The Practice That’s Both Ethical and Practical
Web accessibility — designing and building websites that can be used by people with disabilities, including visual impairments (blindness, low vision, color blindness), motor impairments, hearing impairments, and cognitive disabilities — is simultaneously one of the most impactful practices in web development and one of the most consistently deprioritized. The deprioritization usually comes from a combination of the false belief that it only benefits a small number of users and from the misconception that accessibility requires significant additional effort that can’t be justified in the context of other development priorities.
Both of these beliefs are worth examining. The percentage of people with some form of disability that affects web use is estimated at 15–20% of the population — not a marginal edge case. And many accessibility practices benefit the full user base, not only those with disabilities: good color contrast is easier for everyone to read; keyboard navigation benefits power users; well-labeled forms are clearer for everyone.
Legal and Business Context
Web accessibility is legally required for many organizations in many jurisdictions. In the United States, the Americans with Disabilities Act (ADA) has been interpreted by courts to require accessible websites for businesses open to the public, and ADA accessibility lawsuits have targeted retail websites, restaurant sites, and any business with a significant online presence. The EU’s European Accessibility Act, fully in effect in 2025, extends accessibility requirements to many private sector digital services across all EU member states.
The business case beyond compliance: accessible websites rank better in search engines (because many accessibility practices — descriptive link text, image alt text, clear heading structure — are also SEO best practices), work better for users in suboptimal conditions (bright sunlight on a phone, one hand occupied, noisy environment where audio isn’t usable), and reach users who may be excluded from competitor experiences that aren’t accessible.
The WCAG Guidelines: What They Actually Say
The Web Content Accessibility Guidelines (WCAG), maintained by the W3C, are the international standard for web accessibility. WCAG 2.1 (with 2.2 updates now incorporated into most legal requirements) organizes requirements around four principles: Perceivable (content can be perceived by all users), Operable (interface components can be operated by all users), Understandable (content and operations are understandable), and Robust (content can be interpreted by assistive technologies).
The three conformance levels — A (minimum), AA (standard required for most legal compliance), and AAA (aspirational) — provide a hierarchy of implementation priority. WCAG 2.1 AA is the compliance level required by most laws and regulations. Starting with AA conformance as the target provides a concrete, achievable goal without the full scope of AAA requirements.
The Starting Points With the Most Impact
For a development team starting to address accessibility, the highest-impact starting points are: alt text on all meaningful images (images that convey information should have descriptive alt text; decorative images should have empty alt=”); sufficient color contrast (the WCAG minimum is 4.5:1 contrast ratio for normal text, 3:1 for large text — a contrast checker like the WebAIM Contrast Checker makes this quick to verify); form labels associated with form inputs (every input needs a <label> element connected via ‘for’ attribute, or an aria-label); and keyboard navigability (all interactive elements should be reachable and usable via keyboard alone, without requiring a mouse).
These four areas address the most common accessibility barriers and produce the most significant improvement for the most users. Running an automated accessibility audit tool (Axe, WAVE, Lighthouse’s accessibility audit) against an existing site quickly surfaces violations in these categories alongside others.
Testing With Real Assistive Technology
Automated accessibility testing tools catch approximately 30–40% of accessibility issues — the rest require manual testing, particularly testing with the screen readers that users with visual impairments actually use. NVDA (Windows, free) and VoiceOver (built into Mac and iOS) are the screen readers that provide the most representative testing coverage for web content. Spending an hour navigating your own website with a screen reader and keyboard only, with the monitor turned off or eyes closed, reveals accessibility failures that no automated tool will catch.
Browser developer tools have built-in accessibility panels that show the accessibility tree (how the browser exposes your HTML to assistive technologies) and flag obvious issues. The Chrome DevTools accessibility panel, Firefox’s Accessibility Inspector, and Safari’s Accessibility Audit provide starting points that sit between automated scanning and full manual testing.
