WCAG 2.2 for Web and Product Designer

In today’s digital landscape, accessibility isn’t optional—it’s essential. As more users access online content through various devices and assistive technologies, web and product designers must adhere to accessibility standards to ensure their platforms are usable by all. WCAG 2.2 (Web Content Accessibility Guidelines) provides a roadmap to create inclusive designs that cater to people with disabilities. Let’s explore how designers can apply these guidelines effectively, with concrete examples for each key principle. A bit thank you to Andrew Hick for inspiring this article.

1. What is WCAG and Why Should Designers Care?

a. Introduction to WCAG 2.2

WCAG (Web Content Accessibility Guidelines) is a set of standards aimed at making digital content accessible to people with disabilities. Version 2.2 builds on previous versions, adding new success criteria to address a broader range of user needs, particularly for people with cognitive and learning disabilities, low vision, and mobility impairments.

• A: Minimum accessibility standards.
• AA: Mid-range accessibility, often the legal requirement.
• AAA: Highest standard, typically recommended for enhanced accessibility.

b. Why Designers Should Apply WCAG

Incorporating accessibility improves user experience for everyone, increases market reach, and can ensure compliance with legal requirements like the Americans with Disabilities Act (ADA) or the European Accessibility Act. By making content accessible, designers not only meet diverse user needs but also enhance brand reputation and usability for all.

2. Breaking Down the WCAG 2.2 Map

The WCAG 2.2 map (above) groups success criteria into six key themes. Below, we’ll provide concrete examples of how to apply each guideline.

a. Keyboard Navigation

Users with limited mobility often rely on keyboards for navigation. Designers must ensure that all interactions can be accessed without a mouse.

• No Keyboard Trap (2.1.2): Ensure users can navigate away from any interactive element using only the keyboard.
  • Example: A modal pop-up should always have an accessible “close” button that can be focused on and activated using the Tab key and the Enter key.
  • Specific Setting: In JavaScript, check that focus returns to the correct element after closing the modal (e.g., modal.close() should focus on the triggering element).
• Visible Focus Indicators (2.4.7): The focus should be clear when navigating via the keyboard.
  • Example: Use CSS like outline: 2px solid #005fcc; to ensure that when users navigate with Tab, the focused element is visually distinct.
  • Specific Setting: Avoid removing the focus outline globally with styles like outline: none;—this can create an invisible focus state.

b. Zoom and Legibility

Many users need to zoom in on text or use screen magnifiers. Designers should make sure content remains accessible at all sizes.

• Text Resizing Without Losing Functionality (1.4.4): Text should resize to 200% without breaking layouts.
  • Example: When zooming into a webpage (Ctrl +), ensure that text doesn’t overlap other content or require horizontal scrolling. Use relative units like em or % instead of fixed pixels (px) in CSS for responsive text.
• Content Reflow (1.4.10): Layout should reflow on small screens without requiring users to scroll horizontally.
  • Example: Use CSS Grid or Flexbox to ensure the layout adapts to different screen sizes. Set a maximum width for text containers like max-width: 100ch; to avoid long lines that become hard to read at higher zoom levels.

c. Gestures

Touch gestures need to be intuitive and accessible, particularly for mobile users with motor impairments.

• Pointer Gestures (2.5.1): Complex gestures (like multi-finger swipes) should have simpler alternatives.
  • Example: Instead of requiring a three-finger swipe to delete an item, offer an alternative like a button with a trash can icon that users can tap or select via keyboard input.
• Target Size (2.5.5): Ensure interactive elements are large enough to tap easily on mobile.
  • Example: Buttons should be at least 44×44 pixels on mobile screens. In CSS, you can ensure button size using min-width: 44px; min-height: 44px; to accommodate touch-based interactions.
• Specific Settings: In Figma, use the “Touch Target” plugin to test that your interactive elements meet the recommended size guidelines.

d. Forms and Labels

Forms are common areas where accessibility can break down. Proper labeling and error handling are essential.

• Labels and Instructions (3.3.2): Every form input should have a descriptive label.
  • Example: Use <label> tags with for attributes connected to the corresponding <input> fields. Ensure that users with screen readers hear the correct label before entering data.
• Error Identification (3.3.1): Clearly identify form errors and help users correct them.
  • Example: If a required field is missed, provide a message like “This field is required,” next to the input, not just in red text. Add aria-live="polite" to ensure screen readers announce the error.
• Specific Settings: In HTML, set the aria-describedby attribute for form inputs to provide additional error details.

e. Sensory and Visual Content

Multimedia content must accommodate users who rely on audio descriptions, captions, or other assistive technologies.

• Captions (1.2.2): All prerecorded video should have captions.
  • Example: If you embed YouTube videos, make sure that captions are enabled or manually uploaded. You can use a captioning service like Rev or an auto-captioning tool like Descript.
• Audio Control (1.4.2): Allow users to pause, stop, or control the volume of audio content.
  • Example: Provide a mute button or visible controls to stop audio from playing automatically. Avoid background music that can’t be paused.
• Specific Settings</ strong>: Use aria-controls attributes for media players to link controls with their associated media content for screen reader users.

3. WCAG is a Continuous Journey

Accessibility isn’t a one-time task; it’s an ongoing commitment to ensuring your product or website is usable by all. Incorporating the WCAG 2.2 guidelines into your UI design workflow not only helps your users but also future-proofs your projects against evolving legal requirements.