Automated testing is valuable evidence, but it is not an accessibility verdict
An automated WordPress accessibility audit can crawl pages, identify deterministic failures, group repeated component problems, and give developers a far better starting point than an unaided spot check. It cannot determine whether every person can understand and complete every important task on the website.
W3C’s Web Accessibility Initiative is explicit: evaluation tools can assist with testing, but they cannot check every accessibility aspect automatically and cannot determine accessibility by themselves. Human judgment remains necessary, and tools can produce false or misleading results. See W3C’s guidance on selecting accessibility evaluation tools.
The useful question is therefore not whether a scanner declares a site compliant. It is how automation, manual review, assistive-technology testing, content judgment, and remediation verification work together. The completed Osiris accessibility-audit application was built around that boundary: automate what can be established, identify what needs assisted review, and never convert an untested subjective criterion into a false pass.
What a sitewide WordPress accessibility scanner does well
Automation is excellent at recurrence and scale. It can inspect heading structures, document titles, language attributes, form labels, accessible names, duplicate IDs, empty links or buttons, some ARIA relationships, image alternative-text presence, color-contrast calculations where colors are computable, focusable elements, landmark patterns, and many code-level conditions mapped to WCAG success criteria or accepted testing rules.
A crawler can also show whether one defect is isolated or systemic. If the same navigation component produces an accessible-name failure on 150 URLs, repairing the template may resolve the problem everywhere. If a single article contains an empty heading, the fix belongs to content. Grouping results by component, template, rule, severity, and URL helps owners prioritize the change with the greatest reach.
Repeated scans create a baseline. Teams can compare new releases, identify regressions, and verify that an intended remediation changed the measured behavior. Exportable evidence also improves handoff: the issue, affected pages, relevant markup, criterion, suggested test, and retest status can travel together instead of living in screenshots and memory.
What automation cannot understand reliably
A tool can confirm that an image has an alt attribute, but it usually cannot decide whether the wording communicates the image’s purpose in context. It can find a visible focus indicator under certain states, but it cannot experience whether focus order makes sense through a complex task. It can inspect a form’s labels and errors, but it cannot fully judge whether a user understands how to recover from a failed submission.
Keyboard operation, screen-reader announcements, modal behavior, focus restoration, time limits, drag interactions, dynamic updates, language clarity, instructions, error prevention, and the meaning of link text frequently require a person to perform the task. Cognitive accessibility and usability are especially poorly represented by a single automated score.
False positives also require context. A repeated label may be correct for a group of controls. A contrast calculation may be wrong because a gradient, pseudo-element, or background image was not resolved. An element hidden from the accessibility tree might be decorative or might conceal important information. The responsible workflow records uncertainty instead of inflating the issue count.
Whole-site coverage still needs a deliberate sampling strategy
A crawler should discover canonical public pages through sitemaps and links, but URL count is not the same as experience coverage. Ten thousand articles may use one template, while one checkout page contains several unique states and consequences. Authenticated dashboards, search results, error messages, pagination, filtered archives, forms, media players, consent dialogs, and third-party widgets may not appear in an ordinary sitemap.
We combine broad crawling with feature-aware review. The application can identify technologies and patterns that make certain manual checks relevant. A site without video should not receive a distracting list of caption checks, while a site with a custom dialog requires focus trapping, keyboard dismissal, labeling, background interaction, and focus-return review.
W3C’s current WCAG Evaluation Methodology (WCAG-EM) 2.0 organizes conformance evaluation around defining scope, exploring the product, selecting a representative sample, evaluating that sample, and reporting the findings. It also recommends involving users with disabilities to help address real-world experience. For a WordPress site, representative testing should cover templates, business-critical tasks, states, devices, zoom and reflow conditions, keyboard navigation, and assistive technologies appropriate to the audience and risk.
W3C’s preliminary checks likewise warn that a page can pass basic checks while retaining significant barriers; more robust assessment is required. See W3C Easy Checks.
A useful audit translates findings into implementation decisions
Issue lists are not remediation plans. Developers need to know where the defect originates, whether it belongs to content, a reusable component, a plugin, a theme, or a third party, which users and tasks it affects, how to reproduce it, what success looks like, and how the correction will be tested.
The Osiris application organizes findings by WCAG level and lets the reviewer choose an intended remediation scope such as Level A, A plus AA, or a wider investigative set. That selection controls the implementation prompt; it does not certify conformance. Feature-aware manual review removes irrelevant questions while retaining subjective checks that the software cannot honestly answer.
Prioritization considers user impact, task consequence, recurrence, repair leverage, and dependency. A keyboard trap blocking the contact form deserves immediate attention even if it appears once. A low-severity template defect repeated across the entire site may be the most efficient systemic fix. Cosmetic scoring should not obscure those decisions.
Accessibility remediation belongs in development and maintenance
WordPress accessibility problems are often rooted in implementation: incorrect native elements, missing labels, component state that is not exposed programmatically, focus styles removed by CSS, third-party widgets, or content models that let editors create ambiguous structures. Correcting them may require theme work, plugin changes, editor guardrails, content revision, or vendor replacement.
That makes accessibility part of custom WordPress development, not a report handed to someone else. The strongest fixes use native HTML first, add ARIA only when necessary, preserve keyboard behavior, communicate state, and give editors fields and instructions that make accessible publishing easier.
It is also a maintenance discipline. New content, plugin updates, redesigns, embeds, and campaigns can introduce regressions after a successful remediation. A practical operating model combines automated monitoring, targeted manual review after consequential releases, periodic task-based testing, and a clear owner for issues.
A retest should verify the user outcome, not just the edited code
Closing a ticket because a template changed is not the same as proving that the barrier is gone. A useful retest repeats the original steps, confirms the corrected behavior on every affected component or representative page, and checks that the change did not create a new keyboard, focus, labeling, contrast, reflow, or screen-reader problem elsewhere.
Automated rules should be rerun against the same baseline so the team can distinguish a real improvement from a changed scan scope. Manual findings need manual retesting in the states where the problem occurred. For a form, that can include initial instructions, keyboard entry, validation, error identification, correction, submission, and confirmation. For a dialog, it can include opening, focus placement, reading order, background isolation, keyboard dismissal, and focus return.
The final record should state what was tested, where, with which relevant browser or assistive-technology combination, what passed, what remains unresolved, and whether any limitation prevents a broader conclusion. That evidence is more useful than a single score because it connects the remediation to an observable user experience.
How to evaluate an accessibility-audit proposal
Ask what the audit covers: public pages, authenticated states, templates, forms, keyboard operation, screen readers, zoom and reflow, responsive breakpoints, content, PDFs, video, third parties, and retesting. Ask which WCAG version and conformance level organize the work, how sampling is selected, and which findings are automated, assisted, or manually verified.
The deliverable should contain reproducible evidence, affected scope, user consequence, remediation guidance, ownership, priority, and a retest status. It should state limitations plainly. Be cautious when a provider promises instant ADA certification, treats an overlay as a substitute for correcting the website, or presents one automated score as a legal conclusion.
If you need a sitewide WordPress accessibility assessment or implementation support, contact Osiris with the public URL, important user journeys, known issues, supported browsers, authenticated areas, and any existing audit. Do not send private user data or credentials through the public form.
If you need implementation rather than another scanner export, explore our WordPress accessibility assessment and remediation. We define the pages, technical work, evidence and exclusions before the engagement; a tool score is not a conformance certificate.
