Have you ever experienced illegible text due to font size, colour, or style? Have you been irritated by cut-off web content when using your mobile device? Maybe you’ve landed on a dead-end page? Or ended up focus-trapped when using keyboard navigation? Maybe you’ve taken time to fill out a form only for it to fail on submit for no apparent reason?!
If you’ve ever been frustrated any of these problems, you’ve been a hapless victim of Web Accessibility neglect!
Web Accessibility is the idea that the World Wide Web (WWW, W3) should be usable by all users, including those with disabilities. Web Accessibility was first formalized by the World Wide Web Consortium (W3C) when they launched their Web Accessibility Initiative (WAI) in 1997 with endorsement from the US government to improve web accessibility for people with disabilities.
Disabilities accommodated by Web Accessibility include:
- Blindness and poor vision
- Deafness and hard of hearing
- Motor impairment
- Seizures and epilepsy
As developers, it is our responsibility to prioritize accessibility and prevent similar frustrations from happening to anyone else on the web.
Everyone! Not only does it allow people with disabilities to use the web, but accessibility also helps people in restrictive circumstances. Examples of people without disabilities who benefit from Web Accessibility include:
- people using small screens or different input methods (e.g. keyboard, touch screen)
- older people with degrading eyesight, hearing, or motor skills
- people with short term handicaps, like a sprained wrist
- people under environmental constraints where they have trouble seeing their screen or are unable listen to audio (e.g. outdoors in sunny weather, in a quiet area like a library)
- people using a slow or limited internet connection
Making your website accessible also has many benefits beyond those of the end user:
- Higher quality software: web accessibility techniques align with best practices for web development and serve as a benchmark for functionality and usability that businesses and developers can be proud of
- Reduced maintenance cost: accessible code is easier for developers to read, understand, maintain, and extend, which results in greater efficiency over time
- Wider target audience: accessible websites are able to reach a broader user base through techniques like responsive web design, cross browser compatibility, and search engine optimization
- Corporate social responsibility: businesses have a moral and ethical obligation to accommodate users with disabilities
- Legal compliance: adhering to accessibility standards is required by law in many countries
- Better marketability: accessible websites result in better marketability, not only for the product and business, but also for the skilled developer who’s able to implement them
What Makes a Website Accessible?
Common accommodations for disabilities include:
- Increased font visibility and readability for users with limited eyesight
- Additional onscreen text information for sighted users (e.g. headings, tooltips, captions, definitions for words and acronyms)
- Extra markup for sightless users that rely on screen readers
- Keyboard navigation for motor impaired users and sightless users that rely on screen readers
A screen reader is software that reads aloud the contents of a computer screen. When operated on a website navigated by keyboard, it will read the contents of the current focused element as well as relevant metadata in the markup. For example, most screen readers will tell the user how many list items there are in an HTML list and which list item they are currently focused on (e.g. 1 of 4), the level of heading they’re on (h1 - h6), or if they’re on an actionable control element such as an anchor link or button.
The most popular free screen readers are:
ChromeVox is available as a Google Chrome Extension, while VoiceOver and Narrator are bundled with their respective operating systems and can be enabled in the computer’s system settings.
While keyboard navigation is especially important for users dependent on screen readers and motor impaired individuals, it also benefits anyone who prefers it over mouse navigation — for example, I’m sure we’ve all used keyboard navigation to tab through a form with multiple fields.
Keyboard navigation works by using the Tab, Shift, Space, Enter, and arrow keys to “focus” on different page elements in a set order and “activate” interactive content. “Focusing” on an element should highlight it in your web browser, while “activating” an element will trigger the default action for that element, which is typically a “click” action on an element.
Standard keyboard controls are:
- Tab: focus on next section in page
- Shift + Tab: focus on previous section in page
- Space or Enter: activate interactive content (i.e. clicking a button)
- Arrow keys: scroll or select for radio buttons
- Backspace: return to previous page (e.g. back button)
- Esc: cancel current action (e.g. cancel page load or refresh)
Try it yourself! Start by pressing Tab or Shift+Tab on any web page to focus or highlight different page sections and interactive content. You might just end up ditching your mouse for keyboard navigation.
Now that we have a better idea of who benefits from accessibility and what makes a website accessible, it’s time to dive into the W3 WAI accessibility guidelines.
There are three W3C WAI accessibility guidelines:
- Web Content Accessibility Guidelines (WCAG) — Ensures web content is accessible to users with disabilities on different devices.
- User Agent Accessibility Guidelines (UAAG) — Ensures user agents support web content accessibility features.
- Authoring Tools Accessibility Guidelines (ATAG) — Ensures authoring tools are accessible themselves and facilitate the creation of accessible web content.
- User Agents — software that present web content to the user, such as web browsers (Chrome, Firefox, Safari, Edge, Opera) and screen readers (ChromeVox, VoiceOver, Narrator).
- Authoring Tools — software to create web content, such as code editors (Sublime, Atom, VSCode), content management systems (CMS), blogs (WordPress), and social media networking sites (Facebook, Instagram, Twitter, LinkedIn).
Guidelines are structured in the following Layers of Guidance:
Where each Principle has a set of Guidelines, and each Guideline has a set of Success Criteria. For each criterion, there are sufficient and advisory techniques on how to meet the criterion, as well as practical web examples that fail the criterion.
Each Success Criterion falls under one of the following three levels of conformance:
- Level A — All Level A success criteria must be satisfied
- Level AA — All Level A and Level AA success criteria must be satisfied
- Level AAA — All Level A, Level AA, and Level AAA success criteria must be satisfied
Level AAA is the highest level of conformance and as such, satisfying such criteria is often more involved and rarely achieved. For example, one Level AAA criterion is to provide sign language interpretation for all pre-recorded audio, which would be unrealistic for music streaming sites with millions of songs.
There are 4 accessibility principles defined by W3C WAI:
With a total of 13 Guidelines covered in the WCAG, UAAG, and ATAG:
Perceivable web pages are:
- Easy to read with sufficient size and contrast for text and simple font style
- Presented so separate, related, and interactive elements are distinguishable
- Well structured and organized with logical hierarchy, order, and sequence
- Defined by descriptive and meaningful semantic markup
- Informative through text
- Screen reader friendly
- Non-reliant on colour, shape, size, or position of user interface components for instructions
- Useable in both portrait and landscape orientation
Generally, one should:
- Provide important information through text
- Provide text alternatives for non-text content
- Make all visual information clear and easily visible
- Ensure that screen readers process and read page content in the correct order
- Avoid images of text
- Add a dark mode to your application’s user interface suitable for low light environments
- Use meaningful semantic HTML markup
Specifically, one can:
- Add visible text to describe and identify content (titles, headings, labels, descriptions) or serve as an alternative to non-text content (e.g. captions, subtitles, and transcripts for audio and video)
- Add invisible alternative text through accessible HTML attributes, either native (alt, for, name) or WAI-ARIA (aria-, role), to clarify intended meaning for screen readers and web developers
- Group related elements together
- Use semantic HTML markup to convey structural meaning for screen readers and web developers (article, section, nav, header, footer, h1–h6, ol, ul, li,figure, figcaption, label)
- Use table elements for tabular data, not layout
- Ensure text has a colour contrast ratio of at least 4.5:1 or 3:1 for large-scale text (18 point or 14 point bold) using a contrast checker
- Provide instructions that do not rely only on sensory characteristics of components such as shape, colour, size, visual location, orientation, and sound
Operable web pages are:
- Easy to control, operate, and navigate
- Keyboard accessible with logical flow
- Navigable through links via multiple paths
- Controllable with respect to time-based functionality
- Non-reliant on complex multi-touch, motion, or gesture inputs and controls
- Controllable by buttons of adequate target size
Generally, one should:
- Make all functionality of a web page available through keyboard (Tab to focus next, Shift+Tab to focus previous, Space or Enter on focus to activate default action, and arrow keys)
- Ensure the web page does not cause seizures
- Make sure the entire web page is navigable through links
- Provide single pointer or keyboard alternatives for multi-point, motion, and gesture functionality
Specifically, one can:
- Add keyboard functionality by using Interactive Content HTML elements (button, a, details, embed, iframe, img, input, label, select, textarea, video), which have built-in focusability and activate default actions on focus and keypress of the Enter and Space key
- Add focusability by setting the tabIndex attribute to “0”
- Make the target size for single-pointer input at least 44x44 pixels
Understandable web pages are:
- Easy to read, understand, and use correctly
- Intuitive to use
- Consistent in behaviour of user interface components
- Clear with instructions for input and error correction
- Readable through simple language, translations, pronunciations, or definitions of terms, abbreviations, and acronyms
Generally, one should:
- Write content that is easy to understand
- Define terms, abbreviations, and acronyms
- Provide instructions for user input
- Identify errors on input and suggest corrections
Specifically, one can:
- Assign the lang attribute of the HTML element to the two letter (ISO 639–1) code of the language the web page is in, e.g. “en” for English or “fr” for French.
Robust web pages are:
- Compatible across web browsers
- Error free
Generally one should:
- Write valid, well formed HTML with matching opening and closing tags
- Avoid using poorly supported, deprecated, or ambiguous web language features
- Support as many web browsers as possible
Specifically, one can:
- Use a markup validation service to validate markup
- Use an autoprefixer to add browser specific prefixes to their CSS and allow for increased cross browser compatibility
- Install a linter in their code editor to catch syntax and styling errors
To learn more about Accessibility Principles and Guidelines, check out the W3C’s page on Acessibility Principles
How Accessible is My Website?
Here are some helpful tools that can be used to evaluate Web Accessibility:
- Audits Panel in Google Chrome DevTools:
Performance: How long does this app take to show content and become usable
Progressive Web App: Does this page meet the standard of a Progressive Web App
Best practices: Does this page follow best practices for modern web development
Accessibility: Is this page usable by people with disabilities or impairments
SEO: Is this page optimized for search engine results ranking
- WebAIM contrast checker
- WebAIM web accessibility evaluation tool (WAVE)
- HTML 5 Outliner
- The A11y Project’s Web Accessibility Checklist
For a comprehensive list of Web Accessibility evaluation tools, check out the W3 Web Accessibility Evaluation Tools List:
To learn more about Web Accessibility, be sure to check out:
Mozilla Development Network Accessibility resources:
That’s it! Now that you know all about Web Accessibility, it’s time to put it into practice. Together, we can make the World Wide Web accessible for everyone — now that’s something to get excited about!