♿ Accessibility - WCAG & ARIA

Accessibility is “Search Engine Optimization for people.” A site that is accessible is inherently more indexable, more performant, and more robust. A Programmer designs for Semantic HTML first and only reaches for ARIA when native elements cannot fulfill the required behavior.

📜 1. WCAG (Web Content Accessibility Guidelines)

The international standard for web accessibility, organized under four principles: P.O.U.R.

P: Perceivable: Information must be presentable to users in ways they can perceive (e.g., Alt text for images, captions for video).
O: Operable: Interface components must be operable (e.g., Keyboard navigation, no content that causes seizures).
U: Understandable: Users must be able to understand the information and the operation of the user interface.
R: Robust: Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies.

🏷️ 2. Semantic HTML vs. ARIA

The first rule of ARIA is: If you can use a native HTML element with the behavior you need, do it.

Native Semantics: Using <button> instead of <div onclick="...">. The button automatically handles focus, the “Enter” key, and announces itself correctly to screen readers.
ARIA (Accessible Rich Internet Applications): Attributes added to HTML to bridge the gap when native elements don’t exist (like a complex Tree View or a Slider).
- aria-label: Provides a string as an accessible name (useful for icon-only buttons).
- aria-expanded: Indicates if a menu or accordion is open.
- aria-live: Informs screen readers about dynamic updates (e.g., a “Success” message appearing after a form submission).

Many users rely entirely on a keyboard or switch device.

Focus Visible: Never use outline: none in your CSS unless you are providing a high-contrast custom focus state.
Focus Order: The tabindex should follow the visual and logical flow of the page. Avoid tabindex="1" (it breaks the natural flow); use tabindex="0" to make an element focusable or tabindex="-1" to allow programmatic focus.
Focus Traps: When a Modal is open, the user should not be able to “Tab” out into the background page. You must programmatically “trap” the focus inside the modal until it is closed.

🎨 4. Visual Accessibility

Color Contrast: Text must have a contrast ratio of at least 4.5:1 against its background (WCAG AA). For large text, 3:1 is acceptable.
Don’t rely on color alone: If an input field has an error, don’t just turn the border red. Add an icon or an “Error” text label so color-blind users can identify the issue.
Text Scaling: Ensure your layout doesn’t break when a user increases their browser font size to 200%. Use rem or em units instead of fixed px.

🛠️ Implementation Patterns

A hidden link at the very top of the page (usually becomes visible on focus) that allows keyboard users to skip the navigation and jump directly to the main content.

<a href="#main-content" class="skip-link">Skip to main content</a>

2. Form Labels

Every input must have a label. If the design doesn’t allow a visible label, use aria-label or a visually hidden label.

Programmer’s Move: Use aria-describedby to link input fields to their specific error messages or helper text so they are read together by screen readers.

3. Automated & Manual Testing

Automated: Integrate axe-core, Lighthouse, or pa11y into your CI/CD. This catches ~30-40% of issues (like missing alt text).
Manual: You must test with a screen reader (NVDA or JAWS on Windows, VoiceOver on Mac) and perform a No-Mouse Challenge to truly verify the experience.

💡 Note: Accessibility is a team sport. It starts with Design (contrast and layout) and ends with Engineering (clean code). As a Programmer, your role is to push back on designs that are fundamentally inaccessible (e.g., low-contrast gray text on a white background).