Every Accessibility WCAG Compliance Audit check

Missing or meaningless alt text on images is a hard blocker for screen reader users — assistive technology reads the filename, URL, or nothing at all instead of the image's meaning. WCAG 2.2 SC 1.1.1 (Non-text Content) is a Level A requirement: failure makes a site legally non-conformant under Section 508 and the EU Web Accessibility Directive. Beyond compliance, poor alt text degrades SEO, since search crawlers rely on the same attribute to index images.

Why this severity: Critical because missing alt text creates a complete information blackout for blind and low-vision users who rely on screen readers, violating the foundational WCAG 2.2 SC 1.1.1 Level A requirement with no workaround.

Low-contrast text is the most common WCAG failure and directly excludes users with low vision, color blindness, or anyone reading in suboptimal lighting conditions. WCAG 2.2 SC 1.4.3 requires a 4.5:1 ratio for normal text and 3:1 for large text at Level AA; SC 1.4.11 extends the same 3:1 requirement to non-text UI components. Failing this standard exposes SaaS products to ADA Title III litigation, which is disproportionately targeted at e-commerce and fintech.

Why this severity: Critical because contrast failures exclude real users from reading content at all — not a minor UX friction but a hard functional barrier that violates WCAG 2.2 SC 1.4.3 at Level AA.

Custom interactive components that lack accessible names, roles, or state expose AT users to components they cannot identify or operate. A screen reader encountering a nameless div with an onClick handler reads nothing useful; a toggle without `aria-checked` gives no feedback on state. WCAG 2.2 SC 4.1.2 (Name, Role, Value) is Level A — failures break keyboard and AT navigation entirely, affecting users of VoiceOver, NVDA, and JAWS, plus voice control users who activate elements by speaking their visible label.

Why this severity: Critical because components with no accessible name or role are invisible or unpredictable to screen reader users, breaking core functionality and violating WCAG 2.2 SC 4.1.2 at the most foundational Level A.

Uncaptioned video permanently excludes deaf and hard-of-hearing users and anyone in a sound-restricted environment. WCAG 2.2 SC 1.2.2 (Captions — Prerecorded) is a Level A requirement covering all prerecorded video with audio. Section 508 2018 Refresh explicitly requires synchronized captions. Auto-generated captions from YouTube or Vimeo average 80% accuracy and fail the WCAG requirement of being 'accurate' — they are not a compliant substitute without human review.

Why this severity: High because uncaptioned video creates a complete content exclusion for deaf users and violates WCAG 2.2 SC 1.2.2 at Level A, with Section 508 compliance implications for any federally connected product.

Users who are blind or have low vision cannot access purely visual information in a video — demonstrated workflows, screen interactions, on-screen text, or UI layouts are completely opaque without narration. WCAG 2.2 SC 1.2.5 (Audio Description — Prerecorded) is a Level AA requirement. For a product demo or tutorial video, the absence of audio description can make the core value proposition of a SaaS inaccessible to an entire segment of users.

Why this severity: High because visual-only video content is entirely inaccessible to blind users, violating WCAG 2.2 SC 1.2.5 at Level AA with no workaround short of a full text transcript.

Without semantic landmarks and a skip link, keyboard and screen reader users must navigate through the entire navigation on every page load to reach main content. WCAG 2.2 SC 2.4.1 (Bypass Blocks) is a Level A requirement. SC 1.3.1 (Info and Relationships) requires that document structure — headers, navigation, main content — is conveyed in markup, not just visually. A layout built entirely of divs gives screen reader users no way to orient themselves or jump between sections.

Why this severity: High because missing landmarks and skip links force screen reader users to tab through every nav link on every page load, a severe usability barrier that violates WCAG 2.2 SC 2.4.1 Level A.

Screen reader users navigate pages by jumping between headings with shortcut keys (H in JAWS, NVDA, and VoiceOver). Skipped levels break that outline — a user lands on an h3 and cannot tell whether they missed intermediate context or whether the h2 simply does not exist. This violates WCAG 2.2 SC 1.3.1 (Info and Relationships) and SC 2.4.6 (Headings and Labels), and blocks Section 508 refresh 502.3.5 conformance required for federal procurement. Multiple h1 elements fragment the document model and confuse assistive technology about the page's primary topic.

Why this severity: Medium because the page remains functionally usable but navigation for screen reader users is materially degraded and it blocks 508 procurement.

Generic or missing page titles mean screen reader users hear "untitled" or the app name alone when switching browser tabs or windows — they cannot determine which page they are on without reading the content. WCAG 2.2 SC 2.4.2 (Page Titled) is a Level A requirement. Duplicate titles compound the problem for users navigating open tabs. For SPAs, a title that never updates after the initial load means every route is indistinguishable.

Why this severity: High because pages without descriptive, unique titles disorient screen reader users navigating multiple tabs and violate WCAG 2.2 SC 2.4.2 at Level A — the most foundational tier of conformance.

Removing focus indicators with `outline: none` without a replacement makes keyboard navigation invisible. Users who cannot use a mouse — including those with motor disabilities, power users, and anyone without a pointing device — lose their only visual cue for where focus is on the page. WCAG 2.2 SC 2.4.11 (Focus Appearance) at Level AA requires focus indicators to have at least 3:1 contrast against adjacent colors. SC 2.4.7 at Level AA also requires that keyboard focus is always visible.

Why this severity: High because invisible focus indicators make keyboard navigation non-functional, completely excluding motor-impaired users who rely on Tab navigation to operate the interface — a WCAG 2.2 SC 2.4.11 violation.

Navigation that changes location or order between pages violates users' mental model of the site, forcing screen reader users and keyboard navigators to re-learn the layout on every page. WCAG 2.2 SC 3.2.3 (Consistent Navigation) is a Level AA requirement. Users with cognitive disabilities are disproportionately affected — unpredictable navigation increases error rates and abandonment. For any product requiring repeat visits, inconsistent navigation erodes trust.

Why this severity: High because navigation inconsistency forces users with cognitive or motor disabilities to relearn the interface on every page, violating WCAG 2.2 SC 3.2.3 at Level AA and undermining core usability.

When the same action is labeled differently across pages — 'Save' on one page, 'Submit' on another, 'X' vs 'Close' in modals — voice control users cannot reliably activate components by speaking the label they see, and screen reader users build an incorrect model of the interface. WCAG 2.2 SC 3.2.4 (Consistent Identification) is a Level AA requirement. The cost of inconsistency compounds with every repeated interaction for users who depend on assistive technology.

Why this severity: High because inconsistent component labels break voice control activation and disorient screen reader users across pages, violating WCAG 2.2 SC 3.2.4 at Level AA for every affected user interaction.

Silent session expirations destroy work in progress and are disproportionately harmful to users with cognitive disabilities, fine motor impairments, or anyone who types slowly. WCAG 2.2 SC 2.2.1 (Timing Adjustable) is a Level A requirement: if a timed session exists, users must receive at least 20 seconds of warning and the ability to extend it. Losing an unsaved multi-step form or a long text entry to an invisible timeout is not a minor annoyance — it causes real task failure.

Why this severity: High because silent session expiry deletes user work without warning, directly violating WCAG 2.2 SC 2.2.1 at Level A and imposing disproportionate burden on users with cognitive or motor disabilities.

Keyboard accessibility is the baseline for all assistive technology: screen readers, switch access devices, voice control, and eye-tracking all depend on the keyboard interaction model. WCAG 2.2 SC 2.1.1 (Keyboard) is Level A — every function reachable by mouse must have a keyboard equivalent. Mouse-only interactions like hover menus, drag-and-drop without alternative, or right-click context menus completely lock out users who cannot use a pointing device.

Why this severity: Medium because mouse-only interactions create functional exclusions for keyboard users — a WCAG 2.2 SC 2.1.1 Level A violation — though severity is bounded by how many features are affected.

When information is conveyed solely through color, shape, or position — a red asterisk for required fields, a green border for valid inputs, or an icon without text — users with color blindness or those using high-contrast mode miss it entirely. WCAG 2.2 SC 1.3.3 (Sensory Characteristics) and SC 1.4.1 (Use of Color) are both Level A requirements. Form field errors that appear only as a red border leave screen reader users with no feedback at all.

Why this severity: Medium because color-only information creates silent failures for colorblind users and screen readers, violating WCAG 2.2 SC 1.4.1 at Level A without completely blocking all functionality.

Users with low vision frequently zoom to 200% or more using browser zoom. Fixed-width layouts that do not reflow at this zoom level produce horizontal scroll, force users to pan back and forth to read lines, and can overlap or truncate content. WCAG 2.2 SC 1.4.10 (Reflow) is a Level AA requirement: content must reflow to a single column at 320 CSS pixels equivalent (the width at 400% zoom on a 1280px screen) without loss of content or functionality.

Why this severity: Medium because fixed-width layouts that break at 200% zoom create unusable horizontal scroll for low-vision users, violating WCAG 2.2 SC 1.4.10 at Level AA — a significant but partial exclusion.

A focus trap in a modal or overlay that has no Escape key handler and prevents Tab from exiting leaves keyboard users permanently stuck — they cannot dismiss the overlay, access page content, or use browser navigation. WCAG 2.2 SC 2.1.2 (No Keyboard Trap) is a Level A requirement. Note: intentional focus trapping inside an open modal dialog is correct behavior (users should not Tab out of an open modal); the violation is when there is no way to close the dialog at all.

Why this severity: Medium because an accidental focus trap prevents keyboard users from reaching any other part of the interface, but the violation is scoped to components that actively trap rather than the entire page.

An illogical focus order — caused by positive `tabindex` values or CSS positioning that diverges from DOM order — means keyboard users encounter page elements in a sequence that does not match the visual reading order. WCAG 2.2 SC 2.4.3 (Focus Order) is a Level AA requirement. When a user tabs from the footer back to the header before reaching the main content, the interaction model breaks down and tasks become impossible to complete predictably.

Why this severity: Medium because a scrambled tab order disorients keyboard users and makes task completion unreliable, violating WCAG 2.2 SC 2.4.3 at Level AA — harmful but not a complete access blocker.

Multiple links labeled 'Read more' or 'Click here' on the same page are indistinguishable when a screen reader user navigates by links — a common way to skim a page. WCAG 2.2 SC 2.4.4 (Link Purpose in Context) is a Level AA requirement. Users navigating via the NVDA or JAWS links list hear a list of identical 'Read more' labels with no way to tell which article or section each leads to.

Why this severity: Medium because ambiguous link text makes navigation by links nonfunctional for screen reader users, violating WCAG 2.2 SC 2.4.4 at Level AA and forcing sequential reading instead of targeted access.

Form errors that appear only as a red border or generic 'Invalid' message leave screen reader users without actionable feedback — the element's invalid state is not announced, and there is nothing to explain what went wrong or how to fix it. WCAG 2.2 SC 3.3.1 (Error Identification) and SC 3.3.2 (Labels or Instructions) are both Level A requirements. Poor error UX also measurably increases form abandonment rates for all users.

Why this severity: Medium because form errors that are not announced or explained prevent screen reader users from correcting and submitting forms, violating WCAG 2.2 SC 3.3.1 at Level A — a functional blocker for form completion.

Audio that starts without user interaction collides with screen reader speech, rendering the page unusable for blind users until they locate and stop the media — and vestibular users, users on metered connections, and anyone in a quiet shared space are impacted too. This violates WCAG 2.2 SC 1.4.2 (Audio Control) and SC 2.2.2 (Pause, Stop, Hide), plus Section 508 refresh 415.1. Browsers already block autoplay-with-sound by default in most contexts, so shipping it means the hero video either fails silently on Chrome/Safari or blasts audio on the few engines that still honor it.

Why this severity: Low because modern browsers block autoplay audio by default, limiting real-world impact, but it still fails WCAG and 508.

Auto-playing carousels, tickers, or looping animations that run without pause controls cause concentration difficulties for users with attention disorders and can trigger seizures in photosensitive users if they flash. WCAG 2.2 SC 2.2.2 (Pause, Stop, Hide) is a Level A requirement for any animation or auto-updating content that lasts more than 5 seconds. Carousels are the most common violator — they advance silently and provide no control.

Why this severity: Low because the violation is bounded to components with animations longer than 5 seconds, but for affected users — particularly those with vestibular disorders or ADHD — the inability to pause is a real usability blocker per WCAG 2.2 SC 2.2.2.

When tabbing to an element automatically triggers navigation, form submission, or a dialog, keyboard users lose control over when actions happen. WCAG 2.2 SC 3.2.1 (On Focus) is a Level A requirement: receiving focus must never automatically cause a context change. Users with motor disabilities who accidentally land on a focusable element before their intended target will trigger unintended actions — potentially submitting forms or navigating away from work in progress.

Why this severity: Low because focus-triggered navigation is only a violation when `onFocus` handlers explicitly cause context changes — the default HTML behavior is safe, so scope is limited to explicit misuse of the event.

Selecting a checkbox, radio button, or dropdown option that immediately submits a form or navigates to another page surprises all users — but disproportionately harms keyboard users who may activate controls while scanning options rather than making a final choice. WCAG 2.2 SC 3.2.2 (On Input) is a Level A requirement: changing a form control's value must not automatically cause a context change without warning the user first.

Why this severity: Low because `onChange`-triggered navigation is only a violation when it directly causes context changes without an explicit submit action — standard controlled state updates do not violate WCAG 2.2 SC 3.2.2.

Error messages that say 'Invalid' or 'Error' without explaining the constraint leave users — especially those with cognitive disabilities — stuck on forms they cannot fix. WCAG 2.2 SC 3.3.3 (Error Suggestion) is a Level AA requirement: when an input error is detected and suggestions for correction are known, the suggestion must be provided. A password field that says 'Invalid' instead of 'Password must be at least 8 characters with one uppercase letter' causes measurable task abandonment.

Why this severity: Low because the absence of correction suggestions harms completion rates without completely blocking form access — violating WCAG 2.2 SC 3.3.3 at Level AA rather than the more critical Level A SC 3.3.1.

Users who mount phones to wheelchairs or use assistive devices may be locked into one physical orientation and cannot rotate their device. Locking an app to portrait or landscape only permanently excludes these users from the content. WCAG 2.2 SC 1.3.4 (Orientation) is a Level AA requirement: content must not restrict its view to a single display orientation unless it is essential — a piano keyboard app being the canonical example of 'essential.'

Why this severity: Low because orientation locks are an uncommon but deliberate mistake; most apps do not restrict orientation, so scope is limited, but where it occurs it is a hard exclusion violating WCAG 2.2 SC 1.3.4 at Level AA.

Input fields without semantic `type` attributes and `autocomplete` tokens force users to manually re-enter information the browser already knows. For users with motor disabilities, dyslexia, or limited dexterity, autocomplete is not a convenience but a functional requirement. WCAG 2.2 SC 1.3.5 (Identify Input Purpose) is a Level AA requirement: input fields collecting personal data must use the standardized `autocomplete` attribute values from the HTML 5.2 spec so assistive technologies and password managers can populate them.

Why this severity: Low because missing autocomplete attributes degrade usability for motor-impaired users without completely blocking form access — a WCAG 2.2 SC 1.3.5 Level AA compliance gap.

Pinch-to-zoom, two-finger swipe, or multi-touch gesture controls exclude users with one functional hand, tremor, or other conditions that prevent multi-pointer input. WCAG 2.2 SC 2.5.1 (Pointer Gestures) is a Level A requirement: all functionality that uses multipoint or path-based gestures must also be operable with a single pointer using no path constraint. An image gallery that requires pinch-to-zoom with no zoom buttons cannot be used with one finger.

Why this severity: Low because multi-pointer gesture requirements are limited to specific UI components rather than the whole interface, but wherever they occur they create a hard exclusion violating WCAG 2.2 SC 2.5.1 at Level A.

Voice control users activate elements by speaking their visible label. If a button's `aria-label` reads 'Send form data' but the visible text reads 'Submit', a voice control user saying 'Submit' cannot activate it. WCAG 2.2 SC 2.5.3 (Label in Name) is a Level A requirement: the accessible name must contain the visible text label as a substring. This is a common bug introduced when developers override visible labels with different `aria-label` values for screen readers.

Why this severity: Low because the mismatch only breaks voice control activation — screen readers still announce the accessible name — but it fully blocks users of voice control software like Dragon NaturallySpeaking, violating WCAG 2.2 SC 2.5.3 at Level A.

The `lang` attribute on the `<html>` element tells screen readers which language to use for pronunciation. Without it, a French-language site read by VoiceOver defaults to the user's system language — French words get English pronunciation rules and become unintelligible. WCAG 2.2 SC 3.1.1 (Language of Page) is a Level A requirement. It is a one-line fix that has an outsized impact on all non-English content and multilingual applications.

Why this severity: Low because the `lang` attribute is a one-attribute fix with zero functional impact beyond screen reader pronunciation, but its absence violates WCAG 2.2 SC 3.1.1 at Level A for every user who depends on synthesized speech.

Invalid HTML — duplicate IDs, improperly nested elements, unclosed tags — causes screen readers to parse the DOM incorrectly or skip content entirely. WCAG 2.2 SC 4.1.1 (Parsing) is a Level A requirement. Duplicate `id` values break `aria-labelledby`, `aria-describedby`, and `for` associations — the very attributes that connect form labels to inputs and error messages to fields. A heading nested inside a `<button>` confuses the accessibility tree in ways that vary unpredictably across screen readers.

Why this severity: Low because markup errors produce inconsistent rather than universal failures — different browsers and AT combinations are affected differently — but duplicate IDs break ARIA relationships globally throughout the page, violating WCAG 2.2 SC 4.1.1 at Level A.

Toast notifications, form submission confirmations, live search result counts, and loading states are invisible to screen reader users unless explicitly marked with `aria-live`. WCAG 2.2 SC 4.1.3 (Status Messages) is a Level AA requirement added in WCAG 2.1: status messages must be programmatically determinable through role or property so they can be announced without receiving focus. A 'Form saved successfully' toast that a sighted user sees and a screen reader user never hears is a silent UX failure.

Why this severity: Low because the omission silences feedback without blocking the underlying action — users can still submit forms and navigate — but violating WCAG 2.2 SC 4.1.3 at Level AA means screen reader users never know whether their actions succeeded.

Content that flashes more than three times per second can induce photosensitive seizures in users with photosensitive epilepsy — an estimated 3 in 100,000 people worldwide, with real documented harm. WCAG 2.2 SC 2.3.1 (Three Flashes or Below Threshold) is a Level A requirement. This is not a theoretical risk: the Pokémon seizure incident in 1997 caused over 600 hospitalizations. Strobe-effect loading animations and attention-seeking flashing banners are the most common sources.

Why this severity: Low because most applications do not produce high-frequency flashes — this applies only to explicit animations with rapid brightness cycling — but when it occurs it poses a direct physical safety risk and violates WCAG 2.2 SC 2.3.1 at Level A.

Custom stateful components — toggles, accordions, tabs, menus — that do not update their ARIA state attributes when visual state changes give screen reader users stale or wrong information. A toggle that shows 'On' visually but reports `aria-checked="false"` tells blind users the opposite of the truth. WCAG 2.2 SC 4.1.2 (Name, Role, Value) is Level A — the requirement to keep programmatic state in sync with visual state is not optional.

Why this severity: Low because stale ARIA state attributes misinform rather than completely block — users may still interact with the component — but they violate WCAG 2.2 SC 4.1.2 at Level A and cause consistent misinformation for screen reader users.

Custom keyboard shortcuts that override browser defaults — Ctrl+W, Ctrl+T, Ctrl+L — can trap users who reach for familiar browser actions and instead trigger in-app behavior. WCAG 2.2 SC 2.1.4 (Character Key Shortcuts) is a Level A requirement: any keyboard shortcut using only printable characters must be remappable, togglable, or active only on focus. Undocumented shortcuts are also inaccessible to AT users who need to know what keyboard controls are available.

Why this severity: Info because keyboard shortcut conflicts are an edge-case usability issue that affects only specific key combinations — the violation exists when shortcuts genuinely override browser defaults or lack documentation, not merely because shortcuts exist.

Manual accessibility testing catches only what reviewers know to look for and only in the code paths they exercise. Automated scanning with axe-core or pa11y catches a deterministic subset of WCAG violations — missing alt text, color contrast failures, invalid ARIA — on every build, preventing regressions from silently landing in production. Without CI integration, accessibility quality degrades with each unchecked pull request. WCAG 2.2 SC 1.1.1 and Section 508 compliance require ongoing verification, not one-time review.

Why this severity: Info because automated scanning is an operational practice rather than a direct WCAG violation — its absence does not immediately fail any single criterion, but it guarantees regressions accumulate undetected across the codebase.

Automated tools catch roughly 30–40% of WCAG failures. The remainder — focus management, ARIA live region behavior, reading order, screen reader announcement timing — only surface during testing with real assistive technology. Without documented screen reader testing, an app can pass all automated checks and still fail VoiceOver on Safari or NVDA on Chrome in ways that make core features unusable. For any product claiming WCAG compliance or seeking Section 508 contracts, AT testing evidence is a prerequisite.

Why this severity: Info because the absence of AT testing is a process gap rather than a direct failure of any single WCAG criterion — but it means the remaining ~60% of potential violations go undetected and the compliance claim cannot be substantiated.

Color contrast requirements cover not just body text but icons, data visualization labels, chart lines, and UI component boundaries. A single automated contrast check on the homepage misses theme-specific issues in dark mode, dynamic states like hover and focus, and SVG-based content. WCAG 2.2 SC 1.4.3 (Contrast Minimum) applies to all text in all states; SC 1.4.11 (Non-text Contrast) applies to UI components and graphical objects. Without a documented audit, both can fail silently in edge cases the main audit path never exercises.

Why this severity: Info because contrast issues in edge-case states (dark mode, hover, data viz) are unlikely to appear in automated scans — the gap is an audit process weakness, not a confirmed WCAG 2.2 SC 1.4.3 violation in the main path.

Publishing an accessibility conformance statement demonstrates that the organization has audited its product against WCAG and is accountable for the result. Without one, users with disabilities have no way to know what level of accessibility to expect, what workarounds are documented, or who to contact when they hit a barrier. For products serving government, healthcare, or education markets, a published conformance statement is often a procurement requirement under Section 508, EN 301 549, or the EU Web Accessibility Directive.

Why this severity: Info because the absence of a conformance statement is a transparency and procurement gap rather than a functional WCAG failure — no single criterion is violated by the missing document, but the organization cannot credibly claim compliance without it.