Digital Accessibility Compliance: A Practical Guide for Product Teams

Accessibility lawsuits against websites increased 300% between 2018 and 2023. Domino's Pizza, Beyoncé's website, Netflix, and thousands of smaller businesses have faced legal action for inaccessible digital products.

The legal risk is real, but it's also the wrong reason to care. One billion people globally live with disabilities. Building accessible products isn't charity — it's reaching 15% of your potential market who currently can't use your product.

This guide covers what accessibility actually requires, how to test for it, and how to build it into your workflow without massive overhead.

What WCAG Actually Requires

The Web Content Accessibility Guidelines (WCAG) are the international standard. Most legal requirements reference WCAG 2.1 Level AA as the minimum compliance threshold.

WCAG organizes requirements around four principles (POUR):

Each principle contains specific "success criteria" rated A (minimum), AA (standard), or AAA (enhanced). Level AA compliance means meeting all A and AA criteria — roughly 50 specific requirements.

Most commonly violated criteria:

1. 1.1.1 Non-text Content (A) — Images without alt text
2. 1.4.3 Contrast Minimum (AA) — Text with insufficient color contrast
3. 2.4.4 Link Purpose (A) — Links that say "click here" without context
4. 1.3.1 Info and Relationships (A) — Missing form labels, improper heading structure
5. 4.1.2 Name, Role, Value (A) — Custom controls without proper ARIA attributes

These five issues account for the majority of accessibility failures. Fix them and you've addressed most compliance risk.

Color Contrast: The Numbers

Color contrast isn't subjective — it's mathematically defined as a ratio between foreground and background luminance.

WCAG AA requirements:

Tools for checking contrast:

• WebAIM Contrast Checker (free, web) — Quick manual checks
• Stark (Figma/Sketch plugin) — Design-phase checking
• axe DevTools (browser extension) — Automated scanning
• Color Oracle (desktop) — Simulates color blindness

Common mistakes:

• Placeholder text in form fields (often fails contrast)
• Disabled button states (still need 3:1 for the disabled indicator)
• Text over images without overlay
• Brand colors that don't meet ratios (redesign or use only for large text)

Don't rely solely on color to convey information. A red error message needs more than color — add an icon, bold text, or explicit "Error:" prefix.

Keyboard Accessibility: Essential Patterns

Approximately 20% of accessibility issues involve keyboard navigation. Users with motor impairments, vision loss, or repetitive strain injuries often can't use a mouse.

Every interactive element must be:

1. Focusable — Reachable via Tab key
2. Operable — Activated via Enter or Space
3. Visible — Clear focus indicator when selected

Testing keyboard accessibility:

1. Unplug your mouse
2. Navigate your entire site using only Tab, Shift+Tab, Enter, Space, and arrow keys
3. Can you reach every link, button, and form field?
4. Can you see where focus is at all times?
5. Can you escape modal dialogs and dropdown menus?

Common failures:

Focus indicator requirements:

The default browser focus ring is ugly, so designers remove it. Don't. Instead, style it:

/* Bad - removes focus indicator */
:focus { outline: none; }

/* Good - custom focus indicator */
:focus {
  outline: 2px solid #005fcc;
  outline-offset: 2px;
}

/* Better - only hide for mouse users */
:focus:not(:focus-visible) { outline: none; }
:focus-visible { outline: 2px solid #005fcc; }

Alt Text: What to Actually Write

Alt text describes images for screen reader users. It's also displayed when images fail to load.

Decision tree:

1. Decorative image? (adds no information) → Use empty alt: alt=""
2. Informative image? → Describe the content and function
3. Image of text? → Include all the text in alt
4. Complex image? (chart, diagram) → Brief alt + longer description nearby

Examples:

Don't do this:

• "Image of..." or "Picture of..." (screen readers already announce it's an image)
• Keyword stuffing for SEO
• Describing every visual detail when only some matter
• Leaving alt empty for informative images

Captions and Transcripts

Video and audio content requires text alternatives. This isn't optional — it's a legal requirement and helps users in noisy environments, non-native speakers, and anyone who prefers reading.

Requirements by content type:

Caption quality matters:

Auto-generated captions (YouTube, etc.) typically achieve 80-90% accuracy. That sounds good until you realize 10% errors means multiple mistakes per minute. For compliance, captions need human review.

Caption requirements:

• Speaker identification when multiple people talk
• Sound effects noted: [door slams], [phone rings]
• Music described: [upbeat jazz music]
• Synchronized within 3 seconds of audio
• Readable speed (max ~3 lines, ~200 words per minute)

For teams producing video content regularly, tools like Captionista streamline subtitle editing on mobile devices — useful for quick social media content that still needs accessibility.

Transcript format:

Transcripts should include:

• Speaker labels
• Non-speech sounds
• Description of relevant visual information
• Timestamps for longer content

Forms: Where Accessibility Often Breaks

Forms collect data. Inaccessible forms lose customers and create legal liability.

Essential form accessibility:

1. Every input needs a label

<!-- Bad -->
<input type="email" placeholder="Email">

<!-- Good -->
<label for="email">Email address</label>
<input type="email" id="email" placeholder="you@example.com">

Placeholders aren't labels — they disappear when users start typing.

2. Error messages must be clear and findable

• Identify which field has the error
• Explain what's wrong specifically
• Don't rely only on color
• Associate errors with fields using aria-describedby

<label for="phone">Phone number</label>
<input type="tel" id="phone" aria-describedby="phone-error" aria-invalid="true">
<span id="phone-error" class="error">Please enter a 10-digit phone number</span>

3. Group related fields

<fieldset>
  <legend>Shipping address</legend>
  <!-- address fields -->
</fieldset>

4. Indicate required fields

Mark required fields visually AND programmatically:

<label for="name">Full name <span aria-hidden="true">*</span></label>
<input type="text" id="name" required aria-required="true">

Testing Tools and Methods

Automated tools catch about 30-40% of accessibility issues. The rest require manual testing.

Automated testing tools:

What automated tools catch:

• Missing alt text
• Contrast failures
• Missing form labels
• Invalid HTML
• Missing language attribute
• Empty links and buttons

What automated tools miss:

• Alt text quality (present but meaningless)
• Keyboard trap issues
• Logical reading order
• Focus indicator visibility
• Whether content makes sense

Manual testing checklist:

1. Keyboard-only navigation — Complete key user flows without mouse
2. Screen reader testing — Use NVDA (Windows, free), VoiceOver (Mac/iOS, built-in), or TalkBack (Android, built-in)
3. Zoom to 200% — Content should remain usable
4. Color blindness simulation — Use tools like Color Oracle
5. Cognitive review — Is language clear? Is navigation predictable?

User testing:

Automated and manual testing by developers isn't enough. Test with actual users who have disabilities. They'll find issues you never considered.

Hiring accessibility consultants provides expert audits and helps prioritize remediation. Particularly valuable before major launches or after receiving complaints.

Building Accessibility Into Your Workflow

Retrofitting accessibility is expensive. Building it in from the start costs 10-20% of remediation costs.

Design phase:

• Use design systems with accessible components
• Annotate designs with accessibility specifications
• Check contrast ratios during design, not development
• Define focus states for all interactive elements
• Specify heading hierarchy

Development phase:

• Use semantic HTML (buttons, headings, lists, landmarks)
• Integrate automated testing into CI/CD
• Test keyboard navigation during development
• Add accessibility acceptance criteria to tickets

Content creation:

When creating documentation or written content, structured formats like Markdown help maintain proper heading hierarchy and semantic structure — which translates to better accessibility when published.

QA phase:

• Include accessibility in test plans
• Require screen reader testing for key flows
• Block releases for Level A violations
• Track accessibility issues like other bugs

If hiring external developers:

When selecting app development agencies, ask specifically about their accessibility experience. Request examples of WCAG-compliant work and ask how they handle accessibility testing. Agencies without clear answers will produce inaccessible products.

Remediation Priorities

If your product has accessibility issues (most do), prioritize fixes by:

1. Severity (user impact)

• Critical: Complete barriers (keyboard traps, no alt text on functional images)
• High: Major difficulties (poor contrast, missing labels)
• Medium: Inconveniences (suboptimal alt text, minor contrast issues)
• Low: Enhancements (AAA criteria, ideal rather than compliant)

2. Legal risk

• Login and registration
• Checkout/payment
• Core product functionality
• Contact and support

3. Traffic/usage

• Homepage and main navigation
• High-traffic pages
• Key conversion paths

Quick wins to start:

Legal Context

United States:

The ADA (Americans with Disabilities Act) has been interpreted to cover websites, though specific standards aren't codified. Courts generally expect WCAG 2.1 AA compliance. Lawsuits increased from 814 in 2017 to 4,000+ annually by 2023.

European Union:

The European Accessibility Act requires WCAG 2.1 AA compliance for most digital products and services by 2025.

Other jurisdictions:

Canada (AODA), UK (Equality Act), Australia (DDA) all have accessibility requirements. International businesses need awareness of multiple frameworks.

Risk mitigation:

• Document accessibility efforts and testing
• Have a published accessibility statement
• Provide contact method for accessibility issues
• Respond promptly to complaints
• Show good faith effort toward compliance

An honest "we're working on it" with documented progress provides better legal standing than ignoring the issue.

Cost Estimates

Audit costs:

Remediation costs:

Highly variable based on codebase and issue volume. Rough estimates:

• Simple marketing site: $5,000-20,000
• Medium web application: $25,000-100,000
• Complex platform: $100,000-500,000+

Ongoing maintenance:

Budget 5-10% of development time for accessibility testing and fixes as part of regular workflow.

Bottom Line

Accessibility isn't a feature you add at the end — it's a quality attribute that affects every design and development decision.

Start with the fundamentals:

1. Semantic HTML
2. Keyboard accessibility
3. Sufficient color contrast
4. Meaningful alt text
5. Proper form labels

These five practices prevent 80% of accessibility issues. Build them into your standards, test regularly with automated tools and manual checks, and include users with disabilities in your testing.

Perfect accessibility is aspirational. Meaningful accessibility — products that work reasonably well for users with disabilities — is achievable with modest, consistent effort.

The alternative is products that exclude 15% of potential users and invite legal action. Neither outcome makes business sense.