Accessibility Auditing

Accessibility auditing is the systematic process of evaluating a digital interface — a website, web application, or prototype — against recognized accessibility standards, most commonly the Web Content Accessibility Guidelines (WCAG), to identify barriers that prevent users with disabilities from accessing or using the product effectively. An audit is not a single action but a disciplined, multi-layered methodology that combines automated tools, manual inspection, and direct testing with assistive technologies. Each layer reveals a different class of problem, and only together do they produce a thorough picture of an interface's accessibility health. The end goal is not merely a list of failures but a prioritized, actionable remediation plan that design and engineering teams can act on with clarity and confidence.

Understanding why this matters requires appreciating the breadth of the affected audience. Users with visual impairments navigate with screen readers or rely on high-contrast displays. Users with motor disabilities may use only a keyboard, a switch device, or eye-tracking hardware. Users with cognitive disabilities benefit from predictable layouts, clear labels, and error prevention. An interface that has never been audited routinely contains dozens of barriers invisible to sighted, mouse-using testers — barriers that effectively lock out a significant portion of the population and, in many jurisdictions, expose organizations to legal liability under laws such as the Americans with Disabilities Act (ADA) or the European Accessibility Act.

Audit Methods and Tools

A robust audit draws on three complementary methods, each targeting a distinct category of accessibility problem.

Automated accessibility scanners are software tools that parse a page's DOM and CSS, then flag violations of rules that can be evaluated algorithmically. Common findings include missing alt attributes on images, insufficient color contrast ratios, form inputs without associated <label> elements, buttons or links with no accessible name, and duplicate id attributes that break ARIA relationships. Popular tools include axe DevTools (available as a browser extension and as a CI-integrated library), Lighthouse (built into Chrome DevTools), WAVE (a browser extension from WebAIM), and IBM Equal Access Checker. These tools are fast and highly repeatable, making them ideal for integration into automated testing pipelines so that regressions are caught before code is merged.

However, automated tools are limited by design. Research consistently shows they can only detect approximately 30–40% of WCAG failures. They cannot determine whether a visible focus indicator is sufficiently clear, whether a modal dialog traps focus correctly under all interaction paths, whether the announced reading order of a complex data table conveys the intended meaning, or whether an error message is genuinely understandable to a user unfamiliar with technical jargon. These qualitative, contextual judgments require human evaluation.

Manual keyboard-only testing is indispensable for verifying interaction patterns that no scanner can evaluate. The tester removes the mouse entirely and navigates the full interface using only the keyboard — primarily Tab and Shift+Tab to move between focusable elements, Enter and Space to activate controls, arrow keys for widgets like menus, sliders, and radio groups, and Escape to dismiss dialogs. The tester checks that:

• Every interactive element receives a visible focus indicator — not just a faint browser default outline, but a clearly perceivable ring or highlight that meets WCAG 2.2's Focus Appearance criterion (minimum area and contrast).
• Focus order follows a logical reading sequence — typically left-to-right, top-to-bottom in Western layouts — so that the journey through the page makes semantic sense.
• No keyboard trap exists, meaning the user can always move focus out of any component without resorting to special escape sequences undocumented in the interface. A classic failure point is a custom modal dialog that does not return focus to a predictable element on close.
• All functionality available via mouse is also achievable by keyboard alone — drag-and-drop operations, hover-triggered tooltips with additional information, and custom dropdown menus built with <div> elements rather than native <select> controls are frequent failure areas.

Screen reader testing validates the assistive technology experience — what a blind or low-vision user actually hears when they navigate the interface. Screen readers do not simply read text on screen; they interpret the accessibility tree, a structured representation of the page built from semantic HTML and ARIA attributes. Because different screen readers on different browsers produce different accessibility trees, testing across combinations is important. The standard pairings used in professional audits are:

During screen reader testing, the auditor listens critically: Is each image's alt text meaningful in context? Does a decorative icon carry an empty alt="" so it is silently skipped? When a form validation error occurs, is the error announced automatically or must the user hunt for it? Does a carousel announce its current slide count? Is a data table announced with its column and row headers so the relationship between cell and heading is clear when navigating cell by cell? These are questions only live screen reader interaction can answer.

Auditing Your Own Prototype

When evaluating a prototype — a Figma mockup exported to HTML, a coded prototype, or a staging environment — the auditor adapts these general methods to the specific fidelity and context of what is being tested. A structured approach prevents overlooked areas and keeps findings consistent.

Keyboard-only navigation review is the recommended first step because it requires no special tooling and immediately surfaces the most fundamental interaction failures. Open the prototype in a browser, disconnect or ignore the mouse, and attempt to complete every core user journey — registration, form submission, navigation between pages, activating a modal, completing a purchase. As you move through the interface, note every location where focus becomes invisible, jumps unexpectedly, loops in a trap, or simply never arrives on an element that appears interactive. This pass often reveals architectural problems — components built with non-semantic elements — that will require structural fixes rather than surface-level attribute changes.

Color contrast analysis is the next layer. Using a tool such as the Colour Contrast Analyser (a free desktop application from TPGi), WebAIM's Contrast Checker, or the color picker built into axe DevTools, the auditor samples every meaningful text-and-background combination in the prototype. WCAG 2.1 Level AA requires:

• A contrast ratio of at least 4.5:1 for normal text (below 18pt, or below 14pt bold).
• A contrast ratio of at least 3:1 for large text (18pt or larger, or 14pt bold or larger).
• A contrast ratio of at least 3:1 for non-text UI components such as button borders, input field borders, and focus indicators.

Common failure patterns include light grey placeholder text in form inputs, white text on medium-brand-color buttons, and disabled-state text that is indistinguishable from the background. When checking contrast, remember to test every interactive state — default, hover, focus, active, and visited — because a button may pass in its default state but fail on its focus or hover state.

Inspection of interactive elements for accessible names is a critical check that automated tools partially cover but that requires contextual judgment. Every button, link, form control, and custom widget must have an accessible name that accurately describes its purpose. The accessible name is what a screen reader announces and what voice-control users speak to activate a control. Sources of accessible names, in order of precedence as defined by the accessible name computation algorithm, include:

• aria-labelledby pointing to visible text elsewhere on the page
• aria-label providing an invisible string directly on the element
• A native HTML <label> associated via for/id or by wrapping the input
• The element's own visible text content (for buttons and links)
• The alt attribute for images used as controls
• The title attribute as a last resort (unreliable and not recommended)

A prototype review should inspect every icon-only button (the trash icon, the share icon, the ellipsis menu) to confirm an accessible name is provided. It should verify that linked images carry descriptive alt text. It should confirm that every form input — text fields, checkboxes, radio buttons, selects, date pickers — is programmatically associated with a visible label, not merely positioned adjacent to one.

Documentation of each finding should occur in parallel with testing, not after. Each finding is recorded immediately with four pieces of information: the affected component (identified by page, component name, or screenshot annotation), the relevant WCAG success criterion (referenced by number and name, such as 1.4.3 Contrast (Minimum)), the observed failure (a specific, factual description of what was found), and a severity rating. Recording findings in real time prevents the auditor from relying on memory and ensures that even minor issues discovered during a keyboard pass are not lost by the time the formal report is assembled.

Prioritizing Accessibility Findings

Not all accessibility failures carry equal weight. A pragmatic remediation strategy requires prioritizing findings by the severity of the barrier they create for users. A widely used three-tier severity model maps directly to the impact on a user's ability to accomplish goals.

Critical issues are those that completely prevent a user from completing a core task. They represent total blockers. Examples include a login form with no accessible labels, making it impossible for a screen reader user to identify the username and password fields; a keyboard trap inside a navigation menu that a keyboard user cannot escape; or a modal dialog that never receives focus, meaning an assistive technology user cannot interact with it. A critical issue does not merely cause frustration — it makes a feature entirely inaccessible. These findings must be resolved at the highest priority, ideally before any other development work on the affected area proceeds, and certainly before a feature launches.

Serious issues create significant barriers that substantially degrade the user experience but may have partial workarounds — alternative paths a user could theoretically take, though often with considerable effort. An example is a complex custom dropdown built entirely with <div> elements and JavaScript that is mostly keyboard-operable but mispronounces item counts to screen readers, or a multi-step form where error messages appear visually but are not announced, requiring the user to manually navigate back to find where the problem is. Serious issues should be addressed before a product launches and are treated as near-critical in any well-governed accessibility program.

Minor issues cause friction and reduce quality but do not block access to content or functionality. An example is a tooltip that conveys supplementary (but non-essential) information and lacks a keyboard trigger, or a decorative image that carries a redundant alt attribute describing its appearance when it adds no meaning. Minor issues are real failures and should be documented and tracked, but they are appropriate candidates for scheduling in an iterative improvement backlog rather than holding a launch.

Severity should also be weighted by the frequency of the affected component. A minor contrast failure in a once-per-session modal carries less urgency than the same minor contrast failure in a global navigation element rendered on every page of the product.

Writing Accessibility Findings and Recommendations

The quality of an audit's written output determines how actionable it is. A finding that says only "button is not accessible" gives a developer nothing to work with. A well-structured finding communicates exactly what is wrong, exactly where it is, exactly why it matters, and exactly how to fix it.

Each finding should contain the following components:

• Affected element: Identify the component by name, page, screenshot reference, or code snippet. For example: "The 'Submit' button on the Contact Form page (contact.html)" or "All icon-only buttons in the comment thread component."
• WCAG criterion violated: Reference the specific success criterion by number, name, and conformance level. For example: "WCAG 2.1 Success Criterion 4.1.2 Name, Role, Value (Level A)." This gives designers, developers, and accessibility leads a shared vocabulary and links the finding to a formal standard, which is important for legal and compliance contexts.
• Observed failure: Describe what was found in factual, observable terms. Avoid vague language. For example: "The search icon button renders as <button><svg>...</svg></button> with no visible text, no aria-label, and no title. When navigated to with NVDA and Chrome, the screen reader announces 'button' with no name, providing no indication of the button's purpose."
• Specific, actionable recommendation: Do not simply say "fix the accessible name." Describe the exact change. For example: "Add aria-label="Search" to the <button> element: <button aria-label="Search">. Alternatively, add a visually hidden <span class="sr-only">Search</span> inside the button as its text content." When there are multiple valid remediation paths, list them in order of recommendation so the developer understands the preferred approach.
• User impact statement: Articulate the real-world consequence of the failure for an actual user. This is the component most frequently omitted and most valuable for stakeholder communication. For example: "A blind user navigating by screen reader encounters this button as an unlabeled control. Without knowing the button's purpose, they cannot determine whether to activate it or skip it, forcing them to rely on trial and error or abandon the task entirely." Impact statements translate technical failures into human experiences, which helps product owners, project managers, and business stakeholders understand why accessibility matters and prioritize investment accordingly.

The following example illustrates a complete, well-formed finding:

Finding: Unlabeled icon button in comment thread component
Severity: Critical
WCAG Criterion: 4.1.2 Name, Role, Value (Level A)
Affected Element: "Delete comment" button (icon only) rendered as:
  <button class="delete-btn">
    <svg aria-hidden="true">...</svg>
  </button>

Observed Failure:
The button has no accessible name. The SVG is correctly hidden
from the accessibility tree via aria-hidden="true", but no
alternative name is provided on the <button> element itself.
NVDA + Chrome announces: "button". JAWS + Chrome announces: "button".

Recommendation:
Add aria-label="Delete comment" to the <button> element:
  <button class="delete-btn" aria-label="Delete comment">
If the label must reflect dynamic context (e.g., which comment),
use aria-label="Delete comment by [author name]" populated from
the data model.

User Impact:
A screen reader user navigating the comment thread encounters
multiple unlabeled buttons in sequence. They cannot determine
which button deletes, edits, or reports a comment. They risk
activating the wrong action — including irreversibly deleting
their own content — or are forced to abandon the interaction.

Structuring every finding in this way — element, criterion, failure, recommendation, impact — creates a document that serves multiple audiences simultaneously. Developers receive precise technical instructions. Designers see the affected component in context. Product owners understand business and human risk. Accessibility leads can track remediation against WCAG conformance targets. The audit report becomes not merely a record of failures but a roadmap for building a more inclusive product.