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.
US Government training materials on creating online content from Word docs to presentations, meetings and social media posts
https://www.section508.gov/create/
https://accessibility-manual.dwp.gov.uk/best-practice/how-to-do-accessibility-testing
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/
It's improtant to note that automatic tools, whilst useful, are not at all a subsitute to manual evaluation. According to a government accessibility tool audit the best evaluators catch at most 40% of issues.
npm package for in development validation.
https://www.npmjs.com/package/html-validator
copy paste your code or URL for validation
Run an accessibility check on a page to see all issues.
Similar to WAVE, can be added as browser plugins as well.
For a quick check whether a design has proper contrast.