Quicksloth

WordPress accessibility checklist for small sites

Last updated: 27 October 2026

Nine checks a site owner can do without a developer, in an afternoon, with free tools. Each one names the WCAG 2.2 success criterion behind it, how to test it and where to fix it in WordPress.

We make an accessibility toolbar for WordPress, so weigh what we say with that in mind. Every fact below links to its source. These checks find common barriers; they are not a full WCAG evaluation, and passing them does not mean your site conforms. This is general information, not legal advice.

An accessibility toolbar helps some visitors; it does not make a website conform to WCAG or to the law. Fix your content and code first.

Before you start: the free tools

Automatic tools find only part of the problems: they can tell that an image has no text alternative, not whether the one it has is right. The checks below mix tools with your own judgment. Test a few typical pages: the home page, a post, the contact page and, if you sell, a product page and the checkout.

1. Color contrast

WCAG 2.2: 1.4.3 Contrast (Minimum), level AA: text needs a contrast ratio of at least 4.5:1 with its background, and large text (18 point, or 14 point bold) at least 3:1. Text in logos, decoration, inactive controls and text inside a photo with other content have no requirement. 1.4.11 Non-text Contrast, level AA, asks 3:1 for what people need to see to recognize buttons, form fields and their states, and for the parts of a chart needed to understand it.

Test: check body text, light grey text such as dates and captions, links, buttons, text over images and the borders of form fields. The ratios are thresholds and are not rounded: grey #767676 on white is 4.54:1 and passes for normal text; #777777 is 4.48:1 and does not.

Fix in WordPress: most colors come from the theme. Change them in the theme's color settings (in a block theme, the site editor's styles; in a classic theme, usually the Customizer) rather than block by block. Colors you set on a single block are in that block's settings.

2. Text alternatives for images

WCAG 2.2: 1.1.1 Non-text Content, level A: images and other non-text content need a text alternative that serves the same purpose, with some exceptions; purely decorative images must be ignorable by screen readers.

Test: WAVE and axe flag images with no alternative at all. Then read the alternatives yourself: does each one say what the image tells a sighted visitor? A linked image, such as a logo, needs text that says where the link goes. File names like "IMG_2041.jpg" are not alternatives.

Fix in WordPress: select the image and fill in Alternative text in the Image block settings, or turn on Mark as decorative if the image carries no information (Image block documentation).

3. Headings

WCAG 2.2: 1.3.1 Info and Relationships, level A: structure shown visually, such as headings and lists, must also be in the code. 2.4.6 Headings and Labels, level AA: headings and labels describe their topic or purpose.

Test: go through the page and note each heading and its level (in the editor, the Heading block shows its level in the block toolbar). Look for one main heading, levels that do not skip (an H2 followed by an H4), and text that is big and bold but is not a heading, or a heading used only to make text big.

Fix in WordPress: use the Heading block and pick the level in its toolbar. In most themes the page title is the H1, so headings in the content start at H2 (Heading block documentation). For lists, use the List block, not lines that start with a dash.

WCAG 2.2: 2.4.4 Link Purpose (In Context), level A: the purpose of each link can be worked out from its text, or from its text together with its context in the code (for example the sentence or list item it is in).

Test: look for links called "click here", "read more" or "learn more", especially several on one page that go to different places, and links that are only an icon. axe and WAVE flag links with no text at all.

Fix in WordPress: select the words that describe the destination and add the link to them: "read our delivery times" instead of "for delivery times, click here". "Read more" links in post lists come from the theme's templates: change the text there, or ask the theme's support.

5. Keyboard and focus

WCAG 2.2: 2.1.1 Keyboard, level A: everything works with a keyboard. 2.1.2 No Keyboard Trap, level A: you can always move away from a component with the keyboard. 2.4.7 Focus Visible, level AA: you can see which element has the focus. 2.4.11 Focus Not Obscured (Minimum), level AA and new in WCAG 2.2: the focused element is not completely hidden by content such as a sticky header, a sticky footer or a cookie banner.

Test: put the mouse away. From the top of the page, press Tab through the menu (including drop-downs), the main links, sliders and pop-ups, the search, the contact form and the checkout. At every step you should see where you are, reach everything, use it with Enter or Space, close pop-ups with Esc and never get stuck.

Fix in WordPress: the focus outline and the menus come from the theme, sliders and pop-ups from plugins. If the outline is missing or a menu cannot be opened with the keyboard, ask the theme's support or try a theme with the Accessibility ready tag in the WordPress.org theme directory. Replace plugins that trap the keyboard.

6. Forms and labels

WCAG 2.2: 3.3.2 Labels or Instructions, level A: fields that need input have labels or instructions. 3.3.1 Error Identification, level A: when an error is detected automatically, the field in error is identified and the error is described in text, not only with a red border.

Test: axe and WAVE flag fields without a label in the code. Then fill in the form with the keyboard, leave a required field empty and send it: does the message say, in words, which field is wrong and what to do?

Fix in WordPress: forms usually come from a form plugin (or the shop's checkout). In its field settings, keep the label visible and do not rely only on the grey hint text inside the field; check that required fields are marked in text, and that its error messages name the field.

7. Video and captions

WCAG 2.2: 1.2.2 Captions (Prerecorded), level A: recorded videos with sound have captions. 1.2.5 Audio Description (Prerecorded), level AA: what is shown only on screen is also described in audio.

Test: play each video with the sound off. Are there captions, and are they correct? If they were made automatically, read them through. If something important is shown but not said, such as a price or a step on screen, it needs a description.

Fix in WordPress: for videos uploaded to your site, the Video block has a Text tracks option for subtitles or captions in WebVTT (.vtt) files (Video block documentation). For embedded videos, add and correct the captions on the video platform. The simplest way to cover description is to say aloud what you show.

8. Language of the page

WCAG 2.2: 3.1.1 Language of Page, level A: the main language of each page is set in the code, so that screen readers use the right pronunciation.

Test: view the page source and look at the first <html> tag: it should have lang with your language, such as lang="en-GB" or lang="de-DE". axe flags a missing or invalid one.

Fix in WordPress: themes print this attribute with WordPress's language attributes, which come from the site's language, set under Settings → General → Site Language (documentation; the documentation calls it the dashboard language, but on the public pages WordPress prints the same value). If the attribute is wrong on a multilingual site, check the settings of your translation plugin.

9. Zoom and reflow

WCAG 2.2: 1.4.4 Resize Text, level AA: text can be enlarged to 200% without losing content or functions (captions and images of text excepted). 1.4.10 Reflow, level AA: at a width of 320 CSS pixels, which is a 1280-pixel-wide window at 400% zoom, content fits without scrolling sideways, except parts that need two dimensions, such as maps, data tables and video.

Test: on a desktop browser window about 1280 pixels wide, zoom to 200% and then to 400% (Ctrl and + on Windows, Cmd and + on a Mac). Nothing should be cut off or overlap, menus must still open, and at 400% you should only need to scroll up and down.

Fix in WordPress: this depends mostly on the theme. Watch for fixed heights, sticky headers that cover half the screen when zoomed, and wide tables or columns; the Columns block has a Stack on mobile setting, on by default (Columns block documentation).

After the checks

Where does a toolbar fit? Our free Quicksloth Accessibility Toolbar lets visitors change text size, spacing, contrast and fonts on your site, in their own browser. That can help some visitors, but it does not do any of the nine checks above for you: it adds no alt text, labels, captions or keyboard access. Do the checks first. For fonts and spacing for readers with dyslexia, see what the research says about dyslexia-friendly fonts.

Sources

All read on 27 October 2026.

Found something out of date? Tell us at support@quicksloth.dev and we will correct this page.