Accessibility Overview

Accessibility means designing so that as many people as possible can understand information and operate a UI across environments, input methods, reading modes, and screen sizes. WCAG 2.2 is a W3C Recommendation that provides guidance for making web content more accessible, organized around four principles: perceivable, operable, understandable, and robust, meaning browsers and assistive technologies can interpret the UI correctly.[1]

When AI generates UI, the result can look polished while still leaving problems such as buttons that do not work from the keyboard, forms without labels, or errors communicated only by color. Treat accessibility as a condition in prompts, design, implementation, and review, not as a final checklist.

Four Accessibility Perspectives

1. Perceivable

Information needs to be recognizable. This includes text contrast, image alternatives, heading structure, and alternatives for audio or video.

WCAG 2.2 contrast criteria require at least 4.5:1 for normal text and at least 3:1 for large text.[1] If you let AI choose colors, also ask it to verify the contrast of the foreground and background combinations.

For every text and background color combination, keep contrast at 4.5:1 or higher
for normal text and 3:1 or higher for large text.
If any combination fails, adjust the color and explain the reason in a comment.

2. Operable

The UI needs to work with mouse, touch, keyboard, and assistive technologies. WCAG 2.2 requires all functionality to be operable through a keyboard interface.[1]

Make every interactive element usable with the keyboard.
Tab order should follow the visual order. Enter or Space should activate buttons.
Modals should close with Escape, and focus should return to the trigger button.

3. Understandable

Users need to understand what the screen means, what an action caused, and how to fix errors. In forms, do not rely on placeholders alone. Provide labels, instructions, and error messages. Communicate errors with text and icons, not only color.

Design the form error state without relying on red alone.
Associate each input with a label. On error, use aria-invalid and connect the input
to a specific error message.

4. Robust (Easy to Interpret)

Browsers, assistive technologies, and evaluation tools need to interpret the UI correctly. WAI-ARIA defines attributes and states that communicate dynamic content and advanced controls to assistive technologies.[2] ARIA is not a replacement for native HTML. Start with meaningful elements such as button, a, label, and fieldset, then add ARIA only where it is needed.

<button type="button" aria-expanded="false" aria-controls="menu-panel">
  Menu
</button>

Requirements to Decide Before Asking AI

Do not only say “make it accessible.” Give AI implementable requirements.

Scroll horizontally→

Perspective	What to specify
Structure	Heading hierarchy, landmarks, form labels
Operation	Keyboard behavior, focus order, Escape and arrow-key behavior
Visuals	Contrast, focus rings, state indicators beyond color
States	Loading, error, success, disabled, selected
Motion	prefers-reduced-motion support
Verification	Automated checks, keyboard testing, screen reader review

This table scrolls horizontally. Keyboard users can focus the table and use the left and right arrow keys.

Basic Checks by Component

Buttons

• Provide visible text or an aria-label.
• Use the button element.
• Support Enter and Space.
• Show a visible focus ring.
• Communicate disabled state with disabled and explanatory text when needed.

Links

• Make the destination or purpose clear from the link text.
• Use a for navigation, even if the link looks like a button.
• Avoid link text such as “here” or “details” on its own.

Forms

• Every input has a label.
• Required status, optional status, and input format are clear.
• Error messages are specific and associated with the relevant field.
• After an error, the user knows what to do next.

Modals

For complex UI such as modals and tabs, use the WAI-ARIA Authoring Practices Guide to confirm roles, states, and keyboard interaction.[3] For modals, check focus movement when the dialog opens, focus containment while it is open, and focus restoration after it closes.

Create a modal:
- Treat it as a dialog
- Move focus to the first interactive element when it opens
- Keep Tab inside the modal
- Close with Escape
- Return focus to the trigger button when it closes

Combine Automated and Manual Verification

W3C explains that evaluation tools help, but no tool alone can determine whether a site meets accessibility standards; knowledgeable human evaluation is required.[4] Use automated checks to find obvious issues such as missing labels, contrast failures, and ARIA mistakes, then manually check keyboard behavior and reading order.

At minimum, verify in this order:

1. Check headings, links, and form meaning in the browser.
2. Operate the page with Tab, Shift+Tab, Enter, Space, and Escape.
3. Run an automated accessibility check for clear violations.
4. Inspect accessible names, roles, and states with a screen reader or accessibility tree.
5. Before asking AI for a fix, describe the failed operation and expected behavior precisely.

References

1. W3C, Web Content Accessibility Guidelines (WCAG) 2.2, December 12, 2024
2. W3C Web Accessibility Initiative, WAI-ARIA Overview
3. W3C Web Accessibility Initiative, ARIA Authoring Practices Guide
4. W3C Web Accessibility Initiative, Evaluating Web Accessibility Overview