# accessibility
WCAG 2.2 + Core Web Vitals editorial.
Accessibility on the web is not optional. WCAG 2.2 AA is the minimum bar, and Core Web Vitals is where accessibility meets performance. Both are engineering problems, not marketing statements. Every guide here is written to be pasted into a code review or an audit checklist.
# mission
Why accessibility is a pillar, not a footnote.
A UK site that fails WCAG 2.2 AA is a legal risk under the Public Sector Bodies Accessibility Regulations 2018 (public sector) and the Equality Act 2010 (private sector). Beyond the legal position, an accessible site converts better, ranks better in Search, and is easier to maintain.
Core Web Vitals sit alongside WCAG because a site with an LCP over 4 seconds is inaccessible to someone on a mid-range Android with a patchy 4G connection, just as much as a site with keyboard-trapped modals is inaccessible to someone using a screen reader.
# guides
Checklists and guides.
WCAG 2.2 AA checklist: every success criterion in plain English, ranked by how often it fails on real audits, with a code snippet or a browser-devtools screenshot showing the fix.
Core Web Vitals guide: what LCP, INP, and CLS actually measure, how to profile them in real browsing conditions, and the four fixes that move the numbers on almost any site.
More guides land through waves 1b-1e, covering colour-contrast tokens for design systems, form-error announcement patterns, focus management in modals, and prefers-reduced-motion done properly.
# editorial standards
How accessibility guides are written.
No role="button" on a <div>. No aria-label on visible text. No autoplay video. Every guide reviewed against WCAG 2.2 AA by a developer who has been through a NDA-covered accessibility audit, and every code example runs through axe-core before publish.
If a technique has a browser-support caveat (subgrid on older Safari, has() on older Firefox), the caveat is stated with the actual version numbers, not “most browsers”.
# frequently asked
Accessibility FAQs
WCAG 2.2 or 2.1?
WCAG 2.2 AA is the current UK legal reference (Equality Act 2010 informed by the Public Sector Bodies Accessibility Regulations 2018 for public-sector work; industry best practice for private-sector). WCAG 2.1 AA is a subset; anything 2.2 covers is a superset. Target 2.2 AA.
Core Web Vitals, still matter?
Yes. INP replaced FID in March 2024 and remains a ranking signal in 2026. LCP under 2.5 seconds and CLS under 0.1 are still the thresholds. If your Core Web Vitals are red on real-world Chrome UX Report data, that is a ranking risk and a UX risk.
Is Lighthouse enough?
Lighthouse is a good first check but tests a synthetic scenario. Use Chrome UX Report or Google Search Console for real-world data. Lighthouse Accessibility rarely catches keyboard-only bugs or screen reader issues; run a real audit with NVDA or VoiceOver before you ship.
Best a11y testing tools?
axe DevTools (browser extension) for automated checks. NVDA (Windows) and VoiceOver (macOS) for manual screen reader audits. WAVE for a quick heat map. Storybook plus @storybook/addon-a11y for component-level testing. Playwright with @axe-core/playwright for CI.
How do you fix insufficient colour contrast?
Check the failing pair against the WCAG contrast checker (aim for 4.5:1 on body text, 3:1 on large text and non-text UI). Adjust the darker colour, not the lighter; a slightly darker text keeps the design language while passing. If you cannot change the palette, adjust the font weight (bold text has more optical contrast).
Screen readers on Windows, Mac, Linux?
NVDA is the industry default on Windows (free, open source). JAWS is the enterprise default (paid). VoiceOver ships with macOS and iOS. Orca is the Linux option. Test on at least NVDA plus Chrome plus Firefox for a public-sector-quality audit.