What is the latest version of WCAG?

October 2023 brought us WCAG 2.2, which refines nine success criteria without turning everything upside down. Already nailing WCAG 2.1? You’re basically there. This latest version tackles the everyday barriers that trip up people with cognitive and physical disabilities when they’re just trying to use your website, and public sector organisations in particular need to understand what’s changed.

Forget theoretical compliance boxes. WCAG 2.2 goes after the stuff that actually annoys users: help text that vanishes when you need it most, touch targets so tiny you need a magnifying glass, navigation that changes its mind halfway through a task. These seemingly minor issues become massive roadblocks for anyone using assistive tech or interacting differently with digital content, which is why organisations serious about website accessibility need to get their heads around what’s changed.

Understanding WCAG fundamentals

Web Content Accessibility Guidelines. That’s what WCAG stands for and the World Wide Web Consortium (W3C) publishes them to set the standard for making digital content work for everyone. The whole framework hangs on four principles spelled out in the acronym POUR: Perceivable, Operable, Understandable and Robust.

Breaking that down: Perceivable content reaches users through whatever senses they can use. Operable means your interactive bits work no matter how someone’s trying to control them. Understandable keeps things logical with plain language. Robust code plays nice with screen readers, voice control and whatever browser someone’s using.

Think about someone trying to navigate your site with just their keyboard. Are the colour contrasts strong enough for users with low vision? Can screen readers make sense of your heading structure? When people click something, do they get proper feedback? WCAG’s success criteria tackle real barriers that stop people from using websites properly.

Forget ticking boxes for compliance sake. Accessibility means people can actually get things done on your website without hitting walls they can’t climb over.

Evolution from WCAG 2.0 to 2.2

Back in 2008, WCAG 2.0 made sense for its time. Mobile was barely a thing, everyone designed for desktops first and accessibility got bolted on later (if at all). Those guidelines couldn’t predict smartphones taking over or how people would interact with websites in completely different ways.

Seventeen new success criteria landed with WCAG 2.1 in 2018. Mobile accessibility got proper attention, cognitive disabilities weren’t an afterthought and low vision support improved massively. Content couldn’t be trapped in portrait or landscape mode anymore. Different ways of interacting with sites needed to work consistently. Even UI components faced tougher contrast rules.

WCAG 2.2 takes a different approach than its predecessors. Instead of throwing in massive new categories, it zeroes in on those annoying friction points that kept tripping people up. The nine new criteria? They’re like precision tools rather than sledgehammers.

Key changes in WCAG 2.2

Target Size (Minimum) sorts out one of mobile web’s biggest annoyances. Interactive elements need to be at least 24 by 24 CSS pixels now (with exceptions for inline links and properly spaced elements). We’ve all been there, stabbing at microscopic buttons with our thumbs.

What about people who can’t do precise drag-and-drop movements? Dragging Movements covers this by requiring alternative methods for any drag-based functionality. Cut and paste, directional buttons, whatever works. Users with tremor conditions or mobility limitations get a much better experience and so do people using alternative input devices.

Consistent Help stops the maddening hunt for assistance when you need it most. Help mechanisms must appear in the same spot across all pages, whether that’s contact details, live chat or documentation. People with cognitive disabilities particularly benefit from this predictability, but honestly, we all do.

Complete hiding breaks keyboard navigation entirely. Focus Not Obscured makes sure that when someone tabs to an element, other page content doesn’t completely block the focus indicator from view. Partially covered indicators? That’s fine, but users need to see where they are on the page.

Authentication requirements now limit cognitive burdens during login processes (no more impossible CAPTCHAs), while Accessible Authentication criteria offer alternatives to object recognition or remembering personal details. These updates show how much better we understand cognitive accessibility in digital spaces.

Compliance requirements across sectors

UK public sector organisations must hit WCAG 2.1 AA standards under the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations, though WCAG 2.2 isn’t legally required yet. But it’s the current international best practice and will probably become the benchmark for future regulations.

Different rules apply to private sector compliance. The Equality Act 2010 demands reasonable adjustments for disabled customers without specifying WCAG versions, but courts increasingly look to WCAG standards when deciding what counts as reasonable accessibility. Keeping up with web development best practices gives you stronger legal ground to stand on.

Those 14.1 million disabled people in the UK? They’ve got serious spending power and accessibility compliance opens the door to that market rather than just ticking a legal box.

Accessible design works better for everyone anyway. Bright sunlight makes good colour contrast your best friend, keyboard shortcuts save you when trackpads die and clear navigation stops people getting lost in your site. When our WordPress development team builds accessibility in from day one, the whole user experience improves.

Implementation complexity and approaches

Moving from WCAG 2.1 to 2.2 means targeted tweaks, not starting over. Check your button sizes, review where help content sits, tidy up focus management. Sites with decent accessibility bones can slot these updates into normal development cycles without much fuss.

Starting with a mess is different entirely. Poor semantic markup, poor colour contrast, missing alt text. You’re looking at proper structural work that’ll eat into timelines and budgets, much like renovating a house with questionable foundations versus one that’s basically sound.

Want to know what’s actually breaking your site for users? Professional accessibility audits cut straight to the biggest problems. They’ll fire up screen readers, test keyboard navigation and try voice control to catch all the stuff automated scanners completely miss. Government guidance gives you solid frameworks for working out which fixes to tackle first based on how much they’ll help users and how complex they are technically.

Most teams kick off with automated scanning because it catches the obvious stuff fast. Missing alt text, poor contrast ratios, that sort of thing. Then you move into manual testing where things get interesting, checking keyboard navigation works properly, screen readers can make sense of your content and users won’t get overwhelmed trying to complete tasks. The real gold comes from testing with actual disabled users, though you’ll need to budget properly and recruit thoughtfully.

Tools and testing methodologies

Mixing automated tools with hands-on testing gives you the full picture. WAVE and axe will blitz through your site spotting WCAG violations in seconds, picking up missing alt text, questionable contrast and markup problems without breaking a sweat. But they can’t tell you if your mega dropdown menu is impossible to navigate or if your form error messages make any sense.

Nothing beats firing up a proper screen reader to see what users actually experience. NVDA gives you full screen reader functionality on Windows without costing a penny, while VoiceOver comes ready to go on every Mac and iPhone. You’ll discover how people actually move through your content, spot where they get confused and find interaction problems that no automated tool will ever catch.

Tab through every clickable element and you’ll quickly spot the weak points. Focus indicators that vanish into thin backgrounds, tab order that jumps around like a broken GPS, or worse still, functionality that just stops working the moment you put the mouse down. Custom components usually cause the biggest headaches here.

Managing multiple sites? WordPress maintenance services can bake accessibility checks right into your regular update schedule, which means you won’t suddenly discover compliance issues three months after a content overhaul.

Looking ahead to WCAG 3.0

Don’t hold your breath waiting for WCAG 3.0. Development’s still chugging along, but we’re talking years before it lands properly. The big shift would ditch those harsh pass/fail grades for bronze, silver and gold levels instead, giving you actual room to work with real-world accessibility challenges rather than ticking boxes.

Everything’s getting reshuffled in the current WCAG 3.0 drafts. Out go the principle-based rules, in come practical categories like text alternatives and interaction design. Testing could blend automated scoring with human evaluation, though frankly the whole structure’s still pretty fluid at this stage.

Building your accessibility strategy on WCAG 2.2 means you’re working with something that actually has teeth. Assistive technology vendors support it, legal frameworks recognise it and the accessibility community has rallied behind it. Whatever WCAG 3.0 eventually looks like, the work you do now won’t become obsolete overnight.

But here’s the thing about accessibility work. It doesn’t pause for perfect standards and the business benefits start flowing immediately. SEO performance gets a boost from properly structured markup. Customers complete more transactions when your site works across different devices and input methods. Understanding WCAG 2.2 walks you through exactly how to make these improvements happen, regardless of what platform you’re running.

Why wait for something that doesn’t exist yet? WCAG 2.2 gives you stable standards you can actually implement, while WCAG 3.0 sits somewhere in development limbo with zero confirmed release date.