DEV Community

Cover image for 5 deadly sins of web accessibility

5 deadly sins of web accessibility

Dominik Ilnicki on June 14, 2020

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. ...
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/