Introduction
The goal of accessibility is to unlock the full potential of the Web and enable people with disabilities to participate on an equal basis.
To achieve this, the Web Content Accessibility Guidelines (WCAG 2.2.) provide a set of standards ("success criteria") to ensure that online content is perceivable, operable, understandable, and robust for everyone.
The PWA largely meets this standard.
This guide outlines multiple methods for checking website accessibility and applying the Web Content Accessibility Guidelines (WCAG) 2.2.
Workflow
The following steps outline a structured method for evaluating accessibility, including following guidelines, using automated tools, and performing manual testing.
Follow Accessibility Guidelines During Development
- Use the Accessibility Easy Check Checklist.
- ESLint Rules: Keep the ESLint accessibility rules enabled in your IDE to ensure compliance during development.
Use Appropriate Tools
Scan the page using multiple partially automated accessibility testing tools and address any issues according to the required WCAG 2.2 AA level:
- Do a first check with Google Lighthouse
- Use Silktide and Wave to identify any automatically detected issues.
Test Manually
- Keyboard navigation: Navigate and operate through the page using only the keyboard.
- Screen reader testing: Use a screen reader like NVDA (or Silktide's simulated screen reader) to verify the accuracy of the HTML markup.
Check the Accessibility of a Page
ESLint Rules
The @angular-eslint repository contains a set of linting rules that help to enforce accessibility best practices in Angular component templates.
Most of the accessibility rules enabled in the Intershop PWA are part of the @angular-eslint/template/accessibility plugin, which is configured in the project's .eslintrc.json file.
To verify whether your custom code adheres to these rules, run npm run lint.
Only a few specific rules that are not included in this plugin are explicitly listed here.
Refer to the official repository to check which rules the plugin currently includes: ESLint-Plugin Accessibility Rules
Warning
These rules alone are not sufficient to ensure good website accessibility.
Additional rules:
- @angular-eslint/template/no-positive-tabindex: Ensures that the tabindex attribute is not positive.
- @angular-eslint/template/button-has-type: Ensures that a button has a valid type specified.
Partially Automated Testing
While automated tools are useful for identifying basic accessibility issues, they can only partially verify compliance with the WCAG criteria.
Manual testing is essential to ensure full compliance.
However, they can provide a quick and easy overview of some accessibility issues on a page, and a good starting point for where to focus and fix accessibility problems.
The following list contains some suggestions for free tools that have been used to check the accessibility of the PWA:
- Google Lighthouse: gives a quick overview and detects general problems
- Silktide: huge toolbox, can categorize issues by different WCAG versions
- WAVE: visualizes non-visible attributes like aria-labels and -roles or image alt-texts
- IBM Equal Access Toolkit: categorizes the issues directly by the WCAG criteria
Google Lighthouse
Google Lighthouse is a tool built directly into the Chrome DevTools that provides a quick initial overview of a page's status.
The list of checked criteria can be found here.
Silktide - Accessibility Checker
Silktide is a Chrome-only extension with many accessibility checking functionalities.
It also includes a simple simulated screen reader, similar to a locally installed one, for quickly checking accessible names of buttons and links.
While limited compared to full screen readers, it is a useful tool for beginners.
WAVE - Web Accessibility Evaluation Tool
WAVE is a browser extension for Chrome and Firefox, as well as a website for testing deployed websites.
It is a helpful tool for visualizing non-visual accessibility attributes like aria-labels, aria-roles, and alt attributes for images including a detailed description and the related WCAG criteria. WAVE can also visualize the tab order and the HTML page structure (landmarks and headings).
IBM - Equal Access Accessibility Checker
IBM Equal Access Toolkit provides browser extensions for Chrome and Firefox that integrate into the developer tools.
It categorizes issues directly based on WCAG criteria.
Manual Testing
Keyboard
The purpose of manual testing via keyboard - without using a mouse - is to check the general operability of the page and ensure a logical HTML structure.
Simply avoid using the mouse and navigate/operate the page using the TAB, ENTER, SPACE, or Arrow keys for certain input fields or menus.
Screen Reader
For the beginning, Intershop recommends to start with Silktide’s simulated screen reader.
It is less sophisticated and much easier and simpler to use.
A locally installed screen reader can be used to thoroughly test a page for features and properties that the simulated screen reader is not capable of.
It also reflects the real world application of such an assistive technology a lot closer than the simulated one.
A widely used locally installed screen reader is NVDA.
If you have no experience with screen readers, the following video about Accessibility Testing with the NVDA Screen reader might be helpful.