Skip to main content
The authoritative source for accessibility testing is the WordPress.org Accessibility Handbook, which is maintained by the WordPress Accessibility team. This guide contains a lot more information about accessibility best practices and testing.

​
Web Content Accessibility Guidelines (WCAG)

We aim to meet WCAG 2.2 AA standards, which represent the latest mid-level accessibility requirements. These standards strike a balance, ensuring that our digital content is accessible to a broad range of users. We also follow WCAG accessibility guidelines which described in our frontend best practices. Depending on whether a site is being used as a governmental or public service, a different set of legal requirements may apply and this may be a strict requirement. The Make WordPress Accessible Handbook contains a dedicated section about Testing for web accessibility with steps and resources.

​
POUR Principle

There are four main guiding principles of accessibility upon which WCAG has been built. These four principles are known by the acronym POUR for perceivable, operable, understandable and robust. Many of the technology challenges faced by disabled people/people with disabilities can be described using one of the POUR principles.

​
Perceivable

It means the user can identify content and interface elements by means of the senses. For many users, this means perceiving a system primarily visually, while for others, perceivability may be a matter of sound or touch. Perceivable problem examples:
  • A website’s navigation consists of a number of links that are displayed in a different order from page to page. If a user has to relearn basic navigation for each page, how can he/she effectively move through the website?
  • A Word document contains a number of non-English words and phrases. If the languages are not indicated, how can assistive technology present the text correctly?
Perceivable solutions:
  • Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
  • Time-based Media: Provide alternatives for time-based media.
  • Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
  • Distinguishable: Make it easier for users to see and hear content including separating foreground from background.

​
Operable

It means that a user can successfully use controls, buttons, navigation, and other interactive elements. For many users this means using assistive technology like voice recognition, keyboards, screen readers etc. Operable problem examples:
  • Mouse-dependent web content will be inaccessible to a person who cannot use a standard mouse.
  • People with low or no vision also rely on the functionality of the keyboard. They may be able to manipulate a mouse just fine, but it doesn’t do them much good because they can’t see where to click on the screen. The keyboard is much easier for a person who is blind to manipulate.
Operable solutions: Keyboard Accessible: Make all functionality available from a keyboard. Enough Time: Provide users enough time to read and use content. Seizures: Do not design content in a way that is known to cause seizures. Navigable: Provide ways to help users navigate, find content, and determine where they are.

​
Understandable

Users should be able to comprehend the content, and learn and remember how to use your site. Your site pages should be consistent in its presentation and format, predictable in its design and usage patterns, and appropriate to the audience in its voice and tone. Understandable problem examples:
  • A website’s navigation consists of a number of links that are displayed in a different order from page to page. If a user has to relearn basic navigation for each page, how can they effectively move through your OER?
  • A site makes use of numerous abbreviations, acronyms, and jargon. If these are never defined, how can users with disabilities (and others) understand the content?
Understandable solutions: Readable: Make text content readable and understandable. Predictable: Make Web pages appear and operate in predictable ways. Input Assistance: Help users avoid and correct mistakes.

​
Robust

Content must be robust enough that it can be interpreted reliably by a wide variety of users, allowing them to choose the technology they use to interact with websites, online documents, multimedia, and other information formats. Robust problem examples:
  • A website requires a specific version of a web browser to make use of its features. If a user doesn’t or can’t use that browser, how can that user experience the features of the site?
  • A document format is inaccessible to a screen reader on a particular operating system. If a user employs that OS for day-to-day tasks, how can she gain access to the document?
Robust solutions:
  • Maximize compatibility with current and future user agents, including assistive technologies.

​
Workflow and Design

Everyone needs to play their part in making the web accessible; from developers to editors, to designers, theme builders, and content creators. Accessibility consideration for a project should start during the design process (or earlier if possible), with the branding colours and font styles of the client. Ensuring design is accessible at this stage is key to avoid surprises and redundant work later in the project. By testing and adjusting early in the process, you can prevent extra work and refactoring afterwards. The following design guidelines should be considered:
  • Fonts should be made as thick as the design allows, and not be too thin
  • Use more than just colour to highlight information
  • Make links stand out in sentences by underlining them
  • Provide one clear and unique title per page (h1)
  • Use borders for input fields and provide them with visual labels
  • Provide three ways to find and navigate content, such as:
    • a consistent menu
    • a search field
    • a sitemap
  • Avoid using capitalised text
  • Avoid using animation that can’t be controlled or stopped by the user
For text in designs:
  • Use real text rather than text within graphics
  • Select basic, simple, easily-readable fonts
  • Use a limited number of fonts
  • Avoid small font sizes: use 16px or larger, depending on the font
  • Don’t rely only on the appearance of the font (colour, shape, font variation, placement, etc.) to convey meaning
  • Review your branding colours for adequate colour contrast with the background colour, before you use them in a web design. All text must have a high colour contrast, including headings and text placed on images
  • Recommended fonts:
    • Use standard fonts, natively available in the browser for content text
    • For online reading, sans-serif fonts (e.g. Arial, Verdana) are generally considered more legible than serif fonts (Times New Roman), narrow fonts or decorative fonts. Decorative and narrow fonts, in particular, should be reserved for headlines and decorative texts only
For colour contrast: Designs should always ensure there is sufficient contrast between text and background colours. Colour contrast ratio between text and background must be:
  • 4.5 or more for normal text
  • 3.1 or more for larger text of at least 24 pixels or 19 pixels bold
Colour contrast can be tested using various tools:

​
Frontend (DOM) validation

An overview of how to test the DOM for accessibility is given in the Make WordPress Accessible Handbook. This guide includes checks, tools and resources for:
  • Keyboard navigation
  • W3C and WCAG 2 AA validation
  • Setting up automated testing in the browser and the command line
  • Testing dynamic content with a screen reader
As frontend accessibility testing needs to run against the final generated DOM, tests must be run in a full browser. While automated DOM testing does exist, this often requires painful setup. Additionally, current state-of-the-art automated testing does not capture all errors; testing keyboard accessibility and announcing of dynamic changes by a screen reader cannot currently be automated. Some minor errors can be detected by static analysis, such as the JSX accessibility plugin. This only tests for small, specific issues that would cause your code to be inaccessible, and does not guarantee that the generated pages are accessible.

​
Content checks

After the site is built, it still needs to be filled with content. It’s important that this content is tested and reviewed as well. An overview of how to test the content for accessibility is given in the Make WordPress Accessible Handbook. This guide includes checks, tools and resources for:
  • Reading levels
  • Heading structure
  • Link texts
  • Alternative text for images
  • Audio and video
If the site includes dynamic interactive elements (for example, dynamic forms) or custom HTML, you should also apply the DOM validation steps as well, including keyboard navigation testing.