Launch in Days, Not Weeks
Professional one-page website. Only a few slots left this month
Accessibility audits often produce 400-page reports that paralyse teams into doing nothing. The truth is most UK B2B sites can fix 80 percent of their accessibility issues with a dozen practical changes. Here is what to prioritise, what the law actually requires, and what to ignore for now.
What UK Law Actually Says
The legal framework for private sector website accessibility in the UK rests on the Equality Act 2010. Unlike the public sector, which has specific Web Accessibility Regulations with fixed WCAG 2.1 AA requirements, private sector businesses have a more general duty under the Equality Act: they must not discriminate against disabled people and must make “reasonable adjustments.”
What “reasonable adjustments” means in practice has been tested in case law. The key principle is proportionality. A large enterprise with significant resources faces a higher threshold of obligation than a small business. But even small businesses can face complaints and claims if their digital presence presents a genuine barrier to disabled customers.
The practical risk for most UK B2B businesses is not a regulatory fine (there is no blanket private sector accessibility regulator equivalent to the US ADA). The risk is an Equality Act claim, reputational exposure if accessibility issues are called out publicly, and the real commercial cost of excluding a segment of potential clients.
In the UK, around 22 percent of working-age adults have a disability. Of those, many are decision-makers, procurement managers, and senior buyers. The accessibility argument is not purely compliance; it is basic commercial sense.
WCAG 2.2: What Changed and What Matters
WCAG 2.2 became the current standard in October 2023. It added nine new success criteria on top of the WCAG 2.1 foundation.
The new criteria most relevant to UK B2B sites are:
Focus Appearance (AA level). When an element is focused via keyboard navigation, it must be clearly visible. Many sites style away the default browser focus ring and replace it with nothing. This blocks keyboard users from navigating.
Dragging Movements (AA level). Any functionality achievable by dragging must also be achievable without dragging. Relevant for sliders, interactive pricing tools, or drag-to-reorder features.
Target Size (AA level). Clickable elements must have a minimum target size of 24x24 pixels. Most desktop sites pass this; mobile sites with small tap targets often fail.
Accessible Authentication (AA level). Login and verification processes cannot rely solely on cognitive function tests (typing in random characters, solving puzzles) without an alternative method. Affects any B2B site with gated content or a client portal.
The criteria that were removed in 2.2: Parsing (4.1.1) was removed as it is now redundant given modern browser behaviour.
The 12 Highest Impact Fixes
Most B2B sites fail the same twelve checks. Fix these and you address the majority of your accessibility debt.
1. Colour contrast. Body text must have a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold) needs 3:1. Use the WebAIM Contrast Checker to verify. Light grey text on white backgrounds is the most common failure.
2. Focus states. Every interactive element (links, buttons, form fields) must have a visible focus indicator when navigated by keyboard. Never use outline: none without providing an alternative visible state.
3. Alt text on images. Every image that conveys meaning needs descriptive alt text. Decorative images (purely aesthetic backgrounds or icons) should have empty alt attributes (alt="").
4. Form labels. Every form field needs a properly associated <label> element. Placeholder text inside the field is not a substitute; it disappears when the user starts typing.
5. Heading hierarchy. Pages should have a logical heading structure: one H1, followed by H2s for major sections, H3s for sub-sections. Screen readers and keyboard users navigate by heading. A page with five H1s or headings used purely for visual size is unusable navigably.
6. Keyboard navigation. The entire site must be navigable using only a keyboard (Tab to move forward, Shift+Tab to move back, Enter to activate, Escape to close). Test this yourself: close your mouse and try to complete a contact form.
7. Descriptive link text. “Click here” and “Read more” are meaningless out of context. Screen readers surface links in a list; “Download the Q2 2026 UK salary guide” is useful; “Click here” is not.
8. Error messages. Form errors must be described in text, not just indicated by colour (red border alone). Error messages should identify the field and explain what to correct.
9. Page titles. Every page needs a unique, descriptive <title> tag. “Home” is insufficient. “Services | Fernside Studio | Web Design Nottingham” gives context.
10. Language attribute. The <html> element should declare the page language with lang="en" (or lang="en-GB"). Screen readers use this to select the correct pronunciation engine.
11. Video captions. Any video with speech needs captions. Auto-generated captions from YouTube or Vimeo are often inaccurate; review and correct them.
12. Skip links. A “skip to main content” link at the top of each page allows keyboard users to bypass navigation and reach the main content directly. Typically hidden visually but visible on focus.
Free Tools That Actually Help
axe DevTools (browser extension): catches a significant proportion of WCAG failures automatically. Integrate it into your browser and run it on each key page.
WAVE (wave.webaim.org): visualises accessibility errors directly on the page. Good for training teams on what issues look like in context.
Lighthouse (built into Chrome DevTools): includes an accessibility audit. Scores 0 to 100. Useful as a quick baseline; not comprehensive.
Keyboard-only testing: the most important manual test. No tools required. Unplug your mouse.
Why Automated Tools Only Find 30 Percent of Issues
This is the figure consistently reported across accessibility research: automated tools catch approximately 30 to 40 percent of WCAG failures. The rest require human judgement.
Automated tools cannot judge whether alt text is meaningful (only whether it exists), whether form error messages are helpful (only whether they are present), whether the reading order makes sense, or whether the visual layout matches the underlying content structure.
Human testing, including testing with actual screen reader users, catches the failures that matter most in practice. Accessibility is not a technical certification exercise; it is a usability discipline.
Building Accessibility into the Design Phase
Retrofitting accessibility into a completed build is expensive and often incomplete. Building it in from the start costs almost nothing extra and produces better results.
The checklist: design with sufficient colour contrast from day one. Build component libraries with focus states included. Write meaningful alt text during content creation, not as an afterthought. Test keyboard navigation at each component, not just at the end of the project.
At Fernside Studio, accessibility is built into every web design and web development project from the first design token. We don’t treat it as an audit task at the end; we treat it as a design quality baseline.
If you want a WCAG 2.2 audit of your existing site, get in touch and we’ll walk you through what you’re missing and what to fix first.