WCAG 2.2 accessibility for B2B tech websites: a practical guide

Accessibility used to be treated as a compliance afterthought by most B2B tech firms we worked with. That has changed. Procurement teams at enterprise buyers now ask about WCAG conformance during vendor due diligence, public sector tenders require it as a baseline and the European Accessibility Act has put real legal weight behind it. If you sell software or IT services into regulated sectors, your website is increasingly being scored on this.

WCAG 2.2 is the current target. It builds on WCAG 2.1 with nine new success criteria, most of which are sensible improvements to focus visibility, drag-and-drop alternatives and authentication usability. We have audited and rebuilt sites for SaaS vendors, MSPs and SAP consultancies against this standard, and the same issues keep coming up.

What WCAG 2.2 conformance actually means

WCAG defines three conformance levels: A, AA and AAA. AA is the practical target for B2B websites and the level referenced by most legislation, including the UK’s Public Sector Bodies Accessibility Regulations. AAA is rarely required and often impossible to achieve across an entire site without compromising the design.

Conformance is per-page and per-state. A landing page that passes AA but a contact form that fails it means the site as a whole does not conform. This is the part procurement questionnaires usually catch out, because marketing teams test the homepage and miss the gated content download, the support portal login and the cookie banner.

The issues we find on almost every B2B tech site

Here are the failures we see most often when we audit sites in this sector.

Colour contrast on brand greys and blues

Tech brand palettes love a soft mid-grey on white or a desaturated blue on a slightly darker blue. They look modern. They also fail the 4.5:1 contrast ratio for body text and the 3:1 ratio for large text and UI components. This is the single most common failure on sites we audit. The fix is small (darken the foreground colour, lighten the background or both) but it requires sign-off from whoever owns the brand guidelines.

Focus indicators removed by CSS resets

Many design systems and CSS resets strip the default browser focus ring with outline: none and never replace it. Keyboard users (which includes screen reader users and anyone with motor impairments) cannot tell where they are on the page. WCAG 2.2 introduced a specific success criterion (2.4.11 Focus Not Obscured) that tightens this further. Every interactive element needs a visible, high-contrast focus state.

Forms without labels or error messages

The decorative trend of placeholder-only forms (where the field label disappears as soon as you start typing) is an accessibility failure under multiple criteria. Screen readers cannot reliably read placeholder text as a label, and users with cognitive impairments lose their place. Inline error messages also need to be programmatically associated with the field they refer to, not just visually adjacent.

PDF downloads that are not tagged

B2B tech sites lean heavily on gated PDFs (whitepapers, datasheets, case studies). Most are exported from InDesign or Word without proper tagging, which means screen readers cannot navigate them. PDFs are within scope of WCAG and within scope of accessibility legislation. Either tag them properly or convert the content to an HTML page, which we usually recommend anyway because tagged PDFs are also better for SEO.

Video without captions or transcripts

Demo videos, webinar recordings and product walkthroughs need captions (for live and pre-recorded video) and ideally a transcript. Auto-generated YouTube captions do not meet WCAG because they are unreliable. We typically commission proper captions or use a transcription service and embed the transcript on the page (which has the side benefit of giving search engines and AI crawlers something to index).

What WCAG 2.2 added that you need to know

The new success criteria most likely to affect B2B tech sites:

• 2.4.11 Focus Not Obscured (Minimum): when an element receives focus, it must not be entirely hidden by sticky headers, cookie banners or chat widgets
• 2.5.7 Dragging Movements: any drag-and-drop interaction must have a single-pointer alternative (clicking buttons, for instance)
• 2.5.8 Target Size (Minimum): interactive targets must be at least 24x24 CSS pixels, with some exceptions
• 3.3.7 Redundant Entry: do not ask users to re-enter the same information later in a multi-step form
• 3.3.8 Accessible Authentication (Minimum): do not require cognitive function tests like remembering passwords or solving puzzles for authentication, unless an alternative is provided

Cookie consent banners and live chat widgets are the two components we most often find breaking the new focus and target-size criteria. Most third-party widgets are not WCAG 2.2 compliant out of the box, which is something to flag with vendors before you buy.

How we audit accessibility

When we audit a B2B tech site, we run a layered approach rather than relying on a single tool.

1. Automated scan with axe-core or WAVE to catch the obvious issues (missing alt text, contrast failures, label problems). This finds maybe 30 to 40 per cent of real issues.
2. Keyboard-only walkthrough of every key journey: homepage, service page, contact form, gated download, blog. If we cannot complete the journey using only Tab, Enter and arrow keys, neither can a keyboard user.
3. Screen reader pass with VoiceOver on Mac and NVDA on Windows. We listen to whether the page makes sense when read aloud, whether headings are in order and whether dynamic content (modals, alerts, form errors) is announced.
4. Manual checks for the criteria automated tools cannot test: meaningful link text, content order, focus management on single-page interactions, drag alternatives.

The output is a prioritised list of issues with severity, location and a fix recommendation. We feed that into the build sprint or remediation backlog.

The commercial case (it is not just compliance)

We mention this because some clients still see accessibility as a cost centre. It is not. Accessible sites are better for SEO because the same structural rigour (proper headings, descriptive link text, alt attributes, semantic HTML) is what search engines and LLMs use to understand pages. We cover the AI search angle in structured data for AI search and the credibility angle in E-E-A-T for tech companies. Accessible sites also tend to have lower bounce rates and better mobile conversion because the same fixes (clear focus, larger targets, simpler forms) help everyone.

There is also the procurement angle. We have seen B2B tech vendors lose enterprise deals at the security and compliance review stage because their public website failed WCAG and the buyer’s accessibility policy required vendor sites to conform. Fixing this before you go to tender is a lot cheaper than fixing it under a deadline. For more on the broader build approach, see our page speed checklist and our hand-coded websites argument, both of which interact with accessibility decisions.

Where to start if your site has not been audited

If you have never had a formal audit, start with an automated scan to size the problem, then commission a manual audit against WCAG 2.2 AA from someone who does this work regularly. Build a remediation roadmap with quick wins first (contrast, alt text, focus rings) and structural changes second (form patterns, navigation, dynamic interactions). Bake accessibility checks into your QA process so you do not regress.

If you are scoping an accessibility audit or rebuilding a B2B tech site with conformance in mind, tell us about your situation and we will share what we have seen on similar projects. Our web design team treats WCAG 2.2 AA as a baseline rather than a final-week scramble.