Skip to main content
Accessibility guidelines provide the foundation for building inclusive web experiences. This page covers the essential standards and resources you need to understand accessibility requirements.

Web Content Accessibility Guidelines (WCAG)

WCAG is the international standard for web accessibility, developed by the World Wide Web Consortium (W3C).

Understanding WCAG

WCAG is organized around four principles (POUR):
  • Perceivable: Information and UI components must be presentable to users in ways they can perceive
  • Operable: UI components and navigation must be operable by all users
  • Understandable: Information and operation of UI must be understandable
  • Robust: Content must be robust enough to work with current and future technologies

Conformance Levels

WCAG defines three levels of conformance:

Level A

Minimum level of accessibility. Must satisfy all Level A criteria.

Level AA

Recommended level for most websites. Includes all Level A + Level AA criteria. This is the standard target.

Level AAA

Highest level of accessibility. Includes all criteria. Not always achievable for all content.

WCAG Versions

  • WCAG 2.0 (2008): Original widely-adopted standard
  • WCAG 2.1 (2018): Added mobile, low vision, and cognitive criteria
  • WCAG 2.2 (2023): Latest version with additional criteria for cognitive accessibility
Target WCAG 2.1 Level AA as your baseline. It’s the most commonly referenced standard in legal requirements and best practices.

WAI-ARIA

Accessible Rich Internet Applications (ARIA) is a set of attributes that define ways to make web content more accessible when native HTML semantics aren’t sufficient.

ARIA Authoring Practices Guide

Comprehensive guide for implementing ARIA in web applications. Includes best practices and design patterns.

ARIA Patterns

Complete library of accessible component patterns with working examples and code.

Common ARIA Patterns

The ARIA Patterns guide provides implementation details for:
  • Navigation: Menus, tabs, breadcrumbs, tree views
  • Forms: Comboboxes, radio groups, sliders, spinbuttons
  • Dialogs: Modals, alertdialogs, tooltips
  • Dynamic Content: Live regions, carousels, accordions
  • Interactive Widgets: Drag and drop, grid, listbox

The First Rule of ARIA

“No ARIA is better than bad ARIA.”Always prefer native HTML elements over ARIA. Only use ARIA when HTML doesn’t provide the semantics you need.

ARIA Best Practices

  1. Use semantic HTML first: <button> is better than <div role="button">
  2. Don’t override native semantics: Avoid <button role="heading">
  3. All interactive ARIA controls must be keyboard accessible
  4. Don’t hide focusable elements: Visible focus indicators are required
  5. Use ARIA labels appropriately: aria-label, aria-labelledby, aria-describedby

Platform-Specific Guidelines

Mobile Accessibility

BBC Mobile Accessibility Guidelines

Comprehensive guidelines for mobile app accessibility across iOS and Android platforms.
Key mobile considerations:
  • Touch target sizes (minimum 44x44 CSS pixels)
  • Screen reader compatibility (VoiceOver, TalkBack)
  • Orientation and zoom support
  • Motion and animation controls
  • Text alternatives for non-text content

Native Applications

Each platform has specific accessibility APIs and guidelines:
  • iOS: VoiceOver, Dynamic Type, Reduce Motion
  • Android: TalkBack, system fonts, touch targets
  • Windows: Narrator, high contrast mode
  • macOS: VoiceOver, zoom, display accommodations

Global Standards

  • Section 508 (USA): Requires federal agencies to make digital content accessible
  • ADA (USA): Americans with Disabilities Act applies to private sector
  • EN 301 549 (EU): European standard for ICT accessibility
  • Accessibility for Ontarians with Disabilities Act (AODA) (Canada)
  • Equality Act 2010 (UK): Requires reasonable adjustments for disabled users
Most legal requirements reference WCAG 2.1 Level AA as the technical standard. Check your local regulations for specific requirements.

Industry-Specific Guidelines

Many organizations have published their own accessibility guidelines:

Vox Media Guidelines

Comprehensive checklist for designers, engineers, project managers, QA, and editorial teams.

BBC Accessibility Guidelines

Standards and guidelines from the BBC’s accessibility team for digital products.

Quick Reference Checklists

Essential WCAG 2.1 AA Requirements

Perceivable:
  • Text alternatives for images
  • Captions for video and audio
  • Adaptable layout that works at different sizes
  • Sufficient color contrast (4.5:1 for text)
Operable:
  • All functionality available via keyboard
  • Visible focus indicators
  • Enough time to read/use content
  • Clear page titles and navigation
Understandable:
  • Language of page identified
  • Predictable navigation and functionality
  • Input error identification and suggestions
  • Labels and instructions for forms
Robust:
  • Valid, semantic HTML
  • Name, role, value for all UI components
  • Compatible with assistive technologies

Community & Events

Global Accessibility Awareness Day

Held annually on the third Thursday of May. A day to raise awareness and learn about digital accessibility.

Stay Updated

  • Follow W3C WAI for official updates
  • Join accessibility communities (A11y Project, WebAIM)
  • Attend conferences (CSUN, Inclusive Design 24)
  • Subscribe to accessibility blogs and newsletters

Testing Against Guidelines

Manual Audit Process

  1. Review WCAG criteria applicable to your content
  2. Test with keyboard navigation only
  3. Use screen readers to verify semantic structure
  4. Check color contrast with automated tools
  5. Validate HTML for semantic correctness
  6. Test responsive behavior at different sizes and zoom levels

Documentation

  • Create an accessibility statement for your website
  • Document known issues and timelines for fixes
  • Maintain a VPAT (Voluntary Product Accessibility Template) for enterprise products
  • Track conformance level achieved (A, AA, or AAA)
Accessibility is a journey, not a destination. Regular testing and updates are essential as your product evolves and standards improve.

Further Reading

Build docs developers (and LLMs) love