Website accessibility: the basics every business site should meet
The WCAG 2.2 checks that cover most problems on a company site: contrast, text size, keyboard use, focus, alt text and labels, with how to test each one.
By Sohail Hussain29 October 20267 min read
A business website should meet WCAG 2.2 at level AA. In practice, twelve checks cover most of what goes wrong on a company site: colour contrast, text that can be enlarged, every control reachable by keyboard, visible focus, alt text on images, labelled form fields, headings in order, a skip link, a page language, captions on video, descriptive links, and nothing that moves or flashes without a way to stop it.
None of them needs a specialist. They need a developer who builds with plain HTML and a reviewer who tests with a keyboard. This post lists the checks, what the common failures look like, and how to test without hiring an auditor.
What is WCAG 2.2, and which level should you aim for?
The Web Content Accessibility Guidelines are published by the W3C, the body that sets web standards. Version 2.2 became the current recommendation in October 2023 and the full text is at w3.org/TR/WCAG22. It is organised around four principles: content must be perceivable, operable, understandable, and built so that assistive technology can read it.
Each rule, called a success criterion, is rated A, AA or AAA. Level A is the minimum; AA is what laws and procurement rules around the world reference; AAA is a stretch for specific contexts and not expected of a whole site. Aim for AA. Anyone who tells you a business site needs AAA is selling an audit.
Is accessibility a legal requirement for a business site?
Increasingly, and the direction is one way. India's Rights of Persons with Disabilities Act 2016 and its 2017 rules require ICT, including websites, to meet accessibility standards, and the Guidelines for Indian Government Websites mandate WCAG for public sector sites. In the EU, the European Accessibility Act has applied to e-commerce and a range of online services since June 2025. In the US, the ADA has been applied to websites through case law for years, and a 2024 Department of Justice rule set WCAG 2.1 AA as the standard for state and local government sites.
What this means for a private company varies by country, sector and size. If you sell online, serve the public, or bid for government or large-company contracts, assume someone will ask. Check with your lawyer for your own situation. The engineering answer is the same either way: build to AA from the start, which costs little, rather than retrofit later, which does not. It is the target we write into every website design and development proposal for that reason.
What are the checks, and how do you test each one?
| Check | WCAG 2.2 criterion | How to test |
|---|---|---|
| Text contrast of at least 4.5:1 (3:1 for large text) | 1.4.3 Contrast (Minimum), AA | Paste foreground and background into the contrast checker |
| Interface and icon contrast of at least 3:1 | 1.4.11 Non-text Contrast, AA | Same tool, on button borders, icons and form field outlines |
| Text can be enlarged to 200 percent | 1.4.4 Resize Text, AA | Zoom the browser to 200 percent; nothing should clip or overlap |
| Page works at 320 pixels wide with no sideways scroll | 1.4.10 Reflow, AA | Narrow the browser or use device mode in DevTools |
| Everything works with a keyboard alone | 2.1.1 Keyboard, A | Unplug the mouse and use Tab, Enter, Space and the arrow keys |
| You can always see which element has focus | 2.4.7 Focus Visible, AA | Tab through; the focus ring must be visible on every control |
| Focus is not hidden behind sticky headers or banners | 2.4.11 Focus Not Obscured, AA (new in 2.2) | Tab to a link near the bottom of the screen with a sticky header present |
| Tap targets at least 24 by 24 CSS pixels | 2.5.8 Target Size (Minimum), AA (new in 2.2) | Measure icons, close buttons and inline controls in DevTools |
| Images have alt text; decorative ones have empty alt | 1.1.1 Non-text Content, A | Lighthouse or axe flags missing alt; read the ones present for sense |
| Form fields have visible labels, and errors say what to fix | 3.3.1, 3.3.2, A, and 1.3.1 | Click a label; the field should focus. Submit an empty form and read the errors |
| Headings describe the structure, in order | 1.3.1 Info and Relationships, A, and 2.4.6, AA | View the heading outline in a browser extension; no skipped levels |
| A skip link to the main content | 2.4.1 Bypass Blocks, A | Press Tab once on page load; "Skip to content" should appear |
| Page language declared | 3.1.1 Language of Page, A | lang attribute on the html element; lang="ar" on Arabic pages |
| Video has captions; audio has a transcript | 1.2.2 Captions (Prerecorded), A | Play with sound off |
| Link text makes sense on its own | 2.4.4 Link Purpose (In Context), A | Read only the links on the page; "click here" fails |
| Moving, scrolling or auto-updating content can be paused | 2.2.2 Pause, Stop, Hide, A | Every carousel and autoplaying video needs a visible pause control |
The W3C's quick reference lists every criterion with techniques and failure examples, and is the page to send a developer who asks what a criterion means.
What do the most common failures look like on a company site?
The same handful, project after project.
- Light grey text on white. Brand palettes chosen for print often fail 4.5:1 on screen. The fix is a darker grey for body text, which nobody notices and everyone can read.
- Placeholder text used as the label. It disappears when you start typing and is usually too light to pass contrast anyway. Labels go above the field.
- Icon buttons with no name. A magnifying glass, a hamburger, an X. Screen readers announce "button". Each needs text, visible or as an
aria-label. - Focus styles removed. Someone added
outline: nonebecause the ring looked untidy, and now keyboard users cannot see where they are. - Hover-only menus. Dropdowns that open on mouseover cannot be opened on a phone or by keyboard.
- Autoplaying carousels with no pause button, which fail 2.2.2 and are also the section visitors skip.
- Content only in a PDF or an image. A brochure PDF or a JPEG of a price list is invisible to screen readers and to search engines alike.
- Cookie banners that trap focus or sit over the content a keyboard user is trying to reach, which is the new 2.4.11 criterion in action.
When we design and build a site as part of a website design and development project, contrast is checked at the palette stage, before any page is designed, because fixing a brand colour after sign-off is a harder conversation than fixing it in week one.
How do you test without hiring an auditor?
Four tests, in order of how much they find per minute spent.
- Tab through every page template. Home, a service page, the contact form, the blog. Can you reach every link and button, see where you are, and operate the menu? This single test finds more than any automated tool.
- Zoom to 200 percent and narrow to 320 pixels. Text should reflow, not clip, and nothing should need sideways scrolling.
- Run Lighthouse or the axe DevTools extension. Both are free and built into or added to Chrome. They catch missing alt text, contrast failures, missing labels and bad heading order. They cannot judge whether alt text is useful or whether a page makes sense, so treat a clean automated report as a start, not a pass.
- Spend five minutes with a screen reader. VoiceOver is built into every Mac and iPhone; NVDA is free on Windows. Turn it on, close your eyes, and try to find the phone number. You will find something.
Do this before launch and put it on the launch checklist. Then do the Tab test again whenever a new component is added, because accessibility is lost one widget at a time.
Do accessibility overlay widgets fix the problem?
No. The widgets that add a floating icon and promise compliance with one line of JavaScript do not change the underlying HTML, so a missing label is still missing, an unreachable menu is still unreachable, and a screen reader still reads the broken page. Some of them interfere with the assistive technology a visitor already runs. They have also not protected the companies using them from legal complaints.
If a vendor offers one as a shortcut, decline it and spend the money on the fixes in the table above. They are mostly small.
What should you ask your developer for?
A short list, written into the brief so it is not an afterthought:
- WCAG 2.2 AA as the target, stated in the proposal.
- Semantic HTML: real buttons, real links, real headings, real form labels.
- A visible focus style on every interactive element, designed rather than removed.
- Contrast checked on the palette before design sign-off.
- Keyboard and screen reader testing on each page template before launch, with the results shared.
- Alt text as a field in the CMS, so your team can fill it in for every image they upload.
Most of this is how a careful developer builds anyway. Asking for it makes sure the careless shortcuts are off the table. It belongs in the brief at the start of the project, alongside the page list and the mobile-first requirement, which shares the same tap target and text size rules. Our guide on how to plan a company website covers where it fits.
Was this guide useful?