Common barriers audit teams catch

The barriers that show up first

Manual audits consistently surface the same families of failures across very different products. The interfaces change, the brands change, and the technical stack changes, but the underlying patterns stay remarkably stable. Keyboard traps, missing names, weak focus states, fragile form recovery, and inaccessible visual content account for a large share of what audit teams document on most engagements.

These barriers are common because they sit at the intersection of custom UI work and ambiguous component contracts. Native HTML rarely produces them on its own, but the modern web is built from custom buttons, custom dialogs, custom tabs, custom comboboxes, and custom dropdowns, and the accessibility contract for each pattern has to be implemented intentionally.

This briefing collects the barrier categories audit teams flag most often, what they look like in real interfaces, and what the remediation path usually involves.

What this helps with

• Best for: product, engineering, design, and QA teams preparing for a manual WCAG audit or trying to understand findings already in hand.
• Outcome: a shared vocabulary for the recurring barrier patterns so issues can be reproduced, prioritized, and remediated without re-debating definitions.
• Use when: you need to brief stakeholders on what an audit will surface or translate raw WCAG findings into developer-ready work.

Audit principle: the same barrier patterns recur across products because they live inside reusable components. Fixing the component fixes the pages that consume it.

Keyboard traps

A keyboard trap is any place where focus moves into a component and then cannot move back out through standard keyboard input. Modals, calendars, carousels, chat widgets, mega menus, video players, cookie banners, and custom dropdowns all introduce traps when focus management is incomplete.

Audit teams look for traps by tabbing through the page from the address bar to the footer, then tabbing back. Anything that breaks that cycle, sends focus to the body unexpectedly, or sends focus off-screen is flagged.

• Focus enters a modal but cannot return to the triggering control after Escape.
• Tab cycles back to the top of the page from inside a carousel slide.
• Focus disappears into a hidden element after a dialog closes.
• Cookie banners or chat widgets capture focus and block the rest of the page.
• Custom date pickers do not respond to Escape or arrow keys.

The fix usually involves correct focus return, an Escape handler, and a roving tab index or focus trap that releases on close.

Missing names

Every interactive control needs a programmatic name that matches its visible purpose. Audits often surface icon buttons, link cards, custom inputs, and image controls that present no accessible name to assistive technology, or names that disagree with the visible label.

• Icon-only buttons rendered with an SVG and no aria-label or visually hidden text.
• Form fields that rely on placeholder text instead of a real label.
• Links that contain only an image with empty alternative text.
• Custom comboboxes whose announced name is generic ("button") instead of the field's purpose.
• Composite controls whose name does not include the visible text the user sees.

The remediation path is consistent: associate a visible label with the control, or provide an accessible name through aria-label, aria-labelledby, or visually hidden text that mirrors the visual purpose.

Poor focus states

Focus indicators are how keyboard users know where they are. Audit teams routinely document interfaces where the default browser focus ring has been removed without being replaced, where the new indicator fails contrast against the background, or where the indicator only appears on some controls.

• Custom buttons, tabs, and cards lose all focus styling because outline: none was applied globally.
• Focus indicators that disappear against dark backgrounds, image hero sections, or hover states.
• Focus on a link inside a card, while the card itself appears active visually, leaving users unsure which control is targeted.
• Focus state that only changes color slightly and does not meet the non-text contrast requirement.
• Components that render a focus ring on click but not on tab, so it disappears for keyboard users.

Modern remediation usually pairs :focus-visible with a deliberate two-tone indicator that meets WCAG 2.2's focus appearance requirements on every interactive element.

Form recovery gaps

Forms produce some of the most visible accessibility failures because they sit on the critical path. Account creation, checkout, intake, scheduling, and support all run through them. Audit teams look at how a form behaves before submission, on validation, after error, and after success.

• Error messages that appear visually but are not announced to screen readers.
• Validation that clears the field on submit, forcing users to re-enter data.
• Error text that says "invalid" without identifying the field or describing the fix.
• Required fields and format expectations only revealed after a failed submission.
• Success confirmations that update the visual UI but never move focus or announce the result.

A robust form pattern uses programmatic labels, aria-describedby for error messages, an accessible error summary at the top, preserved input on failed submission, and a confirmed success state announced to assistive technology.

Visual content failures

Visual content barriers are easy to overlook because they often pass automated scanners. Manual auditing catches them by examining contrast on real backgrounds, reviewing images for accurate alternative text, and checking whether information conveyed through color is also conveyed through text or shape.

• Text on hero images or gradient backgrounds that fails 4.5:1 contrast in certain viewport sizes.
• Decorative images with descriptive alt text, or informative images with empty alt text.
• Charts, dashboards, and status indicators that rely on color alone to convey meaning.
• Link text indistinguishable from surrounding paragraph text without underline or contrast support.
• Video and audio content without captions, transcripts, or audio descriptions.

Remediation depends on the failure: contrast adjustments in design tokens, accurate alt text written by the content owner, redundant encoding for color-only signals, and synchronized captions for time-based media.

Why these barriers recur

The same patterns appear across audits because they originate in shared components. A button component without a focus-visible style propagates the failure to every page that uses it. A modal without focus return creates a trap on every workflow it touches. A form pattern without an error summary leaves every form on the site without one.

That is why audit teams document not only the page where a failure was observed, but also the component, the design system reference, or the template responsible. Fixing the source removes the issue at scale and prevents reintroduction during normal feature work.

From findings to remediation

The translation from audit finding to engineering ticket follows a predictable shape: identify the component or template, describe the WCAG failure with reproduction steps, define the acceptance criteria for the fix, and define the retest path. Audit teams that write findings this way reduce back-and-forth and accelerate close-out.

• Reproduce: name the page, the assistive technology, the steps, and the observed behavior.
• Reference: link the WCAG success criterion and the component or template responsible.
• Resolve: describe the expected behavior in concrete terms a developer can implement.
• Retest: define what an auditor will check to confirm the failure is closed.

Conclusion

Most audits find variations of the same five barriers. Keyboard traps, missing names, weak focus states, fragile form recovery, and inaccessible visual content explain the majority of what manual testing surfaces. Teams that recognize the patterns before an audit begins can resolve a meaningful share of findings during preparation, leaving the audit to confirm the harder, more product-specific issues that require deeper investigation.