I recently posted a thread on twitter on making your site more accessible. It turned out to be super helpful for a lot of people, so I wanted to condense this into a post for people to refer to.
Having researched a little more into the topic for a new client, I found some changes I could make to my projects which could make all the difference to someone's experience when navigating a site using assistive technology.
1. Planning Ahead
Something that I need to work on is thinking about accessibility from the beginning. I’m working on it, but i still have a couple projects where I’m retroactively fixing my a11y blunders, including my own new site. I’m calling myself out here. It’s poor etiquette and wastes time.
2. Uppercase Text Properly
Instead of typing out uppercase content in all caps manually, use text-transform: uppercase on its class or id in CSS instead. this is because some screen readers read capitalised text letter by letter. Can you imagine how annoying that would be?!
3. Use Aria-label
The alt tag is used for describing images, but have you used the aria-label attribute? This is used to describe an elements role for screen readers. e.g. On a button that says “close” the aria-label could be “back to homepage” to give better context. You can read more here.
4. Specify the Main Content
Be sure to use one <main> tag to specify where the main content is. This helps less abled users to ignore any fancy fluff on your site and go straight to where the main content is.
5. Hide Elements Properly
When hiding absolutely positioned content using left: -9999px instead of using display: none, it’s not visible on a typical screen but this text is still technically visible for a screen reader, so it will still read whatever it is.
6. Use <button> when its a button
Gosh darn it fellow devs, let’s stop using <div>s as buttons. I know they’re by default really ugly and need style stripping, but you’re losing all the button functionality such as keyboard events which screen readers look for to help with navigation.
7. Style Links Sensibly
When adding a link, you may be tempted to use text decoration: none and change the colour on hover. Don’t do this! people who are colourblind struggle with seeing it as a link and won’t see that change. plus, why not be more creative than that?! Here‘s a snazzier example (credit):
8. Size Text Properly
Text sizing is a biggie for people with visual needs. Don’t make your text so small! A good point of reference - body text should be minimum 16px, small text summaries minimum 12px. It’s generally better to use relative screen sizing though. Read more here.
9. Don't Remove that Outline!
Using outline: none (commonly done on text inputs) is keyboard user unfriendly. They use the outline to see which element they’re focused on when they’re navigating through a page, so won’t know what they’re currently interacting with. to remove it sensibly, try using unfocus.
10. Check your Site
There are some great resources which allow you to check your site with a checklist.
A resource for further info and a checklist: A11yproject.
A similar site: A11y.me.
A repo of a11y css stylesheets for your project: a11.
11. Audit your Site
Google Chrome has an open source toolkit for site accessibility auditing that you should check out. You can install this in your own project for testing. See here.
12. Double Check!
Khan Academy has an open sourced accessibility visualisation toolkit, tota11y, so you can see how your site performs with assistive tech. How awesome is that?! Check it out here.
13. See for Yourself
If you have time, try using a screen reader yourself. On a Mac, turn on VoiceOver using Cmd + 5. Navigate through your site using tab and H/B/T/L to get to the next heading, button, table and list. The closed captions will read out the aria labels! Credit to this StackOverflow answer.
There’s loads more on the internet to learn from and I’m just scratching the surface. I’m trying be a decent citizen of the internet and hope I can encourage other devs to do so too. Feel free to share more valuable tips!
Cover image credit to mds.
Hi! I'm Hannah. I'm a virtual reality developer, senior frontend developer, vrcalm cofounder helping dementia patients, and tech for good enthusiast. 🌎
Top comments (20)
I remember seeing code like that for a hidden input to display a nicer input and hide the old-looking one
left: -9999px😳 I definitely didn't think of the a11y implications of that to screen readers. Thanks!Great summary!
Great list!
Something that helps me with button resetting and hiding but not removing content is making sass mixins or helper classes that can be reused. If they're included in a project boilerplate then it makes these features much easier to incorporate and you can focus on making your buttons etc look pretty.
I definitely need to get better at adding aria labels 🙈
My experience with
text-transform: uppercaseis that it does make the screen reader read out the word as if it was written in uppercase, even if the actual text in the element is not. At least that's the case when using Apple's VoiceOver. I haven't found a way to have visually uppercase text that is read out as lowercase with VoiceOver.Interesting to know!
Great article, thanks a lot. And with the link target at "A repo of a11y css stylesheets for your project: a11." you probably meant github.com/mike-engel/a11y-css-reset, as it's returning a 404 on the current link to github.com/mike-engel/a11
Appreciate the heads up Maximilian! Edited :)
I'd like to add another: keyboard access. Besides people with disabilities, power users often rely on keyboard a lot. It also ties in a lot with your point about link styles, and is a great reminder why focus styles are really important.
One thing with this, screen readers sometimes add their own keyboard event handlers where only mouse ones exist (e.g. they capture pressing Enter as if it were an onclick). For that reason, I always end up recommending testing keyboards without and then with a screen reader running.
Some fantastic tips, thank you
That's a great list, thank you for sharing.
Does anyone know how to try out using a screenreader on a Windows machine?
Cool thing: Windows Narrator is built into current version of Windows. From what I've learned recently, the Edge (Chromium) + Narrator is the most accurate browser/AT combination at the moment, especially where ARIA is concerned. Safari+VO has some issues and has fallen behind.
Great question. It’s not as simple as OS X VoiceOver, but you can use either NVDA on Windows, a free screen reader, or on Google Chrome there’s an extension caller ChromeVox which is a screen reader specifically for Chrome users. I personally haven’t used either but please let me know what you think of them if you do!
Thank you! I'll check them out and let you know!
Love this! Thanks for sharing!
An excellent article. Learnt quite a lot of things which I have never known before. Thank you very much for writing this article.