Basic accessibility tests for developers

Posted Monday, 2 June 2025

This page lists simple accessibility checks that any developer should be able to perform. It’s not a full WCAG checklist or an audit guide, but a set of quick tests and considerations you can refer to while developing features or fixing bugs. It's a great starting point for developer teams wanting to start incorporating accessibility testing into their workflow.

Keyboard accessibility

Using only the keyboard, Tab through the page and check:

All interactive elements, such as buttons, links, and form inputs, can be reached and used without a mouse.
Each element is visible when it gains focus.
A clear focus indicator appears when an element is selected.
Focus never disappears (for example, when something hidden or off-screen gains focus).
The focus order makes sense and flows naturally through the page.
Nothing unexpected happens while tabbing (such as new windows opening or modals appearing without reason).
Focus doesn’t become trapped in an area of the page without an escape route (for example, a modal without a close button).
Focus stays where you expect it after typing into a form.

You can find more in-depth keyboard tests in my how to test keyboard accessibility guide.

Page structure and language

Check the page title is descriptive

A page's <title> is used to identify the browser tab. It's also the first thing announced by a screen reader when the page loads, setting the context for the page.

Check that:

A descriptive page title exists
The title is front-loaded with the most relevant information first (for example, "Football equipment - Acme Sports")

Check the page regions

Main sections of the page should use semantic "landmark" elements:

<header> for the page header
<nav> for the main navigation
<main> for the main content
<footer> for the footer

These help assistive technologies, like screen readers, understand the structure and allow users to move between landmarks easily.

Check the page language

The page should declare its default language with the lang attribute, for example: <html lang="en-gb">
Any parts written in a different language should also be marked correctly, for example: <li lang="de">Deutsch</li>

Colour

Colour should not be the only way of conveying information. For example, links in text should not rely on colour alone but also use an underline
Text colour should have a contrast ratio of at least 4.5:1 against its background (use a tool such as axe DevTools or IBM Equal Access)
Form input borders should contrast at least 3:1 against their background (use a tool like CCA)

Text content

Check proper headings are used

Screen reader users often navigate by headings. If visual headings are not coded with <h1>, <h2>, <h3>, etc., they won’t be recognised as such.

Check that:

Headings use proper HTML heading tags
Headings are descriptive and act as signposts for the content
Heading levels are not skipped (for example, don’t jump from <h1> to <h3>).

Check links text

Link text should make sense on its own. Screen readers may list all links without surrounding context.

Check that links:

Clearly describe their destination
Make sense in isolation
Avoid vague text like "Click here" or "Read more"
Don’t use raw URLs as link text
Include file type and size when linking to documents (for example, "Sales forecast 2025 (PDF, 2MB)").

Where space is limited, visually hidden supplementary text can be added to links if the visual link text does not make sense in isolation, e.g, in a datatable where each row contains an "Edit" link. Ideally this would be provided by text hidden using the CSS clip method.

Check lists are coded correctly

Lists of things, bulleted or numbered use the correct HTML tags. Screen readers often offer users list specific keyboard shortcuts and additional information about lists when coded correctly, such as the users current position in a list and how many items are in the list.

Check any content that visually appears as a list is coded correctly:

Bulleted lists, where order isn't important, should use unordered lists <ul>
Numbered lists, where order is important, should use ordered lists <ol>
Description lists, where you have a key and value, should use description lists <dl>

Check instructions do not rely on sensory information

Make sure any instructions do not rely on the user ability to see the page. For example:

"Click the big square button"
"Click the red button"
"See the blue section on the right"

People who can not see the page will not be able to follow visually instructions.

Images, video and audio

Check that images have alternative text

Informative images, charts, and diagrams must have suitable alt text
Complex visuals should have both an alt attribute and an accompanying text alternative (for example, a data table below a chart)
Decorative images should have an empty alt attribute
Functional images (such as icon-only links) should use alt text that describes the link purpose, not the image itself

The W3C alt text decision tree can be useful for deciding what's appropriate.

Check videos and audio content

Videos with sound must include captions that cover both speech and key sounds
Audio descriptions should describe important visuals not covered by dialogue
Audio-only content should have a transcript

Check for images containing text

Images of text should be avoided (apart from logos and brandnames). Users with vision impairments may need to customise the appearence of text, for example zooming in, increasing text slize or changing text colours. Text within images can not be customised in this way.

Forms

Check form elements are marked up correctly

Use native HTML elements (e.g. <input>, <select>, <button>)
Buttons should be used for actions, not navigation
Custom controls must use the correct ARIA and offer the same keyboard support as their native counterparts
Group related fields (like radio buttons) with <fieldset> and <legend>

Labels

Each input should have a visible <label> which is programatically associated with it's input using the for attribute
Labels should be clearly describe what the user is expected to enter into a field

Help text

Where additional help/hint text is provided for an input, outside of a <label>, it should be:

Positioned directly above or below the input
Descriptive and useful
Programatically associated with the input through the use of aria-describedby="id-of-help-text" on the input

Errors

Form errors must be:

Described in text, not just with colour or icons
Identify the input in error and how to resolve the error e.g., "Error: enter your name" not just "Error"
Be programatically associated with the input, similar to help text, either by adding it to the <label> or by using aria-describedby="id-of-error-text"
Be placed as close as possible to the input in error

Ideally the user would be alerted as soon as possible to the presense of the error. Depending on how the form functions, this may be by adding an error summary to the top of the page which lists the errors and links to the inputs with errors.

Autocomplete

Where form inputs capture certain personal information about the user completing the form, the correct autocomplete value should be used. For example:

A first name input should include autocomplete="given-name"
A credit card number input should include autocomplete="cc-num"
A username input should include autocomplete="username"

A complete list of relevant autocomplete values can be found in the WCAG docs under Input Purposes for User Interfaace Components.

Interactive elements

Check intereactive elements are big enough

Buttons, links, and inputs should be large enough to use easily. Excluding inline controls, they should be at least 24x24px, ideally 44x44px.

Check correct element use

Use the right HTML element for the job:

<button> for actions (submitting forms, opening modals)
<a> for navigation`
<input type="radio"> or <select> for single-choice options rather than checkboxes etc

Native elements come with built-in accessibility features and keyboard support. For example, pressing Enter or Space activates a <button>, but not a styled <div> pretending to be one.

Dynamic content

Check revealed content location

Where content is revealed following a user action, such as a button click, the revealed content should be next in the focus/tab order or if not, have keyboard focus set to it on reveal.

Dynamically loading content

If content loads dynamically (without reloading the page), users should be informed. Use live regions so screen reader users are aware of updates.

For example, a user loads a page that lists items and allows them to filter the items:

on page load a live region exists is present, e.g., <div role="status"></div>
the user applies a filter
a status message is displayed - "Filtering content" - and inserted into the live region
a screen reader user hears "Filtering content" (rather than being unaware content was loading)
when the content has loaded, the status message is changed to "Content loaded" (or similar)

The use of live regions can differ depending on the situation, but the main goal is that users who may not be able to see visual affordances, like loading spinners, get the same information on important changes to on screen content. WCAG 4.1.3 Status Messages goes into more detail.

Zoom

Many people use either magnification software, larger font sizes or higher than default levels of zoom in their browser or operating syste. Use Ctrl + + on Windows or Command + + on Mac to zoom the page to 200% and then 400% and check:

Text and elements enlarge
All content remains readable
All functionaility, such as navigation, forms, and other interactive content is still accessible, works with the keyboard and functions as expected
Nothing is cut off, truncated or overlapping
Horizontal scrolling isn't needed (except for tables)

At high zoom, the layout should usually switch to a single column, following responsive design principles.

Run automated tools

Many "one click" browser extension accessibility tools exist. While automated tools can typically only pick up on ~30-40% of accessibility issues, they are free, quick and easy to use. I'd recommend installing and running the following after the above mentioned manual checks.

Summary

Following these checks during development helps catch many of the most common accessibility problems early. This isn’t a full WCAG checklist and won’t cover every case or situation, but it’s a solid foundation developers can use before more detailed QA or accessibility testing.