A quick checklist for accessibility practices and tools for web developers. These are not only aimed at people with permanent disabilities, they target the whole internet. Contributions are more than welcome!
These practices and patterns are helping users with various types of dissabilities (permanent or temporary), from color-blindness, to vestibular dysfunction, to low vision to hearing deficits.
- color contrast, >4.5 for AA standard, >7.0 for AAA (a lot of tools can automate this check for the entire site)
- aim for bigger contrast for smaller text
- prioritize text contrast vs borders / other elements
- use icons or other visual indicators together with color (ex: showing errors in forms)
- min font-size should be 16px
- keep 80 characters per line when displaying longer texts and ensure standard spacing for paragraphs
- ensure animations are necessary and not unexpected
- use prefers-reduced-motion to disable animations when users opt-in from their OS
- ensure videos have subtitles or auto-captions
- ensure that at least 5 zoom levels are available on your website and that the layout responds well to zooming in
The use of semantic HTML is crucial for offering support to screen readers and other assistive technologies. By default, HTML does a pretty decent job at this, but you have to make sure you follow the standard and don't override useful defaults.
- avoid using a when a semantic tag can be used instead
- use standard landmarks for defining: header, main, footer, etc.
- use headings in the right order, always start from h1
- form inputs should always be accompanied by labels
- menus should start from a element and contains lists and list items
- use relevant titles for links - they are read by screen readers as users tab their way through the site
- avoid titles like: "click here" or "read more", as they give no indication about the actual link
- images should be accompanied by relevant alt texts
- use ARIA attributes only when there's no semantic alternative
Never make assumptions about how your users interact with the website and make sure you have support for things like keyboard navigation. Some of these practices target people with motion difficulties, tremors and other problems limiting their interaction skills.
- links and buttons should always be keyboard focusable (using the tab key)
- menus and lists should be keyboard accessible (left-right for navigation)
- modal windows have to close when pressing the Esc key
- always show an outline when focusing elements - at a minimum, support keyboard outline with what-input
- focus should be handled in parallel with click/tap events as well as with :hover pseudo-selectors
- don't use tabindex > 0, allow a natural flow for the focus through the interface
- trap focus when showing modal/overlays, so the user cannot navigate behind the foreground
- handle focus after navigation - especially for SPA-like applications which are not reloading the page
- ensure a touch area of at least 44px
- Screen Readers
- Jaws for Windows
- NVDA
- VoiceOver on OS-X/iOS
- Orca for Linux
- lighthouse - performs audits in chrome (the audit tab in devtools).
- axe-core - performs e2e automated tests for a11y issues, can easily be integrated in cypress or jest.
- tota11y - shows a11y validations on top of existing websites.
- alexjs - catches insensitive and inconsiderate writing.
- eslint-plugin-jsx-a11y - ESLint plugin for static analysis of a11y violations.
- ReachUI - a list of a11y first React components
- Inclusive Components - a list of articles and examples of inclusive and accessibile components
- A guide to color accessibility in product design
- Designing Accessible Content: Typography, Font Styling, and Structure
- Designing Safer Web Animation For Motion Sensitivity
- Accessibility showcases of real projects
- Web Accessibility Course on Udacity
- Useful Accessibility Resources by Stefan Judis
- Status of a11y support in browsers
- Building Accessible Menu Systems
- Human Interface Guidelines for iOS
- Handling Touch Targets
- WAI-ARIA Guidelines