Website accessibility services that help people complete the task.
An inaccessible menu, hidden focus, or unclear form error can stop someone from using your website. WebXd helps you assess those barriers against WCAG 2.2, plan practical repairs, and check the result. Start with the pages and tasks your visitors depend on, then give your team evidence it can use.
Agree on what the evaluation can establish.
A website accessibility audit needs a defined boundary. We agree on the website areas, representative page types, and complete tasks to examine, including any signed-in states. A registration journey might span several screens and an external payment tool. Reviewing its landing page alone would leave the rest of that experience unresolved.
WCAG 2.2 provides testable accessibility criteria. If AA is the agreed target, the evaluation covers applicable Level A and AA criteria within the defined scope. Record the version, target level, testing date, and supported technology combinations. A sample report should identify what was tested and what remains outside its coverage.
Put these decisions in the brief
- Pages, templates, components, and complete journeys
- Public and signed-in states, including errors and overlays
- Browser, device, keyboard, and assistive-technology combinations
- Documents, video, and third-party tools included or separately scoped
- Access, repair ownership, and the report your team needs
Test how people reach the result.
Automated checks help locate repeatable issues and guide investigation. Manual review examines whether someone can understand the content and operate the interface. A clean scan cannot certify conformance. The testing plan combines methods and records their limits, with user evaluation involving people with disabilities agreed where useful.
Keyboard and focus
Move through menus, dialogs, and controls using the keyboard. Check the order, visible focus, and a way to leave each component. A sticky banner that entirely hides the focused control can create a WCAG 2.2 focus-obscuring failure. Record the viewport and steps needed to reproduce it.
Forms and recovery
Trigger a real validation error in the agreed test environment. Check whether the message identifies the field and explains the correction. Screen reader users need access to that feedback, too. Test returning to the field and completing the task, rather than judging the error's color alone.
Reading and assistive technology
Review headings, link purpose, and control names with the agreed screen reader and browser combinations. Inspect image alternatives for their meaning in context. A control announced only as a button gives little direction. Capture what is announced and compare it with the action the visitor needs to take.
Zoom, touch, and sign-in
Check content at enlarged text and narrow widths, then inspect touch targets and alternatives to dragging. For sign-in, examine support for password managers and pasting credentials. These checks address different barriers, so the report ties each observation to the relevant criterion and the tested state.
A repair starts with a reproducible barrier.
Your team should be able to turn a finding into a repair ticket. Each record connects the affected task to observed behavior, supporting evidence, and a proposed remedy. Include the relevant WCAG criterion and an owner, then describe what the retest must establish. Keep unverified suspicions separate from confirmed findings.
- Barrier
- A keyboard user reaches Continue, but a sticky consent banner entirely covers it.
- Evidence
- Registration details screen; narrow viewport; tab sequence and screenshot recorded. Reference: WCAG 2.2, 2.4.11 AA.
- Remedy
- Adjust sticky layout and scrolling so the focused control is visible. Check nearby fields and banner controls.
- Retest
- Repeat the recorded keyboard path at the affected width. Confirm the control stays visible and can be activated.
- Ownership
- Frontend owner implements; evaluator repeats the test; unresolved vendor dependencies stay open.
This record is a starting point for investigation, not proof about your website. A similar symptom can have a different cause in another component. The useful report preserves enough context for a developer to reproduce the barrier and for a reviewer to assess whether the repair addresses it.
Put task impact into the repair order.
A long issue list can hide the work that matters most. Prioritize barriers that prevent an essential task, affect shared components, or recur across important journeys. Record severity separately from implementation effort. An easy visual adjustment and a difficult keyboard repair may need very different decisions about when to act.
| Priority | Evidence | Response |
|---|---|---|
| Task blocked | Someone cannot submit, navigate, or recover | Arrange a repair owner and an accessible route while work is underway |
| Shared barrier | A header, form pattern, or component repeats the issue | Repair the source pattern and check its other uses |
| Local barrier | One page or content item needs attention | Assign the content or template change and a specific retest |
A third-party booking tool or embedded widget may need a vendor change. Document that dependency and who will follow it up. If your team cannot change the source, discuss an accessible alternative and its limits. Keep the unresolved barrier visible in the report rather than treating an installed widget as a completed repair.
Close the issue with fresh evidence.
After remediation, repeat the recorded steps on the changed build using the relevant testing combinations. Check the surrounding task as well as the repaired component. A dialog can gain a clear label while still leaving focus in the wrong place when it closes. The retest should capture both the correction and any remaining barrier.
The handoff includes the evaluation scope, issue records, and retest results, with open items clearly identified. An issue's closure records a tested change at a stated time. It does not establish that every page or future update conforms. Any broader conformance statement needs evidence that supports its full scope.
Evidence to retain
- Page or component, tested state, and build/date
- Reproduction steps and relevant WCAG reference
- Repair owner, implementation note, and vendor dependencies
- Retest method, observed result, and remaining limitations
Make the next edit easier to check.
Editors need guidance for the changes they actually make. The handoff can include approved heading patterns, useful image alternatives, and descriptive link examples for your CMS. Identify which changes need a developer's review, such as a new interaction or form component. This keeps routine publishing connected to the tested patterns.
Agree when to review accessibility again, especially after a template change, new plugin, or revised application journey. Routine website maintenance supports site upkeep, while website training helps editors practice their tasks. Accessibility retesting gives those changes a specific review against the agreed criteria. A broader UX audit can examine other usability questions.
Before publishing a content change
- Use the approved heading hierarchy
- Describe an informative image's purpose in context
- Give links a destination or action people can understand
- Check new media and documents within their agreed scope
- Escalate changes to controls, templates, and task flows
Questions before defining the work.
Can an automated tool certify our website?
No. W3C says that a tool alone cannot determine whether a site meets accessibility standards. Scans support evaluation, but manual testing and informed judgment are needed. Ask what pages, states, and criteria the report covers, then check that its conclusions reflect the evidence.
Does WCAG conformance mean we are legally compliant?
Technical conformance work and legal conclusions are different. We define the requested standard and document the evaluation and repairs. Your legal adviser should assess obligations for your organization and jurisdiction. The service does not promise legal protection or a certificate that resolves those obligations.
Can we start with our most important journey?
Yes. A focused evaluation can start with a task such as an application, inquiry, or registration. Include its complete path and relevant states, then state the limits of that scope. Findings can help plan wider work; a focused review cannot establish conformance for untested parts of the website.
What determines the cost and schedule?
The scope depends on unique templates, interaction complexity, content formats, and access to the test environment. The number of testing combinations and whether remediation is included also matter. Share your site, important tasks, existing findings, and target dates so the proposal can define the work and responsibilities.
What should we send before the first discussion?
Send your website URL and the tasks people need to complete. Existing audit reports, known access barriers, and details of third-party tools help establish the starting point. Identify who manages the code and content, and bring any requested standard or reporting requirement from your organization.