The Curb Cut Effect
When curb cuts — the ramped edges of sidewalks — were first mandated in Berkeley, California in the 1970s, they were explicitly designed for wheelchair users. The city engineers who opposed them argued they would be unnecessary for the general public, expensive, and would clutter sidewalks with features most people didn't need. The engineers were wrong. Curb cuts turned out to be used constantly by people pushing strollers, delivery workers with hand trucks, cyclists, and anyone carrying heavy bags. The accommodation for one specific group produced infrastructure that improved movement for everyone.
This is the curb cut effect, and it applies directly to interface design. Captions designed for deaf users help people watching videos in noisy environments, non-native speakers following along in a second language, and anyone who wants to search video content by text. Keyboard navigation designed for motor-impaired users enables power users to work faster without leaving the keyboard, and makes interfaces scriptable. High-contrast modes designed for low-vision users improve readability in bright sunlight for everyone. Large touch targets designed for users with tremors are easier for anyone to tap on a moving train.
The framing of accessibility as "for disabled users" is not just ethically limiting — it is strategically wrong. Accessibility improvements reliably improve usability for everyone. Teams that treat accessibility as a compliance checkbox, squeezed in at the end of the design process, are not just failing their disabled users; they are producing worse products for their entire user base.
The Four Principles: POUR
WCAG (Web Content Accessibility Guidelines) organizes accessibility requirements around four core principles, abbreviated as POUR. Understanding these principles is more valuable than memorizing any specific technical requirement, because they provide the reasoning behind the requirements — which enables you to make good accessibility decisions in situations the guidelines don't explicitly cover.
Color and Contrast
Color is one of the most commonly misused design elements from an accessibility standpoint. There are two distinct problems: insufficient contrast (text that's hard to read against its background) and using color alone to convey meaning (links that are only distinguished from body text by color, error states that are only indicated by red).
WCAG 2.1 AA requires a minimum contrast ratio of 4.5:1 for normal text (under 18pt) and 3:1 for large text (18pt or larger, or 14pt bold). AAA compliance requires 7:1 for normal text. These ratios are not arbitrary — they are derived from research on the actual contrast sensitivity thresholds for users with low vision conditions like cataracts, glaucoma, and age-related macular degeneration. A ratio that passes visually for you may fail entirely for 8% of your male users who have some form of color vision deficiency.
The "color alone" problem is subtler. An error state indicated only by red text fails users with protanopia or deuteranopia (red-green color blindness) — they see the same text as normal users, just in a different hue. The fix is to pair color with a secondary signal: an icon, a label, a border, a changed position in the layout. Test your interfaces in grayscale periodically; anything that stops communicating its meaning in grayscale is relying too heavily on color alone.
Focus Management and Keyboard Navigation
Keyboard navigation is the accessibility requirement most frequently broken by modern JavaScript-heavy interfaces. Single-page applications that use custom routing, modals that appear and disappear, components that manage their own interaction state — all of these have the potential to trap keyboard focus, lose it entirely, or produce a tab order that doesn't reflect the visual layout of the page.
Visible focus indicators are not optional — they are a WCAG 2.1 AA requirement (Success Criterion 2.4.7) and a WCAG 2.2 AA requirement (Success Criterion 2.4.11 with enhanced requirements). Removing the browser default outline with outline: none without providing an equivalent custom indicator is one of the most common accessibility failures on the web. The "it looks bad" argument is a design failure, not a reason to fail keyboard users. Design a focus indicator that works within your visual language.
Modal focus trapping is a nuanced requirement: when a modal opens, keyboard focus should move to it and be trapped within it (users should not be able to tab to content behind the modal) until the modal is closed, at which point focus should return to the element that triggered the modal. Getting this right requires careful JavaScript implementation, but it is essential — a modal that doesn't trap focus effectively makes its content inaccessible to keyboard users, and a modal that doesn't restore focus on close disrupts the navigation flow completely. Skip links ("Skip to main content") should be present on every page to let keyboard users bypass repeated navigation.
Screen Reader Semantics
Screen readers convert the visual interface into audio or braille output, navigating the DOM structure of the page. They depend entirely on the HTML being semantically correct — using the right elements for the right purposes, with the right ARIA attributes where native HTML semantics are insufficient.
Alt text for images is the most widely known requirement, but it's frequently misimplemented. Alt text should describe the purpose of the image in context, not its visual appearance. A photo of a person on an About page should say "Sarah Chen, Senior Engineer" not "woman with dark hair wearing a blue sweater in front of a blurred background." An decorative divider image should have an empty alt attribute (alt="") so screen readers skip it, not a description of the decoration. A chart should have alt text that conveys the insight the chart communicates, not a description of the visual elements.
ARIA live regions are essential for dynamic content. When content updates without a page reload — a toast notification, a status update, a new message — screen reader users don't automatically know the update occurred. Using aria-live="polite" or aria-live="assertive" on a container element tells the screen reader to announce updates to its contents. Use "assertive" sparingly — it interrupts whatever the user is currently doing to make the announcement. "Polite" queues the announcement for the next natural pause. Landmark regions (<main>, <nav>, <header>, <footer>, <aside>) help screen reader users navigate page structure quickly.
What "Accessible by Default" Looks Like
The most sustainable accessibility approach is to make accessible choices the default at the component and pattern library level, rather than auditing finished designs for accessibility compliance. This means every button component has visible focus styles; every image placeholder requires alt text; every form field has a visible label (not just a placeholder); every color decision is run through a contrast checker before it becomes a token in the design system.
Touch targets deserve special attention. Apple's Human Interface Guidelines recommend a minimum tappable area of 44×44 points; Google's Material Design recommends 48×48dp. The 44px minimum is not a WCAG hard requirement (WCAG 2.5.5 is AAA, not AA) but it is a practical requirement for users with motor impairments, tremors, or large fingers, and for anyone using a phone on a bumpy commute. Components that are visually smaller can still meet the requirement by having an invisible hit area that extends to the minimum size. This is a small engineering investment with a large usability return.
Plain language is the accessibility requirement most frequently overlooked by designers and engineers — perhaps because it feels more like editorial than design. But reading level is a real accessibility dimension. Complex sentence structures, unexplained jargon, ambiguous error messages — these create barriers for users with cognitive disabilities, low literacy, or non-native language proficiency. The plain language principle — use the simplest language that accurately conveys the meaning — is not a dumbing-down of content. It is a clarity constraint that produces better communication for all users, including highly literate ones who appreciate directness.