A procurement officer opens a vendor’s website, presses the Tab key to move through the navigation, and loses track of where the cursor is. A sticky header hides the focused link. The “Request a Quote” button is too small to tap on a phone. None of these problems shows up in a quick visual review, yet each one tells an enterprise or government buyer something about how the vendor builds things.
Accessibility readiness is increasingly part of vendor evaluation. A WCAG 2.2 website checklist does not have to start with a full audit. It can start with five checks anyone on the team can perform in an afternoon.
Why WCAG 2.2
The Web Content Accessibility Guidelines (WCAG), published by the W3C, are the international standard for web accessibility. WCAG 2.2 builds on earlier versions and adds criteria focused on keyboard focus, touch targets, and authentication. Building to WCAG 2.2 AA covers the earlier 2.0 and 2.1 AA criteria as well.
Check 1: Keyboard Access
What to do: Put the mouse away. Use Tab, Shift+Tab, Enter, Space, and arrow keys to move through the homepage, main navigation, a form, and any menus, sliders, or pop-ups.
What good looks like: Every interactive element can be reached and operated. Focus moves in a logical order. Nothing traps the keyboard, and pop-ups can be closed with Escape.
Common failures: Dropdown menus that only open on hover, custom buttons built from non-interactive elements, and modal windows that cannot be closed by keyboard.
Check 2: Visible and Unobscured Focus
What to do: As you tab through the page, watch the focus indicator.
What good looks like: You can always see which element has focus, and the focused element is not hidden behind sticky headers, cookie banners, or chat widgets. WCAG 2.2 added “Focus Not Obscured” specifically to address content that covers the focused element.
Common failures: Themes that remove the browser’s default focus outline without replacing it, and sticky headers that cover links as the page scrolls.
Check 3: Target Size
What to do: On a phone, try tapping every button, link, and icon in the header, footer, and forms.
What good looks like: Targets are large enough, or spaced far enough apart, to tap accurately. WCAG 2.2’s minimum target size criterion sets a baseline of 24 by 24 CSS pixels, with exceptions such as links within sentences.
Common failures: Tiny social icons placed edge to edge, close buttons on pop-ups, and pagination links crowded together.
Check 4: Labels and Contrast
What to do: Inspect your forms and text.
What good looks like: Every form field has a visible, programmatically associated label, not just placeholder text that disappears when typing. Error messages explain what went wrong and how to fix it. Text meets contrast requirements: 4.5:1 for normal text and 3:1 for large text and meaningful interface elements.
Common failures: Light gray text on white backgrounds, placeholder-only fields, and errors indicated only by color.
Check 5: Accessible Authentication
What to do: Review login forms, client portals, and any account areas.
What good looks like: Users are not required to solve cognitive tests, such as remembering or transcribing information, to log in unless an alternative exists. Password managers and copy-paste should work. WCAG 2.2 added accessible authentication criteria to address this.
Common failures: Fields that block pasting, puzzle-style CAPTCHAs without alternatives, and short time limits.
Turn Observations Into Action
Record each failure with the page, the element, the problem, and who will fix it. Prioritize issues on high-traffic and conversion pages first: the homepage, service pages, contact forms, and checkout.
These five checks are a starting point, not a full conformance evaluation. Automated tools and manual testing with screen readers are needed for a complete picture. SETN Consultants uses checks like these as the first step in every accessibility assessment, and SETN Consultants then documents findings in a format buyers and development teams can both use.
Make the Checks a Habit
Accessibility is not a one-time project. New pages, plugins, theme updates, and design refreshes can reintroduce issues that were already fixed. Add these five checks to the routine for every significant website change, and repeat them on key pages each quarter. Assign an owner, keep a running issue log, and record when each issue was resolved. That record becomes useful evidence when a buyer asks how your organization approaches accessibility, and it shows steady improvement over time rather than a single snapshot taken before a proposal deadline.
Frequently Asked Questions
What is new in WCAG 2.2?
New criteria include focus not obscured, focus appearance guidance, minimum target size, dragging alternatives, consistent help, redundant entry, and accessible authentication.
Can I test accessibility without special tools?
Yes, for the basics. Keyboard testing and mobile tap testing reveal many issues.
Is WCAG 2.2 legally required?
Requirements vary by sector and jurisdiction. Many organizations adopt WCAG 2.2 AA as their standard because it reflects current best practice.
Do accessibility overlays fix these issues?
No. Overlays cannot reliably fix underlying code and design problems.
Request an accessibility assessment and see how your website performs against WCAG 2.2: setnconsultants.com/services/website-design-development/
