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
- No semantic HTML
- Ommiting alt tag
- Lack of labels
- Too low contrast ratio
- No keyboard navigation support
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)
Do you have recommendations for these?
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.
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.
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.
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.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>.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.
Great tips!
Thank you!
Rule 00. It's not a web site, and definitely not accessible, if it requires Chrome.
Do you have recommendation where one can learn more about a11y?
Their new redesign just dropped: a11yproject.com/