On July 1, 2026, Washington became one of the first states to impose a hard WCAG 2.2 Level AA deadline on its own executive branch agencies — and on the vendors who build and maintain sites for them. If you build, host, or maintain WordPress sites for clients who touch government contracts in any state, this deadline should be on your radar even if you’ve never set foot in Olympia. It’s a preview of where state-level accessibility enforcement is headed, and it’s arriving faster than most agencies — and most of their vendors — expected.
What Washington’s Policy 188 Actually Requires
Washington’s Office of the Chief Information Officer maintains Policy 188, the state’s accessibility standard for digital services. As of July 1, 2026, that policy sets the compliance floor at WCAG 2.2 Level AA for executive branch state agencies. That’s a step up from the WCAG 2.1 AA baseline most public-sector accessibility rules — including the DOJ’s ADA Title II web rule — have used up to now.
Two details matter more than the headline date:
- The requirement doesn’t stop at internal state IT teams. It explicitly extends to third-party vendors and contractors who build, host, or maintain sites on the state’s behalf.
- It’s narrower in scope than it sounds. Policy 188 covers Washington’s executive branch agencies. Cities, counties, school districts, and special districts in Washington fall under the separate federal ADA Title II WCAG 2.1 AA requirement instead, on that rule’s own phased timeline.
So if you maintain a WordPress site for a Washington state agency directly, WCAG 2.2 AA is not optional anymore — it’s contractual. If your client is a city or county government, you’re still working toward the federal Title II deadline, but at the 2.1 AA bar, not 2.2.
Why This Matters Even Outside Washington
Most WordPress agencies reading this don’t have Washington state government clients. Here’s why the deadline is still worth understanding:
Washington isn’t inventing a new standard — it’s just adopting the newer, stricter version of the existing one earlier than federal law requires. WCAG 2.2 added nine new success criteria on top of 2.1, covering things like consistent help mechanisms, dragging movements needing an alternative, and larger, more forgiving target sizes for buttons and links. Federal ADA Title II rules currently reference 2.1 AA, but that gap is narrowing, and states are free to move faster. Washington just did.
That’s the pattern worth watching: state and local governments increasingly set their own accessibility bars above the federal floor, and those bars tend to ratchet upward, not down. A state agency that requires 2.2 AA today is a signal that other states, and eventually federal guidance itself, will follow. If you build sites for any public-sector or publicly-funded client — even outside Washington — expect a version of this same requirement to show up in your next contract renewal or RFP.
The Vendor Clause Is the Part People Miss
It’s easy to read a policy like this and assume it’s the state agency’s problem to solve. It isn’t, structurally. When a compliance standard explicitly names contractors and vendors, liability doesn’t stay contained inside the agency’s IT department — it flows downstream into every procurement contract, every maintenance agreement, and every WordPress theme or plugin choice a vendor makes on the agency’s behalf.
In practice, that means:
- Agencies will start asking vendors for accessibility conformance documentation (often a VPAT) before signing or renewing contracts.
- Vendors who can’t demonstrate an ongoing testing process — not just a one-time audit — will be at a competitive disadvantage in public-sector bids.
- The theme, page builder, and plugin stack you choose for a government client’s WordPress site becomes a contractual liability if it generates markup that fails 2.2 AA criteria.
If you’re a freelancer or agency with even one government or quasi-governmental client — a public library, a transit authority, a school district vendor relationship — it’s worth confirming which standard actually applies to that contract and whether your current build meets it.
What Actually Changed Between 2.1 AA and 2.2 AA
For WordPress site owners trying to figure out what a jump from 2.1 to 2.2 actually costs in engineering time, the honest answer is: usually less than people fear, but it’s not nothing. The new criteria most likely to affect a typical WordPress site include:
- Target Size (Minimum) — interactive elements like buttons and links generally need at least a 24×24 CSS pixel target, which trips up a lot of densely packed navigation menus and icon buttons.
- Consistent Help — if a site offers a contact method, chat widget, or help link, it needs to appear in the same relative place across pages.
- Focus Not Obscured — sticky headers and cookie banners can’t permanently cover an element that currently has keyboard focus.
- Dragging Movements — any interaction that relies on dragging (image comparison sliders, drag-to-reorder lists) needs a single-pointer alternative.
None of these are exotic. They’re the kind of issues that show up reliably in a code-level scan of theme and plugin markup, which is exactly the category of problem that gets missed by tools that only check color contrast and alt text.
Take Action
Whether or not you have a Washington state client, Policy 188 is a useful early warning: WCAG 2.2 AA is becoming the standard governments hold vendors to, and that bar moves in one direction. LEWCA scans your WordPress site’s actual code for the issues that matter under 2.2 AA — undersized touch targets, focus-obscuring sticky elements, missing alternatives for drag interactions — and tells you exactly what to fix and where, rather than papering over problems with a bolt-on widget. It won’t get you to “100% compliant,” because no automated tool can promise that, but it will give you a real, defensible starting point for a contract that now requires one. Compare plans on the pricing page or download LEWCA to run your first scan today.