DEV Community

Cover image for 13 ways to level up your site's accessibility ✨
hannah 🐙
hannah 🐙

Posted on • Updated on

13 ways to level up your site's accessibility ✨

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)

Collapse
 
lennythedev profile image
Lenmor Ld

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!

Collapse
 
jessicastrachan profile image
Jessica Strachan

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 🙈

Collapse
 
atyborska93 profile image
Angelika Cathor

My experience with text-transform: uppercase is 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.

Collapse
 
erhannah profile image
hannah 🐙

Interesting to know!

Collapse
 
mfranzke profile image
Maximilian Franzke

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

Collapse
 
erhannah profile image
hannah 🐙

Appreciate the heads up Maximilian! Edited :)

Collapse
 
ashleyjsheridan profile image
Ashley Sheridan

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.

Collapse
 
iainfreestone profile image
Iain Freestone

Some fantastic tips, thank you

Collapse
 
alexiaint profile image
Alexandra Titova

That's a great list, thank you for sharing.

Collapse
 
dominicduffin1 profile image
Dominic Duffin • Edited

Does anyone know how to try out using a screenreader on a Windows machine?

Collapse
 
aut0poietic profile image
Jer

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.

Collapse
 
erhannah profile image
hannah 🐙 • Edited

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!

Collapse
 
dominicduffin1 profile image
Dominic Duffin

Thank you! I'll check them out and let you know!

Collapse
 
ruannawrites profile image
Ruanna

Love this! Thanks for sharing!

Collapse
 
manish profile image
Manish Sinha

An excellent article. Learnt quite a lot of things which I have never known before. Thank you very much for writing this article.