Web Accessibility and WCAG: Complete Guide to Inclusive Design in 2025

What Is Web Accessibility?

Web accessibility means that websites, applications, and digital technologies are designed and developed so that people with disabilities can use them. This includes people with visual, auditory, motor, or cognitive disabilities.

Why It Matters

1. Audience Size

• 15% of the global population has some form of disability
• Represents over 1 billion people
• $8 trillion in global purchasing power

2. Legal Requirements

• In EU: European Accessibility Act (2025)
• In US: ADA and Section 508
• Significant fines for non-compliance

3. SEO Benefits

• Many accessibility practices improve SEO
• Alt text, semantic structure, clear navigation
• Google favors accessible sites

4. Better UX for Everyone

• Accessible design benefits everyone
• Situational disabilities (hands full, bright light)
• Older users

Understanding WCAG

What Are WCAG Standards?

Web Content Accessibility Guidelines (WCAG) are international standards developed by W3C for web accessibility.

Versions:

• WCAG 2.0 (2008)
• WCAG 2.1 (2018) - includes mobile
• WCAG 2.2 (2023) - latest
• WCAG 3.0 - in development

The 4 POUR Principles

1. Perceivable

Information must be presented in ways users can perceive.

2. Operable

The interface must be operable by all users.

3. Understandable

Content and operation must be understandable.

4. Robust

Content must be robust enough for diverse technologies.

Conformance Levels

Level A (Minimum)

• Basic requirements
• Eliminating critical barriers
• Minimum necessary

Level AA (Recommended)

• Standard for most organizations
• Required by many regulations
• Balance between accessibility and effort

Level AAA (Optimal)

• Highest level
• Not always possible for all content
• Target for critical content

Implementation Guide

1. Text Content and Alternatives

Alt Text for Images:

• Good: Descriptive text with context - "Chart showing 45% sales growth in Q4 2024"
• Bad: Generic or missing text - "image" or nothing
• Decorative images: Empty alt and role="presentation" to be ignored by screen readers

Video and Audio:

• Captions for video
• Transcripts for audio
• Audio description for video
• Sign language for critical content

2. Structure and Semantics

Correct Headings:

• Heading hierarchy must be logical: H1 -> H2 -> H3
• Don't skip levels (from H1 directly to H4)
• Each page should have a single H1

Landmark Regions:

Use semantic HTML5 elements for regions:

• header for header
• nav for navigation
• main for main content
• aside for secondary content
• footer for footer

Lists:

• Use ul/ol and li for lists, not divs with visual bullets
• Screen readers announce the number of items in the list

3. Keyboard Navigation

All Functions Accessible:

• Tab for navigation between elements
• Enter/Space for activation
• Arrow keys for menus
• Escape to close modals

Visible Focus:

• Never completely hide focus with outline: none
• Use a visible outline of at least 2px
• focus-visible allows styling only for keyboard navigation

Skip Links:

• Add "Skip to main content" link at the beginning of the page
• Visually hidden but available for screen readers
• Becomes visible when focused
• Allows users to skip repetitive navigation

4. Accessible Forms

Labels and Instructions:

• Each field must have a label associated via the for attribute
• Indicate required fields in the label
• Add hints (e.g., "Example: user@domain.com") with aria-describedby
• For errors, use aria-invalid="true" and role="alert"

Field Grouping:

• Use fieldset and legend to group related fields
• E.g., "Shipping address" as legend for the address field group
• Helps users understand the context of fields

5. Color and Contrast

Minimum Contrast Ratio:

• Normal text: 4.5:1 (AA)
• Large text (18pt+): 3:1 (AA)
• UI components: 3:1

Verification Tools:

• WebAIM Contrast Checker
• Color Contrast Analyzer
• Browser DevTools

Not Just Color:

• Bad: Error indicator only through red border
• Good: Color + icon + text "Required field"
• Ensure information is conveyed by means other than color

6. ARIA (Accessible Rich Internet Applications)

When to Use ARIA:

• When semantic HTML isn't enough
• For custom interactive components
• For live regions

ARIA Examples:

• role="button" for elements that behave as buttons but aren't button tags
• tabindex="0" to make element focusable
• aria-pressed for toggle buttons
• role="tablist", role="tab", role="tabpanel" for tab interfaces
• aria-selected to indicate active tab
• aria-live="polite" for regions that announce updates (e.g., "Product added to cart")

Golden Rule:

"No ARIA is better than bad ARIA"

• Prefer semantic HTML
• Test with screen readers

Common Components

Accessible Modal

Modal requirements:

• Use role="dialog" and aria-modal="true"
• Modal title linked with aria-labelledby
• Trap focus in modal (user can't navigate outside)
• Return focus to trigger element on close
• Close with Escape key

Accessible Dropdown/Menu

Dropdown menu requirements:

• Trigger button has aria-haspopup="true"
• aria-expanded indicates if menu is open or closed
• List has role="menu", options have role="menuitem"
• Navigate with up/down arrows between options

Accessible Accordion

Accordion requirements:

• Buttons have aria-expanded to indicate state
• aria-controls links button to controlled panel
• Hidden panel has hidden attribute
• Navigate with Enter/Space to open/close sections

Accessible Carousel

Carousel requirements:

• Container with role="region" and descriptive aria-label
• Navigation buttons with clear aria-label ("Previous slide", "Next slide")
• aria-live="polite" to announce slide change
• Images with descriptive alt text
• Position indicator (e.g., "Slide 1 of 5")

Accessibility Testing

Automated Testing

Tools:

• axe DevTools: Browser extension, CI/CD integration
• WAVE: Visual display of issues
• Lighthouse: Built-in to Chrome
• Pa11y: CLI tool for CI/CD

Limitations:

• Find only 30-50% of issues
• Don't replace manual testing
• False positives/negatives

Manual Testing

Keyboard Testing:

1. Navigate without mouse

2. Check visible focus

3. Test all functions

4. Check logical tab order

Screen Reader Testing:

• NVDA (Windows, free)
• JAWS (Windows, paid)
• VoiceOver (Mac/iOS, built-in)
• TalkBack (Android, built-in)

Zoom Testing:

• Browser zoom to 200%
• Check text reflow
• Don't lose functionality

Testing Checklist

Perception:

• [ ] All images have alt text
• [ ] Video has captions
• [ ] Sufficient contrast
• [ ] Not just color for information

Operability:

• [ ] Navigable with keyboard only
• [ ] Visible focus
• [ ] Functional skip links
• [ ] No focus traps

Understanding:

• [ ] Language declared
• [ ] Labels on forms
• [ ] Errors clearly identified
• [ ] Predictable behavior

Robustness:

• [ ] Valid HTML
• [ ] ARIA correctly used
• [ ] Works in various browsers

Implementation in Practice

Development Workflow

1. Design Phase:

• Color contrast in design system
• Focus states in components
• Annotation for screen readers

2. Development:

• Semantic HTML first
• ARIA when necessary
• Keyboard handling

3. Code Review:

• Accessibility checklist
• Automated linting (eslint-plugin-jsx-a11y)

4. Testing:

• Automated scans in CI/CD
• Periodic manual testing
• User testing with people with disabilities

For WordPress

Accessible Themes:

• Look for "accessibility-ready" tag
• Theme Unit Test data

Plugins:

• WP Accessibility
• Access Monitor
• One Click Accessibility

Content Creation:

• Alt text on all images
• Heading hierarchy
• Descriptive link text

For React/Vue

React:

• Use eslint-plugin-jsx-a11y for automatic linting
• Libraries with built-in accessible components: Radix UI, Reach UI, Chakra UI, Headless UI
• These libraries automatically handle ARIA, focus management, and keyboard navigation

Vue:

• Use eslint-plugin-vuejs-accessibility for linting
• Ensure click handlers have keyboard equivalents (Enter/Space)
• Use components from libraries like Vuetify that have accessibility support

Legal Aspects

European Accessibility Act (EAA)

Timeline:

• Effective: June 28, 2025
• Affects: E-commerce, banking services, transport

Requirements:

• Accessible digital products and services
• WCAG 2.1 AA compliance
• Accessibility documentation

Other Regulations

Romania:

• Law 448/2006 on protection of persons with disabilities
• Alignment with EU directives

US:

• ADA (Americans with Disabilities Act)
• Section 508 for government
• Increasing lawsuits

UK:

• Public Sector Bodies Accessibility Regulations
• Equality Act 2010

Accessibility Statement

What to Include:

• Conformance level
• Known limitations
• Feedback mechanism
• Contact details
• Date of last review

Business Case

ROI of Accessibility

Direct Benefits:

• Access to 15%+ of market
• Avoiding fines and lawsuits
• SEO improvement

Indirect Benefits:

• Positive brand perception
• Innovation driver
• Employee satisfaction

Cost vs Benefit

Implementation cost:

• Minimal if integrated from start
• Higher for remediation
• Training and tools

Savings:

• Avoiding litigation ($$$)
• Reduced support calls
• Increased conversions

Final Checklist

For Launch

Critical:

• [ ] Skip to main content
• [ ] Fully functional keyboard navigation
• [ ] Alt text on images
• [ ] Labels on forms
• [ ] 4.5:1 contrast
• [ ] Clear error messages

Important:

• [ ] Visible focus styling
• [ ] Correct heading hierarchy
• [ ] ARIA landmarks
• [ ] Language attribute

Nice to Have:

• [ ] Dark mode
• [ ] Reduced motion option
• [ ] High contrast mode

Conclusion

Web accessibility is not optional in 2025. It's a legal requirement, a competitive advantage, and simply the right thing to do.

Principles to remember:

• Start with semantic HTML
• Test early and often
• Include users with disabilities
• Continuous, not one-time

Implementation steps:

1. Current audit with automated tools

2. Prioritize critical issues

3. Integrate into workflow

4. Team training

5. Continuous monitoring

---

The DGI team offers web accessibility audit and implementation services. Contact us for an evaluation of your site.