Frontend checks for web accessibility

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 catches more than about 30% of types of issues. It also gives 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 is the Mozilla Developer Network web docs.

For WordPress, we aim to meet WCAG accessibility guidelines at level AA and the W3C standards. In the section Accessibility standards and best practice youll find documentation 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> doesnt 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()

• First published: October 10, 2025
• Last updated: March 03, 2026
• Edit article: Improve it on GitHub

Other pages in: Checklists

• Overall

  Find content, design, and frontend code checklists about accessibility.

• Content checks

  Find an overview of content checks for accessibility.

• Design checks

  Learn about some design checks you can do to enhance accessibility.

← Back to: Checklists

Quick links and main topics

Disclaimer: This documentation is intended to help the WordPress community understand and implement accessible practices. It is not a replacement for the official Web Content Accessibility Guidelines. Please read the full disclaimer.

↑ Back to top