A website can look reassuring in an accessibility report and still be exhausting to use. Someone may be able to reach every link on a page but struggle to work out which one will help them. A form can have labelled fields and still give an unhelpful error when it is submitted.
I find it more useful to begin an accessibility conversation with a task. What has somebody come here to do, and can they complete it?
For a charity, that might be finding a service and making an enquiry. For a publisher, it might be signing in and reading an article. For a research organisation, it might be narrowing a directory to a useful result.
Keep the tools, understand their limits
Automated checks are valuable. They can find recurring issues quickly and help prevent a fix being lost during later development. I want that feedback close to the work, while changes are still easy to make.
But the W3C’s guidance on evaluation tools is clear that tools cannot check every aspect of accessibility and that human judgement is required. A score summarises the checks a tool performed. It does not describe every experience someone might have on the site.
That distinction affects what a team does next. Chasing a better number can encourage us to treat every reported item as an isolated defect. Following a task helps connect those defects to the person trying to get something done.
Follow one useful route all the way through
Take an enquiry form. Start before the form, on the page where a visitor would reasonably begin. Can they identify the right service? Does the link describe where it goes? Is essential information available before they are asked for personal details?
Then follow the process using a keyboard. Check that the current focus is visible, that controls appear in a sensible order and that opening or closing an interface does not leave you stranded.
Deliberately make a mistake. Leave out a required answer or use an invalid format. Can you find the error, understand how to fix it and continue without re-entering everything? Finally, look at the confirmation: does it explain what happens next and when a response is likely?
Repeat the important parts with enlarged text and a narrow viewport. These are practical development checks, rather than a claim that one quick exercise establishes conformance. They give the team specific behaviour to investigate and improve.
Bring people into the work early
Developer testing has limits too. Knowing how an interface was built makes it easy to fill in gaps without noticing. People who use assistive technology every day will bring experience a project team cannot reproduce by briefly turning a screen reader on.
W3C recommends involving disabled people in evaluation alongside work on accessibility standards. It also cautions against assuming one participant’s experience represents everyone. That is a useful reminder to plan for a range of people and tasks, with time to act on what the testing reveals.
For WordPress teams, the findings need to reach the editing experience as well as the templates. If a page is accessible only while every editor remembers an unwritten set of layout rules, it will be difficult to keep it that way. Clear fields, useful instructions and well-designed patterns can support the next person publishing content.
I want an accessibility review to leave the team with named problems, a clear owner for each fix and a way to check the result. “A keyboard user cannot close the filter panel and return to the results” gives us work we can do and verify.
Pick one important journey on your site and follow it carefully. It is a manageable starting point, and the findings will usually make the next accessibility conversation much more concrete.
