DEV Community

Cover image for 5 deadly sins of web accessibility
Dominik Ilnicki
Dominik Ilnicki

Posted on

5 deadly sins of web accessibility

In this article, I'll point out the 5 most common mistakes related to web accessibility and share ideas about how you can cope with them.

Table Of Contents

01. No semantic HTML

Using tags like <section>, <article>, <nav> or <aside> make your site much more accessible right on the starting point. Thanks to that, screen readers used by blind people can clearly recognize the purpose of different parts of the website. Tags like <div> or <span> haven't any informative value and make your content much harder to interpret.

A quick win for your app is using proper heading hierarchy.
It's common that beginning developers think about heading tags (<h1>,<h2>,...) in size category. But it's not the point! Heading tags are not about the size or design property, they are about the priority of the text. If your text needs to be bigger just use CSS to achieve that.

Also, you shouldn't skip heading levels. Start from <h1> then <h2>, <h3> and etc.

02. Omitting alt tag

Remember, every img should have alt property. That makes photos accessible.
The rule is simple there. If the image is just a decoration element without any content message the value of alt should be an empty string. In another case, alt should have a descriptive description of the image.

Tip: Don't write 'The image presents...' or 'In the photo...' in the alt text. The screen readers already have known that's an image.

03. Lack of labels

People need labeled inputs to know what kind of information they are supposed to provide.

Some people use the placeholder value to tell the user what the input is for. It's not the best idea when it comes to a11y. Firstly, some screen readers don't read placeholder value at all. Secondly, it's just a bad UX. When the user starts typing the placeholder value disappears.

04. Too low contrast ratio

If the element's contrast ratio between background and foreground is too low people with vision disorders just can't see the content.
The interesting fact is that it's very important even for your average users, for example on a sunny day it's almost impossible to capture low contrast elements.

If colors fail audit you should consider changing the palette to make your element accessible.

Tip: You can check contrast ratio using this tool https://whocanuse.com

05. No keyboard navigation support

Sometimes users want to navigate your site using a keyboard only. You need to make their life easier.

Never remove the outline from the focused element if you don't provide any alternative styling (box-shadow, background, border).

What's more, your focus order can't behave unpredictably. The order of focus should be consistent with the reading direction in the user's country. You can use negative z-index value to make some elements unreachable from a keyboard (eg. emojis) but be aware of messing focus order up.

Thanks for reading, I hope those points will point your attention to some web accessibility issues.


Hey, If you want to find & join to some cool open-source project check out my latest side project Just Contribute

Top comments (12)

Collapse
 
patarapolw profile image
Pacharapol Withayasakpunt • Edited

Do you have recommendations for these?

  • Automated a11y audit
  • Reality checking
    • I am not really that disabled, but what is the best way to test for extreme, unaccessible, conditions?
    • Do I need to kill my mouse, or bind my eyes? (But I think this is a good example)
Collapse
 
dominikilnicki profile image
Dominik Ilnicki

Hi,
For automated tests, I personally use Google Lighthouse accessibility tab and this chrome extension, it's very powerful and it guides you through manual tests as well. They are both (like most of the tools) powered by the axe-core

Referring to your second point, You can get into disabled people's shoes using this tool simulating eyes diseases. You can also learn how to use a screen-reader and try to use your app with it. Also, try to navigate using the keyboard and check is it possible to complete all the tasks or not.

I hope it helps you. I'll probably write a post about useful tools in a11y field.

Collapse
 
ashleyjsheridan profile image
Ashley Sheridan

I'd also recommend the a11y tab in Firefox. I've found it tests more things than Lighthouse, and does it without any page reloads (it even applies live changes you make in the DOM inspector so you can test out changes before committing them to your code editor). It also has a simulator for some types of colour blindness. The latest version of Chrome has finally added that feature too, which is helpful.

Beyond that, I'd also suggest testing keyboard access across your website, then test with a screenreader. Test these two situations separately, as screenreaders often add event handling to websites that convert some keyboard events into their mouse event equivalents. I found this out by accident when I was adding some click handlers to elements and testing with an SR. It was only be change I'd disabled the SR and noticed that the event handlers were no longer working with the keyboard.

Collapse
 
colewalker profile image
Cole Walker

I think it's helpful to think of headings as a sectioning tool. H1 denotes the overall title of the page, H2 is the large sub sections of the page, H3 is specific articles within those sub sections, etc.

Collapse
 
atyborska93 profile image
Angelika Cathor

Simple and to the point! 👏 Under "No semantic HTML", I would also mention the atrocity of using <span> instead of <button> for clickable elements just to skip the extra work of overwriting the browser's default styles.

Collapse
 
baukereg profile image
Bauke Regnerus • Edited

Good point. At least add a role='button' to any non-button element with a click event. In addition, <a> should be used to navigate to another URL and should not be used as an alernative to <button>.

Collapse
 
robbiegm profile image
RobbieGM

For people who want to remove focus styles when clicking links but want to keep their site accessible: use :focus-visible instead of :focus. It's not widely supported but there's a lightweight polyfill for it on npm.

Collapse
 
kewbish profile image
Emilie Ma

Great tips!

Collapse
 
dominikilnicki profile image
Dominik Ilnicki

Thank you!

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

Rule 00. It's not a web site, and definitely not accessible, if it requires Chrome.

Collapse
 
aybee5 profile image
Ibrahim Abdullahi Aliyu

Do you have recommendation where one can learn more about a11y?

Collapse
 
perpetual_education profile image
perpetual . education

Their new redesign just dropped: a11yproject.com/