Accessibility Audit

You may have inherited a website, received feedback from a customer, or reached a point in a redesign where the existing experience needs a closer examination. You may have an automated report full of flags without knowing which ones matter or what resolving them involves.

An audit creates a defined investigation around that uncertainty.

It can reveal a content issue, a design decision, an implementation problem, or a dependency on a third-party service. Some findings may relate to a shared component used throughout the product. Others may occur only in a particular state or task.

Understanding the difference helps us recommend changes at the right level. Otherwise, a team may repair individual screens while the same underlying problem continues to appear elsewhere.

The word “website” can conceal a large amount of variation. Public pages, logged-in areas, forms, search, documents, media, payment services, and different user roles may all belong to the experience.

We begin by identifying the product boundaries, important tasks, relevant standards and target level, technical environment, and known concerns. We agree access to the material and systems needed for evaluation.

Scope should account for meaningful states, not only a list of page addresses. A form before submission is different from that form showing an error. A menu that appears on every page may introduce a repeated barrier. A purchase journey may leave the main site and depend on another provider.

Where sampling is appropriate, we document what was selected and why. We also record exclusions and limitations. A limited review must not silently become a claim that every part of the product has been examined.

That clarity helps the client understand both the findings and the questions the audit cannot answer yet.

A useful finding makes a barrier understandable enough to act on.

Accessibility Testing is the family of methods that contributes evidence to the audit. The audit gives that evaluation a defined scope, a reporting structure, and a path toward action.

Automated checks can identify certain patterns and help examine material efficiently. Manual review and interaction testing are needed for issues those checks cannot resolve. Depending on the experience, the work may include keyboard use, focus behavior, screen-reader interaction, content structure, visual presentation, media, and relevant states.

The evaluation environment matters. Browser, device, assistive technology, product version, and testing conditions can affect the interpretation of a finding. The report should make important conditions traceable.

We can shape and coordinate the engagement with appropriate accessibility specialists, designers, developers, and content contributors. The scope determines which expertise is needed and who is responsible for each part of the evaluation.

User participation can add evidence about the lived experience of a barrier. It is valuable alongside technical evaluation, not a substitute for checking the agreed requirements. Participants should not be asked to represent everyone with a similar disability.

A support dialog in a membership portal gives us a concrete task to examine with the people responsible for the experience. Opening the dialog is only the beginning: a person also needs to reach its controls, understand the fields, send the request and recognize what happened.

During the agreed evaluation, we examine whether keyboard focus and the visible interface stay connected. If focus remains behind an open modal, we document the behavior in the relevant environment, how it can be reproduced and its effect on the support task. The applicable evaluation criterion follows from that investigation, not a judgment based on a screenshot alone.

We then work with the team to understand where the component is used. A repeated barrier may need a shared repair rather than separate adjustments to individual pages.

Where a third-party tool owns the dialog, the finding should help the client act: what can be configured, what needs the provider's response and what useful interim access can be offered? An interim route may help someone obtain support without making the original barrier disappear.

The audit connects evidence, human consequence and responsibility. That gives the client and implementation team a shared basis for deciding what happens next.

The format may vary, but a finding should make enough information available for the next person to understand and investigate it.

• Location and context: the page, component, task, role, or state involved.
• Evidence: steps to reproduce the behavior and an appropriate record of what occurred.
• Impact: how the issue interferes with access or use, and the conditions in which that happens.
• Evaluation basis: the relevant criterion or requirement, with broader usability observations identified separately.
• Recommendation: the intended improvement, implementation considerations, and dependencies.
• Priority and follow-up: an explained priority, proposed owner, and what needs to be checked after a change.

Recommendations should be specific enough to move the work forward without pretending that every repair can be fully designed inside the audit. A finding may require further design exploration, a content decision, a technical investigation, or specialist input.

We distinguish observed behavior, interpretation, and proposed response. Those distinctions help the team discuss a recommendation without losing the evidence behind it.

A repeated issue can create hundreds of report entries while originating in one component. A single barrier can prevent someone from completing an essential task.

We consider the impact on people, the tasks affected, the breadth of the problem, dependencies, and the effort needed to investigate and address it. Priority should have a rationale the team can understand.

Low recorded traffic is not, by itself, a reason to dismiss an access barrier. The difficulty may be affecting whether someone can participate at all.

Time and budget can influence how work is sequenced, but they do not change what a finding means. If a repair is deferred, that decision and the remaining limitation should stay visible.

The roadmap can separate immediate actions, shared-component improvements, content work, provider dependencies, and changes requiring deeper design or development. That makes progress discussable without making a promise that everything can be resolved at once.

We already have an automated report. Can you use it? Yes. It can help identify what deserves investigation. We check the current experience and agree the human evaluation needed; a tool's findings are useful input, not a complete account of access.

Are repairs part of the audit? Evaluation, implementation and retesting can be coordinated within a wider engagement, but their responsibilities remain explicit. We can also prepare the findings for your existing team and support the decisions that follow.

An audit identifies and explains issues; remediation changes the experience. Retesting examines whether the changes addressed the relevant findings and whether further attention is needed.

We agree which of those activities belongs in the engagement. Abstraction can help with design, content, development, and coordination, or prepare findings for your in-house team and specialist partners to implement.

Follow-up should preserve a meaningful record: what was changed, what was evaluated again, what remains open, and where a dependency or new issue needs attention. A resolved ticket is an administrative status; it should not stand in for examining the changed behavior.

The report should give the next person a way forward.

The client retains the report and the agreed supporting material as a reference for decisions. Recommendations and lessons can also inform component guidance, editorial practices, and future work.

WCAG provides a technical reference for web accessibility evaluation. The report should identify the version, target level, evaluated material, methods, and limits relevant to the work.

An automated score alone is not proof of conformance. An audit report is not legal certification, and a favorable result for selected material should not be presented as a guarantee that no one will encounter a barrier anywhere in the product.

Legal obligations and their interpretation require appropriate legal advice. Our role is to help make the design and technical situation clear and support a responsible response.

New content, components, integrations, and releases can change the experience after it has been evaluated. The report remains useful evidence about its stated scope and date; it is not permanent assurance about everything that follows.

Discover → Define → Explore → Design / Develop / Market → Learn → Advance → Discover

Digital Accessibility is the broader discipline of designing, implementing, evaluating, and improving access. An Accessibility Audit provides a defined evaluation within that work.

A UX Audit examines the wider experience; a UI Design Audit focuses on the interface. Either may surface accessibility concerns, but a general review should not be represented as a comprehensive accessibility evaluation without the necessary scope and methods.

Digital Design Systems can carry improvements across shared components. Content Operations can help maintain accessible material as it changes. Design Thinking places the findings back into the learning process: what we discover affects what we define, explore, and improve next.

An Accessibility Audit can be engaged independently or as part of a wider redesign and improvement effort. Bring us the product, existing reports, customer feedback, or the uncertainty you want to resolve.

We can help establish a useful scope, bring the appropriate expertise together, and develop a path from findings to action with your team.

Contact Us