10 Common WCAG Violations That Can Put Your Website at Legal Risk
Ten practical WCAG failure patterns, how to fix them, and what the U.S. Title II rule does—and does not—require.
Short answer: Common, high-impact WCAG failure patterns include missing image alternatives and captions, keyboard barriers, hidden focus, low contrast, visual-only structure, inaccessible forms, broken layouts at zoom, unexpected context changes or time limits, and custom controls that do not expose their state. These are practical examples, not a measured ranking. A technical failure can create an access barrier, but it does not by itself establish a legal violation or predict a lawsuit: legal obligations depend on jurisdiction, entity type, applicable law, and the facts.
WCAG conformance is determined by its success criteria, organized around perceivable, operable, understandable, and robust content. W3C recommends using the current WCAG version; WCAG 2.2 is the latest Recommendation in the cited W3C material. The U.S. Department of Justice’s specific Title II web rule covers state and local governments and sets WCAG 2.1 Level AA as its technical standard. That rule should not be treated as a universal standard or deadline for every private website. W3C WCAG overview · WCAG 2.2 Recommendation · DOJ Title II rule fact sheet
1. What “legal risk” means in a WCAG review
WCAG provides testable accessibility criteria. A failure can indicate that a person with a disability cannot perceive information, operate a control, understand an interaction, or use content with assistive technology. Whether that barrier violates a particular law depends on the applicable legal framework and circumstances.
In the United States, the ADA addresses state and local governments under Title II and businesses open to the public under Title III. DOJ’s 2024 web rule establishes a specific WCAG technical standard for Title II public entities. It reaches web content and mobile apps those entities provide or make available, including through contracts or other arrangements, subject to defined exceptions. The Title II rule does not set one technical standard or deadline for all private websites. Other ADA duties may still matter in a particular situation. DOJ Title II regulations · DOJ ADA web accessibility guidance
For covered Title II entities, the technical standard is WCAG 2.1 Level AA. Following the April 2026 extension, covered entities with populations of 50,000 or more have until April 26, 2027. Smaller governments and special district governments have until April 26, 2028. Exceptions require careful application; they are not blanket exemptions for old or vendor-provided content. Recheck DOJ’s current rule materials before relying on dates, and consult qualified counsel about a specific legal question. DOJ first steps guidance and current dates
2. Ten high-impact WCAG failure patterns
The examples below are common types of failure documented in W3C material or practical applications of WCAG criteria. They are not ranked by prevalence. W3C techniques and failure examples are informative ways to understand criteria, not an exhaustive list of the only ways to conform. W3C WCAG techniques
1. Images have no useful text alternative
Barrier: A screen reader user may miss information conveyed only by an image, chart, icon, or image-based control. A filename such as chart-final2.png is not a useful equivalent.
Relevant criterion: WCAG 1.1.1, Non-text Content (Level A). Informative images need an appropriate text alternative. Decorative images should generally be hidden from assistive technology so they do not produce redundant announcements. Criterion 1.1.1
Fix: Write concise alt text that conveys the image’s purpose in context. For a complex chart, provide the key data or a nearby text equivalent. Use empty alt text (alt="") for purely decorative images. Give an image link or button an accessible name that describes its action.
2. Video lacks accurate captions
Barrier: Deaf and hard-of-hearing users can miss speech and meaningful sounds when synchronized video has no captions or inaccurate captions.
Relevant criterion: WCAG 1.2.2, Captions (Prerecorded) (Level A); live media has a separate criterion, 1.2.4 (Level AA). Captions should include dialogue and meaningful sound information, not just a rough transcript. W3C identifies omitted dialogue and important sound effects as failure patterns. Criterion 1.2.2 · W3C failure examples
Fix: Review captions against the actual recording, correct names and timing, identify relevant speakers and sounds, and ensure captions can be enabled in the player. Do not rely on unreviewed automatic transcription for critical content.
3. Core tasks cannot be completed with a keyboard
Barrier: People who cannot use a mouse may be unable to open menus, use dialogs, select options, submit forms, or reach content. A keyboard user can also become trapped in a widget with no way to move focus out.
Relevant criteria: WCAG 2.1.1, Keyboard (Level A), and 2.1.2, No Keyboard Trap (Level A). Keyboard · No Keyboard Trap
Fix: Test the complete task using Tab, Shift+Tab, Enter, Space, arrow keys, and Escape where appropriate. Make every action reachable and operable; keep focus order logical; and provide a documented keyboard exit from composite widgets and dialogs.
4. Keyboard focus is invisible or obscured
Barrier: A keyboard user may not know which link or control will activate next, or a sticky header, banner, or footer may cover the focused item.
Relevant criteria: WCAG 2.4.7, Focus Visible (Level AA), and WCAG 2.2 criterion 2.4.11, Focus Not Obscured (Minimum) (Level AA). The latter says: “When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.” Attribute that criterion to W3C. Focus Visible · Focus Not Obscured
Fix: Preserve a clear focus indicator instead of removing the browser outline without an equivalent. Tab through the page at different viewport sizes and verify sticky elements do not completely hide the focused component.
5. Text or controls have inadequate contrast
Barrier: People with low vision, color vision deficiencies, or reduced contrast sensitivity may struggle to read text or identify controls. Text contrast and non-text contrast are distinct checks; a brand color is not automatically a failure without measuring its foreground and background in context.
Relevant criteria: WCAG 1.4.3, Contrast (Minimum) (Level AA), applies to text and images of text; 1.4.11, Non-text Contrast (Level AA), applies to visual information needed to identify user interface components and states. Consult the criterion text for precise thresholds and exceptions. Contrast (Minimum) · Non-text Contrast
Fix: Measure actual foreground/background pairs, including text over images, hover and focus states, disabled-state treatment where applicable, and component boundaries. Adjust colors or add another visual cue; do not communicate meaning by color alone.
6. Headings, lists, or table relationships exist only visually
Barrier: A page may look structured while assistive technology receives a flat sequence of paragraphs. Screen reader users then lose the ability to navigate headings, understand list membership, or associate table cells with headers.
Relevant criteria: WCAG 1.3.1, Info and Relationships (Level A), and 1.3.2, Meaningful Sequence (Level A). W3C failure techniques include cases where presentation changes convey information without appropriate markup. Info and Relationships · W3C techniques
Fix: Use semantic heading elements in a meaningful hierarchy, list markup for lists, and table header cells with appropriate associations. Do not use font size, bold styling, spacing, or visual position alone to express relationships.
7. Forms lack labels, instructions, or useful error messages
Barrier: Users may not know what a field requests, which format to enter, or how to recover from an error. A placeholder alone can disappear during entry and may not provide a persistent accessible label.
Relevant criteria: WCAG 1.3.1, Info and Relationships (Level A), 3.3.1, Error Identification (Level A), and 3.3.2, Labels or Instructions (Level A). Info and Relationships · Error Identification · Labels or Instructions
Fix: Associate each field with a programmatic label; explain required formats before entry; identify errors in text; and tell the user how to correct them. When validation fails, focus or otherwise direct attention to the error without unexpectedly discarding valid input.
8. Content breaks at zoom or narrow viewport widths
Barrier: Users who enlarge text or magnify the page may lose content or functionality if text overlaps, controls become unreachable, or essential content requires scrolling in two directions.
Relevant criteria: WCAG 1.4.4, Resize Text (Level AA); 1.4.10, Reflow (Level AA); and 1.4.12, Text Spacing (Level AA). Each criterion has specific conditions and exceptions; use the normative text for exact thresholds. Resize Text · Reflow · Text Spacing
Fix: Test at 200% text resizing and the reflow conditions specified by WCAG, then apply the text-spacing overrides in criterion 1.4.12. Check dialogs, tables, navigation, and sticky elements as well as article text. Let content grow and wrap; avoid fixed-height containers that clip it.
9. Unexpected context changes or time limits block completion
Barrier: A user can lose their place when changing a setting unexpectedly navigates or submits a form. A time limit can also expire before someone using assistive technology has completed a task.
Relevant criteria: WCAG 3.2.1, On Focus (Level A), 3.2.2, On Input (Level A), and 2.2.1, Timing Adjustable (Level A), subject to each criterion’s exceptions. W3C documents context-change and timing failure examples. On Focus · On Input · Timing Adjustable · W3C techniques
Fix: Do not navigate or submit merely because focus moves or a field changes unless users were warned in advance. Where WCAG requires it, let users turn off, adjust, or extend a time limit. Test session expiry and recovery paths, not just the initial form.
10. Custom controls do not expose their role, name, state, or value
Barrier: A custom switch may look and behave visually like a control while assistive technology cannot identify it, determine whether it is on, or change it with expected keys.
Relevant criteria: WCAG 4.1.2, Name, Role, Value (Level A), along with applicable keyboard criteria. W3C lists incomplete accessibility API support for custom controls as a failure pattern. Name, Role, Value · W3C techniques
Fix: Prefer native HTML controls. If a custom widget is necessary, expose an accessible name, role, current state/value, and state changes; implement the expected keyboard interaction; and verify with assistive technology. ARIA attributes do not add keyboard behavior automatically.
3. How to find and prioritize issues
- Map key journeys. List the important tasks: account creation, search, checkout, appointment booking, document access, or other core services. Include pages and steps supplied by vendors.
- Scan representative templates. Automated accessibility checkers can flag some detectable problems, such as missing names or contrast candidates. A clean scan cannot prove whole-site conformance: it may not understand whether alt text is meaningful, whether captions are accurate, or whether a keyboard task is usable.
- Test with a keyboard. Complete each mapped journey without a mouse. Confirm logical focus order, visible focus, working controls, and no keyboard traps.
- Inspect with assistive technology and at enlarged sizes. Check headings and landmarks, forms and errors, announcements of custom control states, and layout with zoom and narrow viewports.
- Fix blockers, then retest. Prioritize barriers that prevent a person from completing an essential task. Assign an owner, retest the repaired page and related templates, and record the scope and result.
- Include vendor content and changes. Review third-party components, embedded tools, and content published through contracts. Recheck after significant redesigns or component changes.
For an audit or remediation engagement, compare whether it combines automated scans with manual keyboard and assistive-technology checks, covers templates and complete journeys rather than only the homepage, assigns remediation and retesting ownership, addresses vendor-controlled components, and documents how its findings map to the standard and legal scope that applies. A scanner score or accessibility statement alone does not establish conformance.
4. Common questions
Does my website have to meet WCAG 2.1 AA?
It depends on the law and your organization. DOJ’s specific Title II rule requires covered state and local government web content and mobile apps to meet WCAG 2.1 Level AA. Do not assume that rule supplies the standard or deadline for every private business or every jurisdiction. Determine which requirements apply to your organization with qualified counsel.
Is WCAG 2.2 AA the same as WCAG 2.1 AA?
No. WCAG 2.2 adds nine success criteria beyond WCAG 2.1, while preserving the earlier criteria with limited exceptions. W3C recommends using the latest version for broader accessibility work; a rule that expressly names WCAG 2.1 still has to be read as written. W3C: What’s New in WCAG 2.2
Can an accessibility checker tell me whether my website is compliant?
It can help find some issues, but it cannot establish by itself that a whole website conforms. Human review is needed for meaning, task completion, keyboard operation, captions, and other context-dependent criteria.
Does any single WCAG failure mean I will be sued?
No such conclusion follows from a technical failure alone. Legal exposure depends on applicable law, jurisdiction, entity type, the barrier, and the surrounding facts. Seek qualified legal advice about a specific dispute or obligation.
5. Capture visual evidence while fixing accessibility
When reviewing page changes, consistent screenshots can help a team compare layout before and after a fix, document responsive states, and share a visual regression with developers. A screenshot does not test keyboard access, semantics, captions, or assistive-technology behavior; pair visual records with the manual checks above.
You can capture pages in a browser you control or automate screenshots through an API. ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. One GET request can return PNG, JPEG, WebP, or PDF. Its cookie-banner, popup, and chat-widget handling can help teams capture a cleaner page state; the service reports page verdict and billing status in response headers. Details and configuration are in the ScreenshotNeo API documentation.
Or skip the browser setup
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpimport requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);Cookie banners, popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. See ScreenshotNeo and its API documentation, then sign up for 1,000 free screenshots a month with no card.
