This guide contains instructions and recommendations that you can use to robustly test your product's accessibility, in order to identify accessibility issues and opportunities for improvement.

Keep in mind that this guide will not cover every scenario.

Many accessibility issues can be found by doing a few standard checks.

Good accessibility practices start with structural, semantic HTML. When a screen reader (or any sort of assistive technology) scans a web page, it gets information about the Document Object Model (DOM), or the HTML structure of the page. No styles or JavaScript will be read by a screen reader.

Screen readers (like Voice Over (VO), NVDA, or JAWS) don't just turn text into speech. They also use information in the HTML to list all of the headings on a page, give extra navigation controls to data tables, announce how many items are in a list, and more. This makes semantic HTML essential.

You can use an HTML validation tool to test your product, such as W3C’s markup validation service.

When using PatternFly, we recommend checking for accessibility violations locally via aXe: The Accessibility Engine (using aXe DevTools, the Chrome extension, or the Firefox extension). If you want to test prior to deployment, you can integrate aXe with Cypress.

We offer the patternfly-a11y script for bulk testing, which reports any aXe accessibility violations from a set of pages. You can adapt this script to your needs by creating a configuration file that includes authentication, waits for specific items to finish loading (like a loading spinner), or addresses other items relevant to your use case. As a report, this script will deliver an accessibility report via surge.

Before using this script, your UI should be built in the CI workflow. Once built, create a job to run the script against that build. The script assumes that a web server is running and serving your product somewhere that the script can reach (for example, in localhost:8000).

The keyboard is an essential accessibility tool, so it is necessary to ensure that the following requirements are met:

• All functionality is keyboard accessible.
• Elements in the HTML and in the layout follow a logical order.
• Elements with focus are clearly visible.

Screen readers cannot access style information, so you should disable styles for your product to test that your information architecture is effective and that elements have adequate text labels.

The WAVE browser extension from WebAIM allows you to disable styles if this isn't available in the browser you are using.

You can test with any screen reader that is available in your operating system. In PatternFly, we target:

• JAWS with Chrome, Windows (JAWS keyboard shortcuts).
• VoiceOver with Safari, Mac (VoiceOver keyboard shortcuts).
• NVDA with Firefox, Windows (NVDA keyboard shortcuts).

Your UI's colors should pass the following contrast checks to ensure that users across the vision spectrum can understand your product:

• Text color against background color (Understanding WCAG 1.4.3)
• Text color against link color (Technique G183)
• Visible boundaries of buttons and form elements against adjacent background color (Understanding WCAG 1.4.11)

To keep track of your testing efforts, we recommend referencing the following checklist.

This checklist includes some of the main areas that the PatternFly team checks for to ensure that a UI meets consistent accessibility standards. To evaluate your specific implementation, we recommend checking these same areas in your product.