Frontend checks for web accessibility

This content needs to be reviewed and expanded.
Related issue on GitHub #173 Topic Frontend checks for web accessibility.
If you want to work on this, please let us know before you start.

Testing for valid, semantic HTML is essential for the accessibility of your work. In this page we list some essential requirements and best resources. It gives you the minimum tests you need to do during development and before you commit your work.

While you develop, always check the following items while developing: keyboard navigation, W3C validation, WCAG 2 AA validation and then announcement of dynamic changes for screen readers.

Note: automated testing is not perfect. Automated testing rarely catchies more than about 30% of types of issues. They also give false positives. Manual testing is required to find most issues.

What is web accessibility?

Using semantic, meaningful, valid HTML5.

The way all devices, browsers and users can understand and interact with the functionality on a web page. The best resource for HTML5 are the Mozilla Developer Network web docs.

For WordPress, we aim to meet WCAG accessibility guidelines at level AA and the W3C standards. In the WordPress Accessibility handbook section Best Practices you’ll find examples and resources.

You need to do two different checks, one for keyboard navigation and one for DOM validation.

Key topics to check

• Write semantic, meaningful HTML
  • Use a <button> to invoke an action and an <a> for a change of location.
  • A <div> or <span> doesn’t natively provide interactivity, and should not be used for links or buttons.
• Heading text and level matter
• Make link and button text meaningful
• Use the .screen-reader-text class, a CSS class to hide text visually while leaving it available to screen readers.
• Always give images a proper alt attribute following the alt decision tree
• Forms:
  • always explicitly link labels to an input control. If the label must be invisible for the design, hide it with the screen-reader-text class
  • Wrap check box groups and radio buttons in a <fieldset> and add a <legend> describing the group of controls
• Always define both a :hover and :focus states in your CSS
• Announce dynamic changes with aria-live or wp.a11y.speak()