A website can look clear on a laptop and still be awkward for someone who uses a keyboard, enlarges the page or relies on assistive technology. A short website accessibility check will not prove that a site meets every requirement, but it can uncover barriers that deserve attention now.
This guide is for small businesses, charities and other organisations that want a useful first review. You do not need specialist software for most of the checks. You do need to test real pages and resist the temptation to treat a green automated score as the final answer.
Choose a few important journeys
Do not begin by clicking around the homepage at random. Pick the tasks people actually visit the website to complete. A sensible first sample might include:
- finding and understanding an important service;
- using the main navigation;
- submitting an enquiry or application;
- reading a policy, instructions or other important information;
- completing a booking, payment or sign-in journey, where relevant.
Include at least one ordinary content page and any page where a mistake would stop somebody getting help or completing a task. Keep a note of the page, the problem, who it may affect and what happened. That record is far more useful than a single score with no context.
Put the mouse aside
Start at the top of a page and use the Tab key to move through links, buttons and form controls. Use Shift and Tab to move backwards. Press Enter or the Space bar when a control would normally be clicked.
Check that you can always see which item has focus. The order should follow the page in a way that makes sense. Menus, cookie controls, pop-ups and forms should remain usable, and keyboard focus should not become trapped somewhere with no clear route out.
A visible skip link can help keyboard users move past repeated navigation and reach the main content. The W3C Easy Checks guidance explains how to review keyboard access and visible focus, alongside other basic checks.
If an important action works only with a mouse, record it as a priority. This is not a cosmetic snag. It can prevent somebody from using the service at all.
Zoom in and check what disappears
Use the browser’s zoom control to enlarge the page in several steps. Read the page, open the navigation and try the main action again. Text should remain readable, controls should not overlap and essential content should not vanish beyond the edge of the screen.
Repeat the check on a narrow window or phone. A responsive layout can still fail when text is enlarged, especially where menus, tables, cookie notices and fixed buttons compete for limited space.
Do not assume that a visitor will rotate a device, reduce the text size or know about a hidden gesture. The page should adapt without asking the user to repair the layout.
Read the page structure, not just the styling
Every page needs a short, descriptive title that distinguishes it from other pages. Browser tabs full of identical titles make it harder to know which page is which, particularly when several are open or a screen reader announces the title.
Headings should describe the sections beneath them and form a sensible outline. A large, bold sentence is not automatically a heading, and a heading should not be used merely to make ordinary text look bigger.
Scan the page using headings alone. Can you understand its shape and move to the section you need? If the outline skips around or vague headings such as “More information” appear several times, revise the words and the underlying heading levels.
Check images in context
Informative images need text alternatives that communicate their purpose. A photograph used to identify a person, a diagram explaining a process and an image used as a button need different treatment. Describe what the reader needs from the image rather than listing every visible detail.
Decorative images should usually have an empty text alternative so they do not add noise for screen-reader users. An automated tool can find a missing alt attribute, but it cannot reliably decide whether the words are useful. That judgement needs a person who can see the image in its page context.
Also check charts, diagrams, video and audio. Important information should not exist in only one visual or audio format. Captions, transcripts or a written explanation may be needed, depending on the material.
Test colour and links without guesswork
Pale text can look tasteful on a design board and become tiring or impossible to read in everyday conditions. Use a contrast checker rather than judging colour by eye. Check ordinary text, large text, buttons, form borders, focus indicators and text placed over images.
Colour should not carry meaning on its own. A red border around a failed form field needs a written error too. A chart that separates categories only by colour needs labels, patterns or another clear distinction.
Links should make sense in the surrounding sentence and, where possible, out of context. Repeated links called “click here” give little help to somebody scanning a page or navigating through a list of links. Name the destination or action instead.
Complete every form as if something went wrong
Forms often pass a quick visual review because the empty version looks tidy. Test them properly. Move through every field by keyboard, leave required information blank, enter something in the wrong format and submit the form.
Each field needs a visible label. Instructions should appear before they are needed, and error messages should explain what to correct in plain language. When the form fails, move focus or provide a clear summary so the user can find the problem without hunting through the whole page.
Check the confirmation as carefully as the form. A successful submission should produce a clear on-screen message, and the organisation should retain or route the information as intended. For the planning behind those fields and follow-up steps, see our guide to planning a small-business website enquiry form.
Use automated tools, but do not stop there
Browser tools and accessibility scanners are good at spotting certain technical problems quickly. They can flag missing attributes, some contrast failures and parts of the page structure. They cannot understand every piece of copy, decide whether alternative text is meaningful or judge whether a real journey makes sense to the person using it.
GOV.UK’s accessibility testing guidance recommends combining automated and manual testing because either approach on its own will miss issues. For a fuller assessment, test with assistive technologies and involve disabled users with relevant access needs.
The W3C overview of WCAG 2 is the starting point for the technical standard. WCAG 2.2 organises its guidance around four principles: content should be perceivable, operable, understandable and robust. A handful of checks cannot establish conformance with the full standard.
Sort the findings by effect
Fix barriers that stop a task before smaller irritations. A keyboard user who cannot open the menu has a more urgent problem than a heading that could be worded more clearly. A useful issue record includes:
- the page and step where the problem occurs;
- the browser, device or assistive technology used;
- what you expected to happen;
- what happened instead;
- the user or task affected;
- a person responsible for the fix and a date to check it again.
Retest the exact journey after a change. Then add the check to routine website maintenance so the same barrier does not return with the next redesign, plugin update or new piece of content.
Know which rules apply to your organisation
Accessibility is useful work for any organisation, but the legal position varies. GOV.UK’s guidance for public sector bodies explains the specific 2018 accessibility regulations, the WCAG 2.2 AA requirement and accessibility statements. It also notes the separate duty on UK service providers to make reasonable adjustments under the Equality Act 2010, or the Disability Discrimination Act 1995 in Northern Ireland.
This article is a practical starting point, not legal advice or an accessibility audit. If you are unsure which duties apply, take advice based on your organisation and service.
Make the next review smaller
The easiest accessibility problems to manage are the ones that do not keep returning. Give content editors guidance for headings, links and alternative text. Include keyboard and zoom checks in acceptance testing. Ask suppliers how they test components before those components reach the live website.
If the review exposes structural problems rather than isolated content fixes, our WordPress website service covers information structure, responsive layouts and practical website planning. Bring the list of affected journeys to the first conversation. It gives the project a much better starting point than a request to “make the site accessible” with no evidence attached.