One of my first exposures to accessibility in WordPress is the screen reader text class. When I was learning by tinkering around existing themes – it became a familiar sight. Now, the screen reader text class is an effortless addition to my daily development, and it makes a huge difference.
First we’ll go over briefly what this class is and how it can help make sites more accessible. Then I’ll review 5 real life applications of the screen reader text class in the wild. I hope that by reviewing these cases, it can become part of your every day workflow as well.
What’s a girl to write about after so long? Why, things that she loves of course – WordPress and Accessibility. I’ve been getting to know WAI ARIA in recent months, specifically using ARIA landmark roles in WordPress. This seemed like a great place to start as it was a handful of markup to memorize in an otherwise vast amount of ARIA to learn. It’s also familiar to developers if they’ve browsed through WordPress.org themes even if they haven’t realized it yet.
Before we move on, if you’re unfamiliar with what WAI ARIA is ( ARIA for short ), I’ll direct you to W3.org’s reference first.
Reading! So. Much. Reading…
Now if you’re like me, and stopped reading by the second line of that massive intimidating wall of jargon, I’d advise reading something easier on the eyes ( and brain ) like the A11y project’s, “Getting Started with ARIA“. I also found this lengthy article recently, “Introduction to WAI ARIA” written by Gez Lemon, and although it’s from 2008, it cleared up a lot for me. I’d recommend giving it a read through.
Now that we have a basic understanding of what ARIA is ( not the pirate Queen of Omega* ), let’s go over what ARIA landmark roles are and how they can make our WordPress themes more accessible.
* A Mass Effect reference that I couldn’t help, but take advantage of.
I’m still here on my ongoing mission of coding accessibly. There is one HTML element that has become a huge stepping stone for me once I learned how to properly use it. That stepping stone was the button element. What? The button element? Why the heck do we need that? Well, if you’ve ever seen code like below, or have written code like this ( points to herself ), then this post is for you:
<!-- Have you written this for modal integration? -->
<a href="#">I trigger a modal</a>
<!-- Or how about for carousel navigation? -->
<a href="#">Previous Slide</a>
<a href="#">Next Slide</a>
<!-- Or how about a show/reveal effect -->
<div class="container">
<img src="images/some-image.jpg" alt=""/>
<a href="#">Click for more!</a>
<div class="more-content">
<p>Some more info is here!</p>
</div>
</div>
<!-- There's something wrong with the above methods. -->
<!-- We're going to go over what they are. :-) -->
To be honest, I’d been writing code like the above for years until I realized I was missing opportunities. I know other developers that also write code like the above. Why is this the case? Well, there have been some theories of ignorance and fear being the source. In my case, “semantics” was just one of those words that I didn’t come across in the beginning. I just wanted to build things that I could see. It was like trying to build a cabinet with a box full of tools without truly understanding the tools. Sure I can hammer in all the nails and call it a day. Or I can take the time to see what’s in the toolbox. Maybe I’ll find that a screwdriver might be a better tool for some areas of the end product then a hammer. In the end, using the right tools for the job will result in a higher quality product… or cabinet?
PS: Rachel is no good with analogies…
And semantics – what does that even mean? Take it from a gal who was thrown head first into web development from a fine arts degree and had to google words like “repository” during her first week. There’s so much lingo out there! Even now, as a more experienced dev, it makes my head spin. So let’s go over it all, shall we? How to use the button element and when it’s the right tool for the job.
WordPress has this handy theme review handbook. On my quest to learning about accessibility, the requirements in this handbook seemed the next logical step. Since accessible links have been an overwhelming topic for me, learning requirements first give me a head start in addition to learning about making links accessible via context.
The handbook has three required rules for accessible links:
We’ll go over all three in this post. This post is on the lengthy side, but it’s all pretty easy to pick up. What’s difficult is making these techniques a habit in your everyday coding. That, I think, is what takes practice. This post also assumes you’re familiar with basic Css and comfortable with minor edits in theme template files.
I confess. I reached a point in my learning accessibility journey that I became overwhelmed by how much there is to learn. My intention was to start a few posts about links, but there is just so much about accessible links, I didn’t even know where to start. I became discouraged.
Here I am again though, and I’m back on it! I’ve decided that I can’t tell you everything there is to know about accessible links in one post. I can, however, at least introduce the concept and offer resources to wonderful people that have written great things already.
In this post, I’m going to focus on why accessible links matter, how to know if our links are accessible and what we can do right now in our text-editors. Text-editor changes are what’s helping me ease into the concept of accessible links – hopefully it will be helpful to you as well.
Those wonderful people and resources will be sprinkled throughout for those eager to dive into making the most accessible links ever!
