A useful sample
Choose representative pages and states: navigation, long articles, search, forms, errors, dialogs and embedded services. Include mobile layouts and the variations editors publish most often.
WordPress / Accessibility
A website people can actually use.
A visitor should be able to find an answer, understand an alert and finish a form. Accessibility work starts with those tasks—and the barriers that get in the way.
Start with real tasks
Test the experience,
not just the template.
A homepage can look tidy while a mobile menu traps focus or a form leaves someone guessing what went wrong. We start by agreeing which journeys matter, then review the templates, content and interactions behind them.
That might mean planning a trip, checking an eligibility requirement or sending a project inquiry. The review should reflect how people use your site.
A stated scope
Record the pages, browsers, devices, assistive technology and agreed WCAG reference used in the review. A sample can reveal recurring barriers; it cannot establish what happens on every untested page.
Evidence to act on
For each issue, capture the affected task, steps to reproduce it and the expected behavior. Separate a shared component defect from a content issue so the right person can fix it.
A practical review
Several checks.
One usable journey.
Automated tools help find some problems repeatedly. They cannot determine accessibility on their own. Manual checks reveal what an interaction feels like and whether the information still makes sense.
We use both, with findings tied to a visitor task rather than a score presented as proof of accessibility.
Keyboard navigation and focus
Move through links and controls without a mouse. Check the order, visible focus, skip navigation, menus and dialogs. Open and close interactions, confirm that focus returns sensibly and look for places where someone cannot continue.
Screen-reader structure and feedback
Inspect headings, landmarks, link names and form labels with a screen reader. Follow the task through validation messages and changing content. A useful name or announcement needs to communicate its purpose in context.
Reading, zoom and mobile layout
Review text and interface contrast, content order, enlarged text and narrow layouts. Check whether information depends on color alone, whether controls remain usable and whether important content gets clipped or obscured.
Automated checks and content review
Use automated findings to locate issues such as missing names or detectable contrast failures. Then review what tools cannot judge reliably: meaningful alternative text, clear instructions and whether an error tells someone how to recover.
An alert needs to work beyond its color.
The route, change and next action belong in readable text. The focus outline below illustrates how a keyboard user can identify the next link.
Example service alert
Route 10: stop temporarily closed
Use the stop at Main Street while work takes place. Check the service notice for the affected dates.
Read the Route 10 service noticeStatic illustration: the outlined text represents a focused link. It is not an interactive service notice.What to check
- The heading identifies the route and the change.
- The message remains understandable without a colored badge or icon.
- The link describes its destination when read on its own.
- The reading order and focus indicator remain clear on a small screen.
For a real content example, read Making route-specific transit alerts accessible on mobile and with a screen reader.
From findings to fixes
Make the fix useful.
Then test it again.
A long issue list needs a clear next step. We prioritize barriers by their effect on a task, how widely they occur and the practical dependencies involved in resolving them.
A shared menu fix may help many pages. A misleading instruction may need an editorial change. A third-party widget may require work with its provider or a different way to complete the task.
Remediate at the source
Work in the theme, component or content field responsible for the issue. Prefer native HTML behavior where it fits. Review plugin and embedded-service behavior as part of the journey, including any handoff away from WordPress.
Retest the full task
Repeat the original reproduction steps and check nearby behavior. A corrected label should still work when the form reports an error; a menu fix should hold when the viewport changes.
Leave a maintainable record
Document what changed, what was verified and what remains unresolved. Give editors guidance for recurring content decisions and keep a small set of important journeys available for future release checks.
The review scope and evidence matter. A scan, plugin or limited page sample is not a blanket certification or a guarantee of legal compliance.
Keep the whole experience in view
Access is part of
website operations.
Content changes, new integrations and routine releases can introduce new barriers. Accessibility belongs in the publishing and maintenance process, with checks proportionate to the change.
Clear structure also helps people navigate, while a responsive site makes it easier to stay with a task. Explore our WordPress SEO guide and performance guide for those related questions.
Before you begin
Common questions.
Agree the scope first. Report the evidence clearly.
Can an accessibility plugin handle this?
A plugin may help with specific functions or checks, but it does not establish whether the complete experience is accessible. Theme behavior, editorial content and third-party interactions still need review.
Which accessibility standard should we use?
WCAG provides testable criteria for web accessibility. Agree the version, target level and any organization-specific requirements before the work begins. For example, a review may use WCAG 2.2 Level AA as its reference. That reference is not itself a claim of conformance.
Does every page need to be tested?
A representative sample can help identify shared problems and prioritize work. Record the sampling limits and expand the review where content or functionality differs. Any statement about conformance needs evidence appropriate to its scope.
What about maps, PDFs and embedded tools?
Include them when they are part of an important journey. Identify what your team can change and where a provider is involved. If an interaction is inaccessible, examine how people can obtain the information or complete the task while the underlying issue is addressed.
Read further
Guidance with context.
Technical references: W3C WAI evaluation guidance, WCAG 2.2 quick reference and WAI forms tutorials.
A practical starting point
Which task is hardest
for your visitors?
Bring us the website and the journey you want to improve. We can discuss a focused review, the evidence you need and the work that follows.