Accessibility isn't a compliance checkbox: what accessible design actually requires

Why most products fail accessibility (and it's usually the same reasons)

From our project work, accessibility problems don't come from a hundred different issues. They come from a small, repeating set of design decisions. Low contrast text on a pale background because it looked "clean." Thin, elegant typography that becomes invisible to anyone with reduced vision. Images without alternative text. Video without captions. Interactive elements that can't be reached without a mouse.

When we audit a product for accessibility, the list of findings is usually longer than the team expected but shorter than they feared, because the problems repeat. Fix the four patterns we'll cover below and you've closed most of the real-world gap between your product and users who can't use it today.

This matters for two reasons. First, it makes the problem tractable. Second, it reframes accessibility from "a giant compliance project" into "a design discipline that stacks the same way any other craft does."

Situational disability is universal

The conventional framing of accessibility is about permanent disability. That framing is incomplete.

Disability is situational. Someone using a phone in bright sunlight experiences the same visual limitation as someone with low vision. Someone on a noisy commute needs the same caption support as someone deaf. A parent holding a child has the same one-handed navigation need as someone with a motor impairment. Someone trying to concentrate in a distracting environment has the same cognitive load concerns as someone with ADHD.

Design for permanent disability and you pick up every temporary and situational version of it for free. The "accessibility tax" argument (that accommodating edge users costs effort that doesn't return) has the causation backwards. Designing for the edges improves the product for the middle, because the middle is made up of people who are only edge users some of the time.

Roughly 15 to 20% of any population lives with some form of disability. The percentage of users experiencing a situational version of that disability at any given moment is much higher.

The four categories where accessibility actually breaks

1. Color and contrast

What fails: text that's hard to distinguish from its background. White text on pale gray. Light gray body copy on white. Color-coded states where the color is the only signal.

Why it matters: reduced vision, color blindness, and situational glare all make low-contrast content effectively invisible. Users don't "struggle" with it. They miss it entirely and don't know they missed it.

The fix at the design level: meet the contrast minimums (4.5:1 for body text, 3:1 for large text under WCAG AA). Don't rely on color alone to communicate state. Pair color with text, icons, or position. Preview designs against actual content, not placeholder text that's always the exact color you specified.

The fix at the development level: use design tokens for color, not one-off values. Test contrast ratios on built screens, not just in mockups. Rendering differences can change actual contrast.

2. Text and readability

What fails: fonts chosen for aesthetics over legibility, body text under 14 to 16px, line heights too tight to track comfortably, paragraph widths too wide to read without losing place, and text locked at a fixed size that can't be scaled up.

Why it matters: readability problems compound with reduced vision and situational fatigue. Users abandon content they have to work to read.

The fix at the design level: body text at a minimum of 14 to 16px, typeface with clear letter shapes (generous x-height, distinguishable letterforms), line height at roughly 1.4 to 1.6 times the font size, paragraph width capped around 60 to 75 characters per line. Reserve thin and display weights for headlines and marketing moments, not body copy.

The fix at the development level: use relative units (rem/em) that respect the user's browser font size setting, not fixed pixels. Support scaling up to at least 200% without layout breaking.

3. Media alternatives

What fails: images without alt text, video without captions or transcripts, audio-only content without a written version, infographics where the information is trapped inside the image.

Why it matters: a user who can't see an image, can't hear a video, or is in a context where audio is impossible (library, open office, noisy commute) gets nothing from content that depends entirely on one channel.

The fix at the design level: treat alternative formats as part of the content, not a retrofit. Plan for captions when producing video. Write alt text as the image is being placed, not in a last-minute sweep. Build infographics with the underlying data available in a readable format alongside the visual.

The fix at the development level: alt text attributes on all informational images (empty alt for purely decorative ones), captions and transcripts on video, keyboard-accessible media controls, audio descriptions for video where visual information is load-bearing.

4. Keyboard navigation and focus

What fails: interactive elements unreachable without a mouse, focus indicators hidden or styled away, tab order that jumps around unpredictably, modal dialogs that trap focus or lose it, skip-links missing on long pages.

Why it matters: screen reader users, users with motor impairments, and many power users navigate entirely with the keyboard. If your product isn't usable without a mouse, it isn't usable, period. The test takes thirty seconds: press Tab repeatedly and see what happens.

The fix at the design level: design visible focus states as a first-class part of the interaction system, not an afterthought. Make sure interactive elements are visually obvious as interactive. Order elements so tab progression matches the visual reading order.

The fix at the development level: ensure every interactive element (links, buttons, form fields, custom components) is reachable and operable via keyboard. Implement logical tab order. Manage focus explicitly on modals, dialogs, and route changes. Include a "skip to main content" link on pages with heavy navigation.

What WCAG actually asks for (in numbers)

WCAG (Web Content Accessibility Guidelines) is the international standard maintained by the W3C. It's organized into three conformance levels:

- Level A: The minimum. Catches the most severe barriers. Below this level, the product is effectively unusable for meaningful user groups.

- Level AA: The operational target. What most businesses should aim for and what most accessibility regulations worldwide actually require. Covers color contrast (4.5:1 for body, 3:1 for large text), keyboard access, captions on live video, resizable text up to 200%, consistent navigation, visible focus, and meaningful form labels.

- Level AAA: The highest level. Useful in specific contexts such as government, healthcare, education, and content primarily for users with disabilities. Often impractical as a blanket target across all product content.

Target Level AA unless there's a specific reason to go higher or lower. It's the shared benchmark that regulators, auditors, and users expect.

The business case: three reasons accessibility isn't optional anymore

Accessibility used to be framed as a "nice to have." That framing has aged out.

- Legal: Many jurisdictions now legally require digital accessibility. The US Americans with Disabilities Act (ADA) has been extended through case law to cover digital products. The European Accessibility Act reaches enforcement in 2025 with requirements on most products and services sold in the EU. The UK Equality Act, Canada's Accessible Canada Act, and equivalents in other markets create similar obligations.

- Market: Roughly 15 to 20% of any population lives with some form of disability. Adding the temporary and situational versions lifts the practical number much higher. A product that excludes them is leaving measurable revenue on the table.

- Search and usability: Many accessibility practices (clear text hierarchy, descriptive alt text, semantic markup, logical navigation) also improve search ranking and usability for non-disabled users. The work pays back even without the accessibility argument.

The question isn't whether to invest in accessibility. It's whether to pay for it upfront as design discipline or later as legal risk and remediation.

The cost objection: why retrofitting is expensive, not designing-in

The most common objection we hear is "accessibility costs more." Honest answer: when retrofitted late, yes, sometimes dramatically. When built in from the start, the added cost is marginal.

Accessibility built in looks like: designers check contrast as part of normal design review, developers use semantic markup and ARIA patterns that are already part of their framework, QA tests with keyboard and screen reader as part of the standard test pass, content teams write alt text and captions as part of content creation. Each of these adds minutes, not hours, to work that's already happening.

Accessibility retrofitted looks like: an audit that finds hundreds of issues across a shipped product, a cross-team remediation project that touches design, code, content, and testing simultaneously, and a timeline that competes with planned roadmap work.

The cost most teams perceive as "the cost of accessibility" is actually the cost of accessibility debt. The way to avoid it is to stop building more of it.

Pre-launch accessibility checklist

A practical list to run before any significant launch. No tools required. These are checks a designer, developer, or content owner can do directly.

- Contrast: Body text meets 4.5:1 contrast against its background. Large text meets 3:1. Check on actual content, not placeholder copy.

- Text size and scaling: Body text at 14 to 16px or equivalent. The page remains usable when zoomed to 200%.

- Keyboard navigation: Tab through the entire page. Every interactive element is reachable. Tab order matches visual reading order. Nothing gets trapped. A "skip to main content" link exists on pages with heavy navigation.

- Focus indicators: Every focused element has a visible focus ring. Default browser focus styles weren't hidden in the stylesheet.

- Images: Every informational image has descriptive alt text. Decorative images have empty alt attributes.

- Video and audio: Captions available on video. Transcripts available for audio-only or video-heavy content. Media controls are keyboard-accessible.

- Forms: Every form field has a visible, programmatically associated label. Error messages are descriptive and tied to the field. Required fields are marked both visually and programmatically.

- Headings: Page uses a logical heading structure (one H1, properly nested H2 to H6). Headings describe section content, not just style sections visually.

- Color as the only signal: Status, errors, and required states don't rely on color alone. Text, icons, or position reinforce the meaning.

- Screen reader pass Navigate the page once with a screen reader. Key content is announced in a sensible order. Interactive elements identify their role.

Run this before any product launch. It catches most of what an audit would catch, before the audit happens.