Every Accessibility Basics Audit check

Unlabeled form inputs are completely invisible to screen readers — when a blind user tabs to an input field, their assistive technology announces only 'edit text' or 'text field' with no indication of what information belongs there. This violates WCAG 2.2 SC 1.3.1 (Info and Relationships) and SC 3.3.2 (Labels or Instructions), and constitutes a Section 508 2018 Refresh 502.3.3 failure. In a login form, the user cannot tell whether they are in the username or password field. In a checkout form, they cannot distinguish billing address from shipping address. The practical consequence: screen reader users abandon the form entirely, creating both an ADA compliance liability and lost conversions.

Why this severity: Critical because unlabeled inputs make forms completely unusable for screen reader users, constituting an absolute barrier rather than a reduced experience.

When required fields are marked only by a red asterisk or red border color, users with color vision deficiencies and screen reader users cannot determine which fields must be filled before submission. WCAG 2.2 SC 3.3.2 (Labels or Instructions) mandates that users receive adequate instructions before encountering a field, and SC 1.3.1 (Info and Relationships) requires that programmatic relationships reflect visual ones. Section 508 2018 Refresh 502.3.3 enforces the same. A user who submits an incomplete form and receives a generic 'form has errors' message has no way to identify which fields they missed. Forms that fail on submission without pre-warning required fields also violate SC 3.3.1 (Error Identification). The downstream impact is user frustration, elevated support tickets, and ADA litigation exposure.

Why this severity: Critical because missing required-field indicators cause form submission failures that screen reader users cannot diagnose, blocking task completion entirely.

A page composed entirely of `<div>` wrappers presents a flat, unnavigable structure to screen reader users. Screen readers expose a landmark navigation menu (typically via a key like `R` or a rotor gesture) that lets users jump directly to main content, skip the navigation, or jump to the footer — but only when semantic landmark elements exist. Without them, keyboard-only users must Tab through every navigation link on every page load before reaching content. WCAG 2.2 SC 2.4.1 (Bypass Blocks) and SC 1.3.6 (Identify Purpose) are both violated. Section 508 2018 Refresh 502.3.5 requires programmatic determination of page structure. This affects all keyboard users, not just screen reader users: poor landmark structure also breaks browser reader mode and assistive browser extensions.

Why this severity: High because missing landmark regions force keyboard users to tab through all navigation on every page, significantly degrading usability even if no absolute barrier exists.

Icon-only buttons — a close X, a hamburger menu, a heart for favorites — read as 'button' or are skipped entirely by screen readers when they carry no accessible name. WCAG 2.2 SC 4.1.2 (Name, Role, Value) requires every UI component to expose a name to assistive technology. SC 2.4.6 (Headings and Labels) requires labels to be descriptive. Section 508 2018 Refresh 502.3.1 mandates that all object information be programmatically determinable. A screen reader user navigating a list of 'View Details' links on a product listing page encounters identical announcements with no way to distinguish which product each link targets — this is a known and documented navigation failure mode. The business consequence is that entire interaction patterns are unusable by an estimated 7.5 million screen reader users in the US alone.

Why this severity: High because nameless interactive elements render entire interaction flows inaccessible to screen reader users, blocking navigation and task completion.

Removing the focus outline with `outline: none` — one of the most common CSS resets — makes it impossible for keyboard-only users to know where they are on the page. This affects sighted keyboard users (power users, users with motor disabilities who cannot use a mouse) as well as those navigating by switch access or sequential navigation. WCAG 2.2 SC 2.4.7 (Focus Visible) requires a visible focus indicator; SC 2.4.11 (Focus Appearance, AA in 2.2) adds a minimum area and contrast requirement of 3:1. SC 2.4.3 (Focus Order) is violated when positive `tabindex` values reorder focus in ways that conflict with visual layout. Section 508 2018 Refresh 503.4 requires keyboard navigation support. An invisible focus state means a keyboard user literally cannot use the application — they click Tab repeatedly with no visible response.

Why this severity: High because invisible or illogical focus indicators prevent keyboard-only users from knowing their position on the page, making navigation functionally impossible.

Applying `role="button"` to a `<button>` element, or `role="navigation"` to a `<nav>`, creates conflicting semantics in the accessibility tree that screen readers must reconcile — some resolve the conflict predictably, others do not. More dangerously, using `<div role="heading">` instead of an `<h2>` loses the implicit heading level, which assistive technology uses for document outline navigation. WCAG 2.2 SC 4.1.2 (Name, Role, Value) requires that roles accurately represent the element's function. SC 1.3.1 (Info and Relationships) requires structure to be programmatically determinable. Section 508 2018 Refresh 502.3.1 enforces the same. The practical failure mode: screen reader users who navigate by headings (the most common navigation strategy) find that custom `role="heading"` elements without `aria-level` are announced inconsistently or omitted from the heading list entirely.

Why this severity: Low because redundant roles rarely block usage outright but create unnecessary complexity and occasional screen reader inconsistencies across browsers.

When a form validation error appears as inline red text, or a toast notification slides in from the corner, screen reader users receive no indication that anything has changed — their focus is still on the input field or wherever it was when they triggered the action. This is a silent failure from the assistive technology's perspective. WCAG 2.2 SC 4.1.3 (Status Messages) requires that status messages be programmatically determinable by assistive technology without receiving focus. SC 1.3.1 (Info and Relationships) covers the relationship between an error message and its field. Section 508 2018 Refresh 502.3.14 requires that changes in status be programmatically determinable. The practical consequence: screen reader users submit forms with errors and receive no feedback, cycling through submission repeatedly with no understanding of why the form fails.

Why this severity: Medium because the failure silences important feedback for screen reader users without completely blocking form access for sighted users.

A modal dialog that does not trap focus allows Tab presses to reach background content — visually hidden behind the overlay — while screen reader users may never realize the modal is open at all. WCAG 2.2 SC 2.1.2 (No Keyboard Trap) is often misread as 'don't trap focus,' but the actual requirement is that users can both enter and exit a trap using standard keys (Escape closes the modal). SC 2.4.3 (Focus Order) and SC 4.1.2 (Name, Role, Value) require modals to be correctly marked up with `role="dialog"` and `aria-modal="true"`. Section 508 2018 Refresh 502.3.1 covers programmatic determinability of role. When `aria-modal` is absent, some screen readers ignore the visual overlay entirely and continue reading background content as if the modal weren't there, leading users to interact with controls they cannot see.

Why this severity: Medium because focus-trap failures create confusing and disorienting experiences for keyboard users without blocking all access to the application.

A `<div onClick={handler}>` that renders as a clickable UI element with no keyboard equivalent shuts out every user who does not use a pointer device — keyboard-only users, switch access users, and users on devices with no pointing hardware. WCAG 2.2 SC 2.1.1 (Keyboard) requires all functionality to be operable via keyboard without requiring specific timings. Section 508 2018 Refresh 407.6 mandates keyboard operation for all standard functions. This is not a fringe scenario: approximately 26% of US adults with disabilities have a mobility disability affecting computer use. The most common failure patterns are custom dropdown menus that require hover/click, carousels that accept only swipe gestures, and custom select components built on `<div>` elements without `role="option"` and Arrow key handling.

Why this severity: Critical because mouse-only interactive elements completely block keyboard users from performing those actions, constituting an absolute access barrier.

A focus indicator removed by `outline: none` in a CSS reset — one of the most ubiquitous accessibility mistakes — means that a sighted keyboard user cannot determine which element is active. Without knowing where focus is, they cannot predict what Enter or Space will do. WCAG 2.2 SC 2.4.7 (Focus Visible) is a long-standing Level AA requirement; SC 2.4.11 (Focus Appearance) in WCAG 2.2 adds minimum geometric constraints: the focus indicator must have a contrast ratio of at least 3:1 against adjacent colors and must enclose a perimeter of at least the CSS `outline` equivalent. SC 1.4.11 (Non-text Contrast) governs UI component contrast. Section 508 2018 Refresh 302.7 requires visual accessibility. The specific failure: Tailwind's `ring` utility defaults to a `ring-offset` that is invisible on dark backgrounds, creating a technically-present but practically-invisible focus indicator.

Why this severity: Critical because invisible focus indicators make keyboard navigation completely unusable for sighted keyboard users, affecting millions of users who rely on keyboard navigation.

Custom keyboard shortcuts that use single-character keys (letters, numbers, punctuation) without a modifier conflict with screen reader commands — screen readers intercept single-key presses as navigation commands. WCAG 2.2 SC 2.1.4 (Character Key Shortcuts) requires that single-character shortcuts can be turned off, remapped, or are only active when the relevant component has focus. Section 508 2018 Refresh 407.7 covers key repeat and shortcut behavior. The concrete failure: an application that binds 'S' to search while a screen reader user is navigating will trigger the search instead of reading the next element. Undocumented shortcuts compound the problem — users cannot discover or avoid them. Browser shortcut conflicts (Ctrl+L for address bar, Ctrl+T for new tab) can trap or disorient all keyboard users.

Why this severity: High because single-key shortcuts that conflict with screen reader commands actively disrupt assistive technology navigation without any fallback.

Without a skip link, a keyboard user visiting a page with a navigation menu of 30 items must press Tab 30 times before reaching the main content — on every single page load. This is not a theoretical concern; it is a documented and cited reason why keyboard users abandon websites. WCAG 2.2 SC 2.4.1 (Bypass Blocks) specifically requires a mechanism to skip repeated blocks of content. Section 508 2018 Refresh 302.1 requires a clear path to primary functionality. The skip link requirement applies regardless of whether your navigation is long or short — it is a baseline expectation for any multi-page site. SPA route transitions that re-render navigation without a skip link create the same problem on every virtual page navigation.

Why this severity: Medium because the missing skip link significantly degrades keyboard navigation efficiency but does not create an absolute barrier — all content remains reachable via Tab.

Focus order that conflicts with visual reading order creates a disorienting experience where a keyboard user presses Tab and the cursor jumps from the page header to the sidebar, then back to main content, then to a footer element — with no visual logic connecting the sequence. WCAG 2.2 SC 2.4.3 (Focus Order) requires that focus order preserve meaning and operability. SC 1.3.2 (Meaningful Sequence) requires that the reading sequence be programmatically determinable. Section 508 2018 Refresh 502.3.5 covers information flow. The common failure pattern is a CSS flexbox or grid layout where `order` or `flex-direction: row-reverse` rearranges visual layout while the DOM order — which drives tab order — remains unchanged, causing Tab to skip backwards through the visual layout.

Why this severity: Medium because unpredictable focus order causes disorientation and navigation errors but does not prevent users from eventually reaching content via repeated tabbing.

A tab bar with 10 individual tabs, each focusable by Tab key, forces a keyboard user to press Tab 10 times to move through the tab list before reaching content — even though they might only want the fifth tab. This is the exact scenario roving tabindex solves. WCAG 2.2 SC 2.1.1 (Keyboard) requires keyboard operability; SC 2.4.3 (Focus Order) requires a logical, efficient focus sequence. Section 508 2018 Refresh 407.6 governs keyboard navigation. The ARIA Authoring Practices Guide specifies roving tabindex as the correct pattern for composite widgets: tabs, radio groups, menu bars, tree views, and listboxes. Implementing individual tabstops for every item in a group is both a deviation from the ARIA spec and a usability failure for keyboard users.

Why this severity: Medium because the absence of roving tabindex creates significant keyboard navigation overhead without blocking access to individual widget items entirely.

When a modal dialog closes and focus drops to the document `<body>` or jumps to the page top, the keyboard user loses their place entirely. They must navigate from the beginning of the page to find where they were working. In a long page with complex navigation, this can require dozens of Tab presses. WCAG 2.2 SC 2.4.3 (Focus Order) requires that focus order preserve meaning and operability. SC 3.2.2 (On Input) guards against unexpected context changes. Section 508 2018 Refresh 302.1 covers programmatic determinability of primary functionality. The specific failure manifests in delete confirmation dialogs: user clicks Delete, dialog appears, user confirms, dialog closes — and focus is gone. The user cannot easily verify the deletion happened or continue their workflow.

Why this severity: Low because focus loss after dialog close is disorienting and adds navigation overhead but does not prevent users from accessing content with additional keystrokes.

When every page of an application shares the same `<title>` tag — often the product name alone — screen reader users who open multiple browser tabs cannot distinguish between them. Browser tab switchers read the title aloud; a list of identically-titled tabs gives no navigational information. WCAG 2.2 SC 2.4.2 (Page Titled) requires that pages have titles that describe their topic or purpose. Section 508 2018 Refresh 501.1 mandates that content conform to WCAG 2.2. In single-page applications, client-side route transitions that do not update `document.title` also fail SC 2.4.2 — the title announces 'Home' even when the user has navigated to their account settings. This affects screen reader users navigating via browser tabs and sighted users managing many open tabs simultaneously.

Why this severity: Low because generic page titles impair navigation efficiency and orientation without blocking access to page content directly.

Two unlabeled `<nav>` elements on the same page — a main navigation and a footer navigation — are indistinguishable in a screen reader's landmark navigation list. Screen readers present landmarks as a list ('navigation, navigation') and users cannot tell which is which without entering each one. WCAG 2.2 SC 1.3.1 (Info and Relationships) requires semantic relationships to be programmatically exposed. SC 2.4.6 (Headings and Labels) requires that labels, when present, be descriptive. Section 508 2018 Refresh 502.3.5 covers information flow relationships. The specific failure: a screen reader user invokes landmark navigation, sees two 'navigation' entries, enters the wrong one, and must back out and try the other. This adds unnecessary navigation overhead on every page.

Why this severity: Info because unlabeled duplicate landmarks add minor navigation friction without preventing access to any content or functionality.

A custom dropdown component whose accessible name computes to 'Select' rather than 'Select country' leaves screen reader users without enough context to understand the control's purpose before interacting with it. The accessible name computation algorithm (accname-1.1) traverses text content, `aria-labelledby`, `aria-label`, and `title` in a defined priority order — getting this wrong produces names that are either missing, duplicated, or meaninglessly generic. WCAG 2.2 SC 4.1.2 (Name, Role, Value) requires that every UI component exposes a correct name to assistive technology. Section 508 2018 Refresh 502.3.1 covers the same. The failure is non-obvious: the component may appear labeled to a sighted user, but the accessibility tree — which tools like Axe and screen readers read — computes the name from different inputs than the visual rendering.

Why this severity: Info because incorrect name computation is typically caught by automated tools and causes confusion rather than complete access failure.

Gray text on a white background — a common design choice for body copy, labels, and placeholder text — fails WCAG 2.2 SC 1.4.3 (Contrast Minimum) when the ratio drops below 4.5:1 for normal text or 3:1 for large text. SC 1.4.6 (Enhanced Contrast) sets a higher AAA bar of 7:1. Section 508 2018 Refresh 302.7 enforces visual contrast. The most common specific failure: `#888` text on `#ffffff` background produces a 3.5:1 ratio — passing for large text but failing for body copy. Form label text, placeholder text, and secondary captions are the most frequently failing elements. Approximately 8% of men have color vision deficiencies that reduce their effective contrast perception, and low contrast also affects users in bright sunlight or on low-quality displays.

Why this severity: Low because contrast failures degrade readability for many users without making text completely invisible, and are typically caught and fixed with tooling rather than requiring architectural changes.

A dark mode implementation that inverts colors without verifying contrast ratios often swaps a passing light-mode palette for a failing dark-mode one. WCAG 2.2 SC 1.4.3 (Contrast Minimum) applies equally in both color modes — there is no dark mode exemption. Section 508 2018 Refresh 302.7 governs visual accessibility regardless of theme. Common failure: a link color of `#3b82f6` (blue-500) passes on white (`#ffffff`, ratio 3.94:1 — too low for body text but acceptable for large text) but the same blue on a dark background of `#111827` improves to 5.9:1. However, secondary text `#9ca3af` (gray-400) on `#111827` produces only 4.0:1 — failing for normal-weight body text under 18px. Dark modes added as afterthoughts frequently have these partial failures concentrated in secondary text and muted labels.

Why this severity: Low because dark mode contrast failures affect only users who have explicitly opted into dark mode, but those users have the same accessibility rights as light mode users.

Error states indicated only by a red border, status indicated only by a green/red dot, and form field requirements indicated only by an asterisk colored red — all three convey meaning exclusively through color. Approximately 8% of men and 0.5% of women have some degree of red-green color vision deficiency; for them, red and green may appear as identical shades of brown. WCAG 2.2 SC 1.4.1 (Use of Color) explicitly prohibits color as the sole visual means of conveying information. Section 508 2018 Refresh 302.7 enforces visual accessibility. The concrete failure: a form with red-bordered invalid fields shows no error text — a user with protanopia sees a border of indeterminate color and has no way to identify the problem or its nature.

Why this severity: Medium because color-only indicators exclude users with color vision deficiencies from understanding critical state information like form errors or required fields.

Buttons and links smaller than 44x44 CSS pixels create a precision targeting problem for users with motor impairments, tremors, or large fingers on touch devices. WCAG 2.2 SC 2.5.8 (Target Size, Minimum) — new in WCAG 2.2 — requires a minimum target size of 24x24 CSS pixels with no adjacent targets within 24px, or a 44x44 minimum with no spacing requirement. SC 2.5.5 (Target Size, Enhanced) sets the AAA target at 44x44. Section 508 2018 Refresh 407.8 mandates operable part size. The most common failures: icon buttons (often 20x20 or 24x24 pixels), inline text links with short visible text, and toolbar controls packed without spacing. On touch-screen devices, close misses on a 20px button frequently activate adjacent controls instead.

Why this severity: Low because undersized touch targets impair usability for motor-impaired and touch-screen users without blocking access, and the fix requires only CSS changes.

For users with vestibular disorders, conditions like PPPD (Persistent Postural-Perceptual Dizziness) or Meniere's disease, parallax scrolling, auto-playing carousels, and animated page transitions can trigger nausea, vertigo, and seizure-like symptoms. These users configure their OS to prefer reduced motion as a medical accommodation. WCAG 2.2 SC 2.3.3 (Animation from Interactions) — a AAA criterion — requires that motion animation triggered by interaction can be disabled. Section 508 2018 Refresh 302.1 covers a general right to usability. Even at AA, animations that play unconditionally violate reasonable usability expectations for a significant user population. The `prefers-reduced-motion` media query is supported in all major browsers and is a one-to-one signal from user OS settings.

Why this severity: Info because failing to respect reduced-motion preferences is a AAA-level concern that affects a smaller population, but it can trigger genuine medical symptoms in vestibular disorder patients.

A form that displays validation errors as inline red text — but does not announce them to assistive technology — leaves screen reader users in a silent loop: they submit the form, receive no feedback, and submit again, never understanding why their submission fails. WCAG 2.2 SC 3.3.1 (Error Identification) requires error fields to be identified programmatically. SC 3.3.3 (Error Suggestion) requires that suggestions for correction be provided when the format is known. SC 4.1.3 (Status Messages) requires status messages to be programmatically determinable. Section 508 2018 Refresh 502.3.14 covers status change announcements. The `aria-describedby` link between an error message and its input is the mechanism that allows a screen reader to read the error when the user focuses the invalid field.

Why this severity: High because inaccessible error communication completely prevents screen reader users from diagnosing and correcting form submission failures.

A 'show password' toggle button that changes an input from `type="password"` to `type="text"` — but has no `aria-pressed` — is announced identically by screen readers whether the password is visible or hidden. Users cannot tell whether their action succeeded. The same problem applies to a favorites button, a bookmark toggle, a mute button, and any other binary-state control. WCAG 2.2 SC 4.1.2 (Name, Role, Value) requires that the current value or state of UI components be programmatically determinable. Section 508 2018 Refresh 502.3.4 mandates that value or state changes be programmatically determinable. The expected pattern per ARIA Authoring Practices: a toggle button uses `aria-pressed` to expose its binary state.

Why this severity: Medium because missing `aria-pressed` leaves screen reader users unable to determine toggle state, requiring them to infer it from side effects rather than direct feedback.

An accordion section that shows or hides content via CSS `display: none / block` toggling — but has no `aria-expanded` on the trigger button — is invisible in state to screen readers. The screen reader announces 'button: FAQ: What is your refund policy?' whether the section is open or closed. Users who want to collapse an open section have no way to confirm its current state before clicking. WCAG 2.2 SC 4.1.2 (Name, Role, Value) requires the state of UI components to be programmatically determinable. Section 508 2018 Refresh 502.3.4 covers programmatic state. The ARIA disclosure widget pattern specifies `aria-expanded` on the controlling button and `id`/`aria-controls` linking the button to its panel.

Why this severity: Medium because absent `aria-expanded` removes state awareness from screen reader users, degrading their ability to navigate and manage accordions and disclosure widgets.

A data table with `<td>` elements in the header row instead of `<th>` elements loses its entire semantic structure for screen readers. Without `<th scope="col">` headers, screen readers announce cell content without any column or row context — a user navigating a pricing comparison table hears '49, 99, 199' with no indication of which tier each price belongs to. WCAG 2.2 SC 1.3.1 (Info and Relationships) requires that relationships conveyed visually (like column header to data cell) be available programmatically. Section 508 2018 Refresh 502.3.5 covers information and relationships. Complex tables with both row and column headers require `scope="col"`, `scope="row"`, and in multi-header scenarios, `headers` attributes on data cells referencing multiple `id` values.

Why this severity: Low because missing table headers create context loss for screen reader users in tabular data without blocking access to the underlying cell values.

A product photo gallery with no `alt` text means a screen reader user hears 'image, image, image' with no product names, no descriptions, and no way to distinguish between items. A decorative divider image without `alt=""` forces the screen reader to announce the filename ('divider-wave-blue.png') — meaningless noise. WCAG 2.2 SC 1.1.1 (Non-text Content) requires text alternatives for all non-text content. SC 1.3.1 (Info and Relationships) covers semantic grouping of related images via `<figure>`/`<figcaption>`. Section 508 2018 Refresh 302.1 enforces the same. The specific failure mode for AI-generated projects: image alt attributes contain only the filename or a generic 'image of...' prefix without describing the actual visual content.

Why this severity: Low because missing or inadequate alt text removes image information for screen reader users but does not break surrounding navigation or interactive functionality.