Approximately 1.3 billion
people worldwide live with some form of disability. Visual impairments, motor
disabilities, hearing impairments, and cognitive differences all affect how
people interact with websites. If your website is not accessible, you are excluding
a significant portion of your potential audience.
Beyond the ethical case,
there is also a legal one. In the United States, the ADA (Americans with
Disabilities Act) has been applied to websites, and lawsuits against
inaccessible websites have increased dramatically year over year. The EU Web
Accessibility Directive mandates accessibility for public sector websites.
Building accessible websites is both the right thing to do and increasingly a
legal obligation.
Understanding WCAG: The Accessibility Standard
The Web Content
Accessibility Guidelines (WCAG) are the internationally accepted standard for
web accessibility, published by the W3C. The guidelines are organized around
four principles: Perceivable (information must be presentable in ways all users
can perceive), Operable (users must be able to operate the interface),
Understandable (content must be understandable), and Robust (content must work
with assistive technologies). WCAG 2.1 Level AA is the most commonly required
standard in legislation and accessibility policies.
The Most Important Accessibility Fixes
1. Write Descriptive Alt Text for Images
Every image that conveys
information needs an alt attribute that describes what the image shows. Screen
readers read the alt text aloud to users who cannot see the image. Good alt
text: 'Bar chart showing website traffic increasing 45% from January to June
2024.' Bad alt text: 'image' or 'chart' or leaving alt empty without a reason.
Decorative images (background patterns, purely aesthetic graphics) should have
an empty alt attribute (alt='') so screen readers skip them. Icon images should
have alt text describing their function, not appearance: alt='Search' not
alt='magnifying glass icon'.
2. Ensure Sufficient Color Contrast
Low contrast between text
and its background makes text difficult or impossible to read for people with
low vision or color blindness. WCAG AA requires a contrast ratio of at least
4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). Check your
contrast ratios using WebAIM's Contrast Checker
(webaim.org/resources/contrastchecker) or the axe browser extension. Common
failures: light gray text on white backgrounds, yellow text on white, and pale
blue links on light backgrounds.
3. Make Everything Keyboard Navigable
Many users navigate
entirely by keyboard — they cannot use a mouse due to motor disabilities. Test
your site by unplugging your mouse and navigating with Tab, Shift+Tab, Enter,
Space, and arrow keys. Every interactive element (links, buttons, form fields) must
be reachable and operable by keyboard. Custom interactive components
(dropdowns, modals, carousels) need special keyboard handling that matches
expected ARIA patterns. Never use elements that swallow focus or create
keyboard traps.
4. Provide Visible Focus Indicators
When a user tabs to a
focusable element, there should be a clearly visible outline showing which
element is focused. Many designers remove the default browser focus ring with
outline: none or outline: 0 because they consider it ugly — this is a critical
accessibility mistake. Replace the default ring with a custom, visible,
high-contrast focus style, but never remove it entirely.
5. Structure Your Page with Semantic HTML
Screen readers navigate
pages using landmarks and headings. Use proper HTML elements: nav for
navigation, main for main content, header, footer, section, article, aside for
page regions. Use heading elements (h1-h6) hierarchically to create an outline
of your content — never skip heading levels. Use button elements for clickable
actions and a elements for navigation. Do not use div and span for everything —
semantic elements communicate meaning to assistive technologies at no
additional cost.
6. Write Accessible Forms
Every form input must have
a programmatically associated label. Do not rely solely on placeholder text as
a label — it disappears when the user starts typing. Associate labels using the
for attribute matching the input's id, or by wrapping the input inside the
label element. Group related inputs (like radio buttons or checkboxes for a
single question) with fieldset and legend. When validation fails, communicate
errors clearly in text (not just by color change) and associate the error
message with the relevant input using aria-describedby.
7. Use ARIA Attributes Correctly
ARIA (Accessible Rich
Internet Applications) attributes add semantic meaning to elements when native
HTML is insufficient. Common ARIA attributes: aria-label provides an invisible
label for elements without visible text (like icon-only buttons). aria-hidden='true'
hides decorative elements from screen readers. aria-expanded indicates whether
a collapsible element is open. role attributes define the type of widget for
custom components. The first rule of ARIA: if a native HTML element exists for
what you need, use it instead of ARIA. Native HTML is always preferable.
8. Provide Captions for Video and Audio
Captions make video
content accessible to deaf and hard-of-hearing users. Auto-generated captions
(from YouTube or similar services) are a starting point but often inaccurate —
always edit them for correctness. Provide transcripts for audio content. For
live video, provide real-time captioning.
Testing Accessibility
Automated Testing Tools
axe browser extension
(free, excellent) catches approximately 30-40% of accessibility issues
automatically. WAVE (from WebAIM) visually overlays accessibility information
on your page. Lighthouse (built into Chrome DevTools) includes an accessibility
audit. These tools are essential for catching obvious issues but cannot catch
everything — manual testing is always necessary.
Manual Testing with a Screen Reader
Test with NVDA (free,
Windows), VoiceOver (built into macOS and iOS), or TalkBack (Android). Navigate
your site using only the screen reader and keyboard. Experience your site the
way a screen reader user does — it reveals issues that automated tools miss.
Accessibility Is Not a Sprint, It Is a Practice
Achieving perfect
accessibility on a complex existing website is a project, not a task.
Prioritize the highest-impact issues first: color contrast, alt text, keyboard
navigation, and form labels cover the most users. Add accessibility testing to
your standard code review process. Run automated checks as part of your CI/CD
pipeline. Build accessibility from the start on new projects — retrofitting it
later is far more expensive.
Conclusion
Making your website
accessible means making it better for everyone. High-contrast text is easier
for all users to read. Keyboard navigation benefits power users and people with
motor disabilities alike. Semantic HTML improves SEO alongside accessibility.
Good form labels help all users, not just those with disabilities. Start with
the fixes in this guide, test with automated tools and a screen reader, and
iterate. Accessibility is achievable, and the investment pays dividends in user
experience, SEO, and legal compliance.
