I recently set out to level up my accessibility skills and thought I would share some of my findings. Accessibility can seem like a daunting task, but even a few small considerations can lead to better, more accessible websites.
Don’t Remove Focus States
Many developers remove the browser’s default focus styles without replacing it with something else. This can be an issue for keyboard users, as it makes it difficult to tell where they’re at in a website. Rather than removing focus styles entirely, create your own to better match your brand or visual identity.
Hide or Show Content Specifically for Screen Readers
Sometimes you will have content that is geared specifically for sighted users, while other times you might want to include supplemental text for screen readers only. To prevent a screen reader from reading a specific piece of text, you can use the aria-hidden attribute. If set to true, this tells the screen reader to ignore that text. You can use this technique to prevent screen readers from reading off-screen menus before they’re visible or other hidden content. Just remember to set aria-hidden to false once the off-screen menu is opened.
On the other hand, you can use the hidden text technique described by Jonathan Snook to hide text visually while still allowing the screen reader to read it. The A11Y Project has a nice how-to article on hiding content I recommend taking a look at, as well.
Include Context for Links
How often have you seen or even written links that just say “Click Here” or “Read More”? As a sighted user, you have the context of the text around the link to fill in the gap of where it might go, but that isn’t always the case for non-sighted users. If someone uses a screen reader to navigate through the links on your site, and they all say “Read More”, it can be difficult to tell where anything goes. They might even feel like they’re caught in a keyboard trap if there are enough links in a row that all have the same text. To avoid this, try writing more descriptive link text to give context to your users. Alternatively, you could also use the hidden text technique noted above to include additional helper text. I did this on a news page that had a bunch of “Read More” links. After “Read More”, I included a span with the hidden text class on it that would read “About” and the title of the news article.
Text Treatment
For some screen readers, the way text is treated visually can impact how it is spoken to a user. I came across this when building a website where all of the headings had text-transform: uppercase; applied to them. When testing the site with a screen reader, the “About Us” headline was instead read as “About U.S.”, as the word “US” in all caps is a common acronym for “United States”. Although I haven’t seen any way of avoiding this other than not capitalizing the entire headline, it is something to be aware of. If you find your headlines contain a lot of potential acronyms when capitalized, you could try rewriting the headlines or avoiding caps altogether.
Visual Separators
Sometimes we will use a symbol as a visual separator for text. This is most commonly seen in breadcrumbs and other forms of navigation, where symbols such as a pipe, greater than sign, hyphen, or dot might separate each link. I was recently testing a site with a screen reader and found that after each breadcrumb link it would say “greater than”. This quickly became very annoying, and it detracted from the actual navigation. To fix this, I altered how I included my visual separator by adding each one as a span with aria-hidden="true", as described above. This kept the screen reader from reading the symbol aloud, while leaving the visual separator in place.
Accessibility Resources
There are lots of great resources for learning more about accessibility and best practices. Here are some of the ones that helped me:
-
The A11Y Project has how-to guides, common patterns on CodePen, a website checklist, and additional resources.
-
WebAIM includes detailed write-ups on best practices, information on how to begin testing with screen readers, and more.
-
Responses to the Screen Reader Strategy Survey by HeydonWorks features insightful responses from actual screen reader users on how they navigate websites.
-
Practical ARIA Examples by HeydonWorks features nine examples on how to use ARIA attributes properly.
-
The Vox Product Accessibility Guidelines contains a detailed checklist for designers, developers, project managers, and other team members.
Next Steps
I recently did a bunch of accessibility enhancements for a client’s site, and will be doing the same for this site soon! I’m looking to continue learning about best practices for accessibility, so if you have any additional resources you use, be sure to share them on my Twitter.