How We Test Website Accessibility

The testing layers we can substantiate

1. Inventory and scope. We identify agreed public routes, representative templates, viewport sizes, and important scripted states. Untested pages and inaccessible authenticated flows remain outside the result.
2. axe-core in Playwright. A browser loads each in-scope route and state, then axe-core evaluates machine-testable rules. Each finding retains its route, state, selector, impact, rule reference, and capture time.
3. Scripted browser checks. Playwright checks repeatable conditions such as landmarks, focus targets, new-tab context, and possible focus obstruction. These are scripted heuristics, not observations by a human keyboard or screen-reader user.
4. Review and prioritization. Repeated occurrences are grouped around components and likely source roots. Priority considers user impact, affected task, repetition, and confidence; occurrence totals are not presented as independent defect counts or a compliance score.
5. Remediation and retest. A record remains identified or remediated-unverified until the applicable rule and state are rerun. We do not label an item resolved without dated retest evidence.

Scope-dependent human stages

Keyboard review, screen-reader testing, PDF/document inspection, and third-party transaction testing are separate stages. They require an agreed scope and a confirmed tester with the necessary environment. They are not represented as completed merely because automation recommends them. A report must name the method actually used and identify pending human review.

• Keyboard: task completion, focus order, visible focus, menus, dialogs, forms, and focus obstruction.
• Screen reader: names, roles, states, announcements, reading order, errors, and task completion with the named assistive technology and browser.
• Documents: tags, reading order, headings, tables, links, alternatives, and form fields where applicable.
• Third-party flows: ordering, booking, payment, maps, chat, and other systems not fully controlled by the primary site.

These stages are not a standing promise of a particular tester, device, turnaround, result, or certification. They are included only when confirmed in the project scope.

How results are described

Detected violations are findings. Incomplete axe checks are unresolved review items, not passes. Scripted failures are leads for reproduction, not human testimony. A clean automated rerun does not establish that the full page or site conforms to WCAG. Reports state tested routes, environments, dates, methods, exclusions, remaining dependencies, and whether human review is pending.

See the evidence format

Review the own-site sample audit for dated examples from JubilantWeb's September 22, 2026 programmatic audit. It is a demonstration, not a customer report.

Sources

• axe-core rule documentation
• W3C Web Content Accessibility Guidelines (WCAG) 2.1

Request a website accessibility scan

We review the submitted site and return a plain-English summary. This is a request for review, not an instant public scanner or legal advice.

Request a scan