The open web is powerful due to its ability to give everyone access to the same information. This means the Web needs to be designed to work for all people regardless of their location, hardware preferences, language, or abilities. AMP invests in this work through the UI and Accessibility Working Group with the goal to ensure that all AMP experiences are WCAG AA compliant by default. This means that AMP doesn’t just make it easy for you to create accessible sites, it goes one step further by making sure creating an inaccessible experience is not the default outcome.
This blog highlights some of the work that the AMP Project has put into creating accessible components and some key principles and tools that developers should keep top of mind as they create web experiences.
Enabling accessible sites
Accessibility is an important early consideration when designing AMP components. Our Design Reviews and Intent to Implement process focus on making sure that the components we release do not exclude people with varying accessibility needs. This results in AMP enabling you to create pages that meet the W3C WCAG 2.0, Level A and AA guidelines which are an important part of laws with accessibility considerations internationally.
However, like any other framework, while AMP does allow you to create accessible experiences and offers nudges to do so, we can’t enforce that all websites using AMP are meeting WCAG guidance. For example, while <amp-img> allows you to specify an alternate text, we don’t enforce that all images have alternate text; even if we did, we couldn’t enforce that the string provided was actually a description of the image without running extensive Machine Learning models.
How we reduce developer effort
Below is just some of the heavy lifting that the team has done to make the commonly used AMP components and actions accessible by default.
- Click and tap events using the on=”tap.action” handler: In addition to respecting mobile device “taps” and desktop mouse click events, the AMP `tap` event also respects keyboard activation via spacebar or `Enter` for a number of elements annotated with a tappable “role” attribute.
- <amp-sidebar>: Focus management was top of mind for the team as it implemented <amp-sidebar>. This is why <amp-sidebar> moves focus to the sidebar when opened and moves focus to the opener automatically when closed. It also provides a focusable “close” modal for users interacting with the component via a screen reader.
- <amp-carousel>: For <amp-carousel> version 0.2, the next and previous buttons always announce the current slide and the total number of slides when being accessed by a screen reader.
- <amp-list>: By default, <amp-list> adds a list ARIA role to the list element and a listitem role to item elements rendered via the template. If the list element or any of its children are not focusable, or “tabbable” (accessible by keyboard keys such as the a and button elements or any elements with a positive tabindex), a tabindex of 0 will be added by default to the list item. This makes them explicitly accessible via screen reader.
- <amp-autocomplete>: The <amp-autocomplete> component will annotate its generated suggestions to announce that the input field will display suggestions and fully supports navigating through them and selecting them via keyboard. When suggestions are available, the user can use `Up` and `Down` arrow key navigation to visually highlight completed inputs, or for screen readers, to read them aloud.
What we intend to do in the future
Since accessibility is a top priority for the UI and Accessibility Working Group we plan to continuously invest in improving AMP’s default accessibility in the future. Below are a few themes we intend to work on:
- Improve our contribution documentation by adding guidance on accessibility testing that needs to be done by anyone contributing components.
- Improve AMP component documentation to clearly document the accessibility features the component gets right and what added work the developers need to do themselves (such as captioning all videos on the page).
Accessibility resources that the AMP team finds useful
To ensure that your sites are meeting WCAG AA guidelines, we suggest using the following tools to automate your testing.
- axe-core: An accessibility testing engine for websites that integrates with any existing test environment so you can automate accessibility testing alongside regular functional testing.
- WAVE: Tools for facilitating web accessibility evaluation by providing a visual representation of accessibility issues within the page.
- Lighthouse CLI: Chrome Lighthouse builds on axe-core to publish a report on how accessible a site is.
- Other Web Accessibility Evaluation Tools suggested by the W3C here.
However, automated tools can’t always catch all issues, and the best recourse is to have a developer with understanding of the WCAG guidelines review your markup and CSS to ensure that best practices are being utilized.
As always, please let us know if you have any issues or feature requests especially in the accessibility space.
Posted by Naina Raisinghani, Product Manager, AMP Project