Many business websites shut out some visitors without anyone noticing. Text is too faint to read, menus cannot be reached with a keyboard, and form fields give a screen reader no clue what they are for. Those people leave, and in your analytics they look like any other bounce.
Website accessibility means building your site so people with disabilities can use it, including people who are blind, have low vision, are deaf or hard of hearing, or cannot use a mouse. Most problems come from a short list of fixable issues, and you can check for many of them yourself in an afternoon. This guide is for founders and marketing or operations leads who own a website but do not write code. You will learn what accessibility covers, what the WCAG levels mean, which issues show up most often, and how to run quick checks.
What website accessibility means and who it helps
Accessibility is about whether someone can perceive, understand, navigate, and use your site, whatever way they access it. Some people use a screen reader that reads the page aloud, some navigate with only a keyboard, and others zoom to 200% or rely on captions.
It helps more people than most owners assume. Beyond permanent disabilities, there are temporary ones (a broken wrist) and situational ones (sunlight on a phone screen, or a video watched on a train with the sound off). Older visitors whose eyesight has changed benefit from the same fixes.
There is a business case too. Clear contrast, labeled forms, and logical headings make a site easier for everyone to use, and some of the same work (descriptive alt text, proper heading structure) overlaps with this technical SEO checklist.
WCAG compliance explained: the three levels
WCAG stands for Web Content Accessibility Guidelines. It is published by the W3C, the body that develops web standards. The current version is WCAG 2.2, published in October 2023 with an update in December 2024, and it is also approved as the international standard ISO/IEC 40500:2025, according to the W3C’s WCAG overview.
WCAG is organized into testable success criteria at three levels:
| Level | What it means | Example criteria | Who should aim for it |
|---|---|---|---|
| A | The minimum. Failing these can block some users completely. | Images have text alternatives; everything works by keyboard | Every website |
| AA | The practical standard. Removes the most common barriers. | Body text contrast of at least 4.5:1; visible keyboard focus | Most business websites |
| AAA | The strictest level. Some criteria are hard to meet for every type of content. | Body text contrast of 7:1; sign language for video | Specific pages or audiences |
Each level includes the one below it, so AA means meeting every A and AA criterion. For most businesses, WCAG 2.2 Level AA is the sensible target. If an agency says they build “to WCAG”, ask which version and which level.
The most common accessibility issues
The 2026 WebAIM Million report, an automated analysis of one million home pages, found detectable WCAG failures on 95.9% of them. The most frequent were low contrast text (83.9% of home pages), missing image alt text (53.1%), and missing form input labels (51%). Automated tools only catch certain kinds of problems, so treat those figures as a floor.
Color contrast
Under WCAG 2.2 Level AA, normal text needs a contrast ratio of at least 4.5:1 against its background, and large text (about 24px regular or 18.5px bold) needs at least 3:1, per the W3C’s contrast guidance. Fix it once in your color palette so every page inherits the fix.
Alt text for images
Screen readers read an image’s alt text aloud. A product photo should describe what matters (“Navy wool overcoat, front view”), a chart should state its main takeaway, and purely decorative images should have empty alt text so they are skipped.
Keyboard access
Put your mouse aside and press Tab through your homepage. You should be able to reach every link, button, menu, and form field, see a clear outline showing where you are (the focus indicator), and never get trapped inside a pop-up. Custom dropdowns, sliders, and cookie banners are the usual offenders.
Forms
Every field needs a visible label that stays in place, not placeholder text that vanishes once someone starts typing. Error messages should say what went wrong and how to fix it (“Enter a date as MM/DD/YYYY”), not just turn the border red, because color should never be the only signal.
Headings and structure
Screen reader users often jump from heading to heading to scan a page. Use one H1 per page, then H2s and H3s in order, and never pick a heading tag just for its size. Link text should make sense on its own: “Download the pricing guide” beats “Click here”.
Captions and media
Videos with speech need captions, and audio-only content such as podcasts needs a transcript. Review auto-generated captions, since they often garble product names and numbers. Give people a way to pause carousels and animations.
Quick self-checks you can run today
No developer needed for a first pass: set aside an hour and test your homepage, a key landing page, and your main form.
- Keyboard test: Tab through each page and note anything you cannot reach or cannot see focus on.
- Zoom test: Zoom the browser to 200%. Text should reflow, and nothing should be cut off or overlap.
- Contrast test: Run your brand colors through a free contrast checker, including gray text, buttons, and text over images.
- Automated scan: Run Lighthouse in Chrome DevTools, or a browser extension such as WAVE or axe DevTools.
- Screen reader test: Turn on VoiceOver (built into Mac and iPhone) or NVDA (free for Windows) and try to submit your contact form.
- Sound-off test: Play your main video muted and see whether you can still follow it.
A page can pass an automated scan and still be unusable by keyboard, which is why the manual checks matter. For a broader review that covers usability too, try a structured UX audit.
Website accessibility checklist
Use this accessibility checklist to track your key pages.
| Area | What to check | How to check | WCAG level |
|---|---|---|---|
| Contrast | Normal text 4.5:1, large text 3:1 | Contrast checker on brand colors | AA |
| Images | Meaningful alt text; empty alt on decorative images | Automated scan plus spot check | A |
| Keyboard | Every control usable without a mouse | Manual Tab test | A |
| Focus | Visible focus indicator on interactive elements | Manual Tab test | AA |
| Forms | Visible labels, clear errors, not color alone | Submit the form with mistakes | A and AA |
| Headings | One H1, logical H2 and H3 order | Heading outline extension | A |
| Links and buttons | Descriptive text; none left empty | Automated scan | A |
| Page language | Language set in the HTML | Automated scan | A |
| Media | Captions on video, transcripts for audio | Watch with sound off | A |
| Zoom and reflow | Usable at 200% zoom and on small screens | Browser zoom | AA |
| Motion | Pause controls for carousels and animations | Manual check | A |
Accessibility and the law, in general terms
Accessibility is also a legal topic in many places. In the US, businesses have faced lawsuits under the Americans with Disabilities Act over websites disabled visitors could not use, and the UK’s Equality Act and the EU’s European Accessibility Act also set expectations. Who is covered, and what is required, varies by country and industry.
This article is not legal advice. If you sell into a regulated market or have received a complaint, speak to a lawyer who works in this area. Building toward WCAG 2.2 Level AA and recording what you tested and fixed is far better than doing nothing. Be cautious with “overlay” widgets that promise one-click compliance: a script layered on top of a page cannot reliably fix unlabeled fields or keyboard traps in the code underneath.
Common mistakes
- Treating accessibility as a launch-week task. Retrofitting takes longer than designing for it. Build contrast, focus states, and form patterns into your components, as covered in this design system guide.
- Trusting automated scores alone. A perfect Lighthouse score does not prove a site works with a keyboard or screen reader.
- Fixing pages instead of components. If the button component has no focus style, every page has the bug.
- Ignoring third-party tools. Chat widgets, booking tools, and cookie banners are part of your site as far as visitors are concerned.
Building accessible website design into your next project
Accessibility is cheapest when it is part of the brief. Add “WCAG 2.2 Level AA” to your requirements, ask agencies how they test (manual keyboard and screen reader checks, not just a scan), and include it in your acceptance criteria. If a rebuild is coming, add these items to your website redesign checklist. In UI/UX design, contrast, type sizes, focus states, and form patterns get decided early in the UI/UX design process, when they are cheap to change, and developers then turn them into semantic HTML and full keyboard support.
Conclusion
Website accessibility comes down to a handful of habits: readable contrast, meaningful alt text, full keyboard access, labeled forms, clean headings, and captions. Run the self-checks on your most important pages, fix anything that stops people from completing a task first, then work through the checklist and retest whenever you add features or third-party tools.
If you want help, Vynix Digital’s UI/UX design service builds accessibility into wireframes, prototypes, and Figma design systems, and our web development service turns those designs into well-structured, accessible front ends. To talk through your site or an upcoming project, reach out through our contact page.
