25 WordPress Accessibility Plugins for Auditing and Fixing a Site

Choose between auditing, remediation and reading preferences

Before installing a plugin, choose an action visitors must be able to complete. For a town hall, this may be reading opening hours and requesting a callback. For a store, try opening the menu, adding a product to the cart and correcting a shipping address. Note the exact point where the person becomes blocked, the browser used and any screen reader.

An audit tool identifies signals, such as an unnamed button or weak contrast. A targeted fix changes a specific element, such as a skip link or table. A reading-preference widget lets visitors enlarge text or reduce certain motion. For an obstacle preventing form completion, prioritize fixing the form itself. Introduce a reading preference after checking the basic journey.

The tools collected here cover these three uses. Some combine several. Entries indicate the use for which testing is most useful. Start with one scanner and one correction at a time, retaining the page reproducing the issue. Accessibility evaluation includes human checks and, where possible, tests with people who actually use these access methods.

The WordPress acceptance test shows what a focus-moving skip link looks like and how to check a button’s name in the browser. Other entries rely on developer-documented features.

• Choose three representative pages, such as a post, a form and an ordering journey.
• On a copy, note one action to complete per page and what currently prevents completion.
• Assign each task to an owner among the editorial team, theme team and relevant plugin team.

Read a report and retain the list of pages actually checked

First check whether the tool reads source HTML or analyzes browser rendering. The former can find duplicate identifiers or unlabeled fields. The latter can account for some styles and injected elements. An open menu, error message or filled cart may nevertheless represent another state. Replay these steps after initial analysis.

A report helps locate findings. Associate each result with a URL, element, state and action to test. If a rule does not apply, document why before dismissing it. If the scanner could not load a URL, note that it remains unchecked. Fewer alerts mean little if an archive or protected screen has disappeared from scope.

• Analyze the same content before and after, using the same scanner setting and width.
• Keep a record of URLs ignored, redirected or inaccessible to the scanner.
• First address defects preventing essential tasks, then replay those tasks by keyboard.

Before-and-after example with a callback form

On a draft page, create a fictional form with an email field. Include a pale-gray introduction, informative image and collapsed help. The starting variant uses placeholder text instead of a label, an image without alternative text and a clickable help area absent from tab order. Keep this variant on your test installation.

In the acceptance test run on two fictional HTML pages, axe-core detected the introduction’s low contrast and image lacking an alternative. The label rule did not flag the field containing only placeholder text. DOM inspection confirmed no associated label. Tab also skipped the help area. A point absent from the report may therefore deserve a separate test.

In the corrected variant, associate a label element with the field using for and id. Keep the label visible once typing begins. Connect instructions and, when displayed, the error to the field with aria-describedby. For an error in this single-field form, return focus to the field requiring correction. For help, use a real button and synchronize aria-expanded with panel visibility. A native button responds to Enter and Space.

Replace pale gray with dark text on white and describe the image’s function. In this test, the image indicates the service desk’s location between the entrance and waiting room. The Chrome check passed the three targeted rules and keyboard tests after correction. The test form submits no data. Reproduce the behavior in your theme and form plugin with a fictional address.

• From the address bar, use Tab to reach “Aller au contenu”, then Enter. Check that focus reaches the main content and the field is reachable afterward.
• Submit the empty field. Check that the error is visible, explicit and associated with the field. Then enter essai@example.test and check confirmation.
• Reach “Afficher l’aide” without a mouse, open it and close it. Check that focus stays in the right place and button state matches display.
• Replay the journey at phone width and with a screen reader. Retain each test result separately.

Correct images and media according to their use

For an image, ask what visitors lose if it disappears. A decorative image may have an empty alt attribute. An image serving as a link should help explain its destination. For a map or chart, adjacent text may convey relationships or values readers need. Describing the file or color does not explain its role.

Review batch-generated alternatives on existing pages, because the same image may serve different purposes. For a recording, prepare a transcript and, for video, synchronized captions where necessary. Examine proper names, useful sound descriptions and focus return after the player. Also test the file or page actually hosting the media.

If an AI or PDF-remediation tool uses an external provider, identify transmitted content, billing unit and the step triggering the request. A test document without personal information suffices to compare features. For a public document, check the final file with a screen reader and retain the source document.

• Review alternatives for three images with different uses directly on the page.
• Read the PDF in logical order and check headings, links, tables and any forms.
• Replay player controls by keyboard, then compare the transcript and captions with the original track.

Try a widget without blocking page functions

If adding reading preferences, activate a panel on one test template. With zoom and a narrow screen, check that its button covers neither navigation, cart nor contact link. Try opening, closing and resetting by keyboard. If the panel uses a shortcut, check that it does not conflict with browser or assistive-tool commands.

Check every setting on actual content. Global contrast may change links and icons. Enlarged letters may hide part of a button. A stop-motion option may affect CSS transitions while leaving a slideshow driven by another script running. The same journey must remain possible with default preferences.

Budget depends on site coverage and work continuing after installation. Annual licenses, analysis credits, API fees and support may be billed separately. A free connector may provide a trial without covering ongoing use. Check the offer date and terms and results actually stored in WordPress before choosing.

• Establish the reference journey without a widget and note defects to correct.
• Enable settings one by one. Test a short page, long article and form.
• Decide whether to keep the widget based on tests, cost and preferences actually useful to the audience.

Replay the keyboard journey in a WordPress copy

On a copy of your site, open a page using visitors’ menu and components without an administrator session. Note where the first Tab lands, whether its outline is visible and which control the next Tab reaches. The skip link goes directly to main content. Screen movement alone does not verify it. Also examine where focus lands after Enter.

Our test used WordPress 7.1.4, WP Accessibility 2.4.5 and Chrome 156 at 390 and 900 pixels. The fictional theme had two navigation links and main content with the main-content identifier. A test rule hid focus outlines. Without the plugin, the first three tabs reached both menu links, then “Demander un rappel”. The first link did have focus, but its outline was invisible.

With the skip link and outline enabled, the first Tab revealed “Skip to Content”, in English on this installation. The menu link whose outline was previously invisible then displayed a two-pixel border. Returning to the skip link with Shift+Tab, we pressed Enter. Focus reached the content, then Tab reached “Demander un rappel” with a visible outline. The next Tab reached the email field. Shift+Tab returned to the button.

In our test theme, the target was <main id="main-content" tabindex="-1">. Negative tabindex lets this element receive focus during the skip while keeping interactive controls in their usual order. In your theme, first identify the existing ID and ensure it appears only once per page. If the theme already has a working skip link, retain it. If you maintain the theme, you can also add the link directly and restore an outline with :focus-visible in a child theme or the provided CSS settings.

• Open WP Accessibility settings, enable skip links and enter #main-content as the content-link target if that identifier exists. Enable the focus outline separately. The acceptance test applied both settings by script.
• Reload without clicking inside the page. Press Tab, then Enter on the skip link. Check that the next Tab reaches the first content control. Repeat with Shift+Tab and also check the menu at narrow width.
• If the page scrolls but Tab resumes in the menu, examine the target in the inspector and test focus movement. If the outline is clipped or blends into the background, examine the CSS rule, overflow-hiding containers and fixed elements covering the area.

Check an icon button’s accessible name

The accessible name is what the browser exposes to assistive technologies. The “Demander un rappel” button derives its name from text and the email field from its associated label. We checked both in Chrome’s accessibility tree before and after plugin activation. The custom “?” button had a button role in both cases with an empty name. Making it keyboard-visible resolved one specific obstacle while leaving the naming issue intact.

The test theme used a native button whose pictogram was hidden from the accessibility tree. Adding aria-label="Aide" to the button made “Aide” appear in the browser tree. Prefer a visible label when space permits. For form fields, associate visible text using for and id. Check components as rendered on the public page, including open and closed states.

The previous two-HTML-page experiment and this WordPress test are separate checks. The WordPress sample concerns a fictional template, three page states and two widths in the same browser. It observes names in the browser tree and keyboard movements. Actual templates, menus, popups and forms still need checking, followed by the journey with screen readers and affected users.

• In Chrome, inspect the button, then open the Accessibility panel. Read Role and Name. If the name is empty, correct the component generating the button.
• Reload the page. Check the name, an outline during Tab and button action with Enter and Space on the real component. In the sample, buttons serve only to observe focus and names.

Further reading

• Make WordPress form fields and errors understandable
• Stop disruptive animations and autoplay in WordPress
• WordPress and AI: find a button skipped by Tab