When you are developing in an accessible way you are not only coding for completely blind people. There are a lot of people out there with low-vision who can still see the screen and for instance use their mouse to hover over text which is then read to them by the screen reader.
And we haven't even mentioned people who just prefer using Tab to go through a site/form.
Accessibility in general is much more than proper semantics, focus handling, contrasts. Site speeds etc.
However, this page (for now) will only deal with the above.
76% of screen reader users are blind (from a non-representative study). The rest have either low vision (18.5%) or other impairments (deafness/hard-of-hearing 6.0%, cognitive 3.3%, motor 2.0% and other). 15% have multiple disabilities.
Any element that's in the tab order (can be reached when you Tab through the site) can receive focus.
<div>s are not focusable by default, you have to place them in the tab order if you want them to behave as interactive elements such as buttons.
<div tabindex="0">Tabbable due to tabindex value of 0.</div>If you lose sight of the focus ring and are not sure what element is currently in focus you can find it through your dev tools the following way:
- Open Dev Tools (
Ctrl+Shift+I) - Select
Console - Click on
Live expressions - Type
document.activeElement - Click outside of the Live Expression UI to save.
Check out the screen reader guide page for help on how to set up and use a screen reader on your own machine. It helps a lot in checking the accessibility of your code.
The recommended software to be used. It is free, works on Windows machines and widely used.
In order of popularity based on a non-representative survey done by WebAim
If you have it, use it. It is widely used but not free.
If you are on a Mac machine you should have access to Voice Over which is a great piece of tech.
Windows10's inbuilt screen reader - Narrator - is not very good and not really used by many. Avoid using it.
A Google developed Chrome extension (previously called ChromeVox). OK for quick checks but not very comprehensive or widely used.
ChromeOS's screen reader, not widely used (just like ChromeOS 🙄)
In Settings under Universal access there's a toggle for a screen reader. It's OK but not very widely used.
If you want a comprehensive overview of accessibility and implementation in the codebase this is a great course to go through. Touches on everything important from focus handling to the importance of proper semantics and aria attributes amongst others.
https://www.udacity.com/course/web-accessibility--ud891
Great, practical examples of accessible code patterns from tables and forms to images and carousels.
https://www.w3.org/WAI/tutorials/
A collection of accessible vanilla JS scripts for carousels, tab panels, accordions, hide/shows, modal windows, dialog tooltips (modal) and tooltips.
https://van11y.net/
Web Accessibility Evaluation Tool (WAVE)
Run an accessibility check on a page to see all issues.
https://wave.webaim.org/
Chrome Lighthouse
Integrated in Chrome and can be found via the Dev Tools.
Contrast checker
For a quick check whether a design has proper contrast.
https://webaim.org/resources/contrastchecker/
W3 Html markup validator
Just to check your html for not necessarily accessibility related issues
https://validator.w3.org/