Website Accessibility: Making Your Site Work for Everyone
5 min read
What Is Website Accessibility?
Website accessibility means building your website so that everyone can use it — including people with disabilities. That means people who are blind and use screen readers, people who are deaf and need captions, people with motor disabilities who can't use a mouse, and people with cognitive disabilities who need clear, simple layouts.
This isn't a niche concern. One in four American adults — about 61 million people — lives with a disability. Globally, that number is over one billion. If your website doesn't work for them, you're excluding a massive group of potential customers.
And here's the thing most people don't realize: accessibility improvements make your site better for everyone, not just people with disabilities. Captions help people in noisy environments. Clear navigation helps everyone find what they need. Good color contrast is easier to read in bright sunlight.
Why It Matters: The Legal Side
Website accessibility isn't optional in many situations. In the US:
The ADA (Americans with Disabilities Act) has been interpreted by courts to apply to websites, especially for businesses that serve the public. Lawsuits over inaccessible websites have increased dramatically — over 4,000 were filed in 2023 alone.
Section 508 requires federal agencies and organizations receiving federal funding to make their digital content accessible.
In the EU, the European Accessibility Act requires private-sector digital services to be accessible starting in 2025.
You don't need to be a massive corporation to get sued. Small businesses, including restaurants, retail shops, and local service providers, have faced accessibility lawsuits. An ounce of prevention is worth a pound of legal fees.
Common Accessibility Problems
Most accessibility issues fall into a few categories. Here are the ones we see most often:
Missing Alt Text on Images
Alt text is a short description of an image that screen readers read aloud. When an image has no alt text, a blind user hears... nothing. Or worse, they hear the file name: "IMG_4738.jpg."
Every meaningful image on your site should have descriptive alt text. Not "image of building" — more like "Front entrance of Smith Law Offices on Main Street."
Decorative images (like background patterns or dividers) should have empty alt text (alt="") so screen readers skip them entirely.
Poor Color Contrast
If your text is light gray on a white background, it looks stylish but is impossible to read for people with low vision — and annoying for everyone else. The WCAG (Web Content Accessibility Guidelines) require a minimum contrast ratio of:
Not everyone uses a mouse. People with motor disabilities often navigate websites entirely with a keyboard — using Tab to move between links and buttons, Enter to activate them, and arrow keys to scroll.
If your website only works with a mouse (clickable elements that don't receive keyboard focus, dropdown menus that only open on hover), you're locking out keyboard-only users.
Missing Form Labels
If your contact form has input fields without proper labels, a screen reader user has no idea what information to enter. They hear "edit text" instead of "Email address."
Every form field needs a <label> element that describes what goes in the field.
Auto-Playing Media
Videos or audio that play automatically when a page loads are jarring for everyone and especially problematic for screen reader users, whose experience gets disrupted by unexpected sound.
Don't auto-play media. If you must, provide a clearly visible way to pause or stop it.
Missing Page Structure
Screen reader users rely on heading structure (H1, H2, H3) to understand and navigate your page. If your page doesn't use headings — or uses them out of order for visual styling — the page structure is invisible to screen readers.
Use headings to create a logical outline of your page content. H1 for the main title, H2 for major sections, H3 for subsections.
Quick Wins: What You Can Fix Today
You don't need to overhaul your entire site at once. Start with these high-impact fixes:
Add alt text to all images — Go through your site and add descriptive alt text to every meaningful image
Check your color contrast — Use WebAIM's contrast checker on your text and background color combinations
Test keyboard navigation — Put your mouse aside and try using your site with only your keyboard. Can you reach everything? Can you see where you are?
Add labels to form fields — Make sure every input has an associated label
Check your heading structure — Do your headings create a logical outline?
These five changes alone will dramatically improve your site's accessibility.
Testing Your Site
A few tools that help identify accessibility issues:
WAVE (wave.webaim.org) — Free browser extension that highlights accessibility issues directly on your page. Great for a quick visual audit.
Lighthouse — Built into Chrome DevTools. Run an accessibility audit from the Audits tab in DevTools.
axe DevTools — Free browser extension from Deque. Provides detailed accessibility reports with explanations of each issue.
Manual testing — No tool catches everything. Try navigating your site with a keyboard. Try using a screen reader (VoiceOver on Mac, Narrator on Windows). You'll find issues no automated tool can.
The Bottom Line
Website accessibility is the right thing to do, it's increasingly a legal requirement, and it makes your site better for everyone. You don't need to achieve perfection overnight — start with the quick wins, test regularly, and improve over time. The businesses that get this right will reach more customers and avoid the legal headaches that come with ignoring it.
Want help making your website accessible? Get in touch — we'll audit your site and fix the issues that matter most.
WCAG Standards, ARIA Attributes, and Building Accessibility Into Your Workflow
Let's dig into the technical standards and implementation details behind website accessibility.
WCAG: The Accessibility Standard
The Web Content Accessibility Guidelines (WCAG) are the international standard for web accessibility, published by the W3C (World Wide Web Consortium). There are three conformance levels:
Level A — The bare minimum. Addresses the most critical barriers that would make content completely inaccessible. Examples: all images have alt text, all form fields have labels, no content relies solely on color to convey information.
Level AA — The standard most laws and organizations target. Includes everything in Level A plus additional requirements like sufficient color contrast, resizable text, and consistent navigation.
Level AAA — The highest level. Includes everything in AA plus requirements like sign language interpretation for video, enhanced contrast ratios, and simpler reading levels. Few organizations achieve full AAA compliance — it's more of an aspirational target.
For most businesses, Level AA is the target. This is what the ADA lawsuits reference, what most accessibility overlays claim to provide, and what gives you a solid foundation of accessibility.
The current version is WCAG 2.2 (published in 2023), though WCAG 2.1 is still widely referenced.
The Four Principles: POUR
WCAG is organized around four principles, known by the acronym POUR:
Perceivable — Users must be able to perceive the content. This covers alt text, captions, contrast, and alternatives for any content that relies on a single sense.
Operable — Users must be able to navigate and interact with the interface. This covers keyboard accessibility, sufficient time to read content, and navigation that doesn't cause seizures.
Understandable — Content and interface must be understandable. This covers readable text, predictable behavior, and clear error messages.
Robust — Content must be robust enough to work with current and future assistive technologies. This covers valid HTML, proper use of ARIA, and compatibility with screen readers.
ARIA: Filling the Gaps in HTML
ARIA (Accessible Rich Internet Applications) is a set of attributes you can add to HTML elements to provide additional information to screen readers. It's especially important for interactive elements that HTML alone can't fully describe.
Common ARIA attributes:
aria-label — Provides an accessible name for an element when visible text isn't sufficient. <button aria-label="Close dialog">X</button> tells screen readers the button closes a dialog, not that it's labeled "X."
aria-describedby — Links an element to a longer description elsewhere on the page. Useful for form fields that need additional instructions.
aria-hidden="true" — Hides an element from screen readers while keeping it visible. Use for decorative elements that add visual noise but no meaning.
aria-live — Announces dynamic content changes to screen readers. When a notification appears on screen, aria-live="polite" tells the screen reader to announce it when there's a pause in activity.
role — Defines what an element is. role="navigation" tells screen readers this is a navigation section. role="alert" announces important messages immediately.
The golden rule of ARIA: Use native HTML elements whenever possible. A <button> is always better than a <div role="button">. ARIA is for when HTML falls short, not as a replacement for proper HTML.
Accessibility Overlays: Why They Don't Work
You may have seen accessibility widgets — those little icons that float in the corner of a website offering to "fix" accessibility with font resizing, contrast adjustments, and screen reader modes. Companies like AccessiBe, UserWay, and AudioEye sell these as quick fixes.
The accessibility community overwhelmingly rejects these tools. Here's why:
They don't fix underlying code issues — a missing alt tag is still missing regardless of what the widget does
They can actually interfere with real assistive technology that users already have
They create a separate, inferior experience for disabled users rather than making the main experience work
Multiple lawsuits have been filed against websites using these overlays, not despite them
The National Federation of the Blind has spoken out against overlay products
Real accessibility requires fixing the actual code of your website. There are no shortcuts.
Screen Reader Testing Basics
Testing with a screen reader is the most effective way to understand your site's accessibility. Here's how to get started:
On Mac — VoiceOver:
Press Cmd + F5 to turn it on
Use Tab to navigate interactive elements
Use VO keys (Ctrl + Option) plus arrow keys to read through content
Press VO + U to open the rotor (a table of contents for the page)
On Windows — NVDA (free):
Download from nvaccess.org
Press Insert + Down Arrow to start reading
Tab navigates interactive elements
H jumps between headings, K between links
Key things to check:
Can you understand every image from its alt text alone?
Do form fields announce their labels?
Can you navigate the entire page using headings?
Do interactive elements (menus, buttons, dialogs) announce their state?
Is the reading order logical?
Building Accessibility Into Development
The cheapest time to fix accessibility issues is during development, not after:
Use semantic HTML — <nav>, <main>, <header>, <footer>, <article>, <section>. These elements communicate page structure to assistive technology automatically.
Include accessibility in design reviews — Check contrast ratios, font sizes, and touch target sizes before any code is written.
Run automated tests in CI/CD — Tools like axe-core can catch many accessibility issues automatically during your build process.
Include manual accessibility testing in QA — No automated tool catches everything. Keyboard testing and screen reader testing should be part of your regular QA checklist.
Accessibility isn't a feature you bolt on at the end. It's a quality standard that should be part of every decision, from design to deployment.
Want a professional accessibility audit of your website? Get in touch — we'll identify the issues, prioritize the fixes, and help you build accessibility into your workflow going forward.