×
India
GlobalThailandUAEUSAIndia
Back
Back
Sr. Director - Media
Software |
Buyers now ask for WCAG 2.2 Level AA before approving...
By Aditya Mohite
Jul 08, 2026 | 5 Minutes | 
| 
Buyers now ask for WCAG 2.2 Level AA before approving software vendors for purchase. Accessibility has become a sales gate, not just a legal box to check off. Your QA team needs a working WCAG 2.2 compliance checklist to audit your platform and document your status correctly.
WCAG 2.2 adds nine new rules focused on focus visibility, touch button sizing, and workflow consistency. A WCAG 2.2 compliance checklist helps your QA team test each rule systematically and thoroughly. Automated tools find only 30-40% of issues. You need both automated scans and manual expert review for complete coverage.
WCAG 2.2 works alongside WCAG 2.1 standards. If your platform passes 2.2 AA, it also passes 2.1 AA automatically. The nine new rules fix gaps the old standard left open for improvement.
The first group focuses on keyboard focus visibility and indicator placement. Focus Not Obscured (Minimum) stops sticky headers from hiding where your keyboard focus indicator is. Focus Not Obscured (Enhanced) works in crowded layouts with many overlays. Focus Visible (Enhanced) needs better contrast on the focus dot itself.
The second group fixes interactions and workflows people use daily. Target Size (Minimum) needs buttons at least 24×24 pixels for touch. Target Size (Enhanced) needs 44×44 pixels for better accessibility and usability. Dragging Movements need keyboard options for drag-and-drop interactions. Redundant Entry stops repeating data entry twice in workflows. Consistent Help keeps support links in one place across pages.
Why does this matter to your business? According to W3C (2023) shows, focus visibility failures stop keyboard users completely from using your platform. Small touch targets cause tap errors that disrupt key business tasks. Inconsistent help placement wastes time for users with memory issues. Per IS 17802 (2024) show, your business increasingly faces requirements to meet WCAG 2.2 AA standards.
Dense dashboards and multi-step forms struggle most with accessibility issues. Sticky headers hide the keyboard focus indicator, stopping keyboard-only users from seeing where they are in workflows. Drag-and-drop tools lack keyboard options, making them unusable for screen reader users altogether.
Charts lack text versions and alternatives, making data hidden from screen reader users trying to understand trends. Support widgets move across pages, forcing users to hunt for help repeatedly each time. Forms ask for the same country twice with no auto-fill feature. Form labels are missing or invisible, so screen readers cannot announce what they are.
These issues only show in manual testing and expert review. Automated tools miss most of these real-world problems entirely.
Start by using only your keyboard to move through your platform carefully. Press Tab to jump through every button, link, and form field systematically. When you tab to a form field, is the focus dot visible to you clearly? When you scroll down a page, does a sticky header hide the focus indicator completely? That's a problem you need to fix right away.
Next, check touch target sizes in DevTools carefully. Every button and link must be at least 24×24 pixels in size. Test all drag-and-drop tasks on your platform thoroughly. Is there a keyboard option to do the same job or task? In multi-step forms, if you pick a country in step 1 and again in step 3, fill it in automatically the second time to save users time.
Check form labels on every page in your platform. Can a screen reader tell you what each field is for and needs? Look at your charts and data visuals. Is there a table with the same data underneath? Visit every main page and verify: is the help link in the same spot every time?
Run an automated tool like Axe or WAVE across your platform. These tools catch main issues fast and efficiently for you. But they miss 60% of problems and edge cases. Manual testing finds the rest of the hidden issues. Have someone who knows screen readers test your platform top to bottom.
Put all fixes in order by how much they help your users:
Fix first (stops users completely):
Fix second (hard but possible):
Fix later (nice to have):
The goal is simple and clear: remove complete blocks before quality of life fixes. Keyboard users cannot use your site without focus visibility indicators. Mobile users quit apps with bad tap targets constantly. That's why these rank first in your WCAG 2.2 compliance checklist.
Buyers ask for a VPAT or Voluntary Product Accessibility Template form. A VPAT is not your test report or audit findings. It's a formal statement of your platform's status for each WCAG rule and criterion.
Your VPAT states three things clearly: the level you claim (A, AA, or AAA), the test date, and the result for each rule. Results are Supports, Supports with Exceptions, Does Not Support, or Not Applicable to you.
Example:
2.4.11 Focus Not Obscured (Minimum)
Status: Supports
Notes: Sticky header uses scroll-padding-top.
Tested on Chrome, Firefox, Safari with keyboard only.
Build your VPAT before buyers ask for it from you. Have your QA team test all 81 rules thoroughly. If you find problems or issues, say so directly. Honest talk about known issues and fix timelines is far better than over-claiming you're complete.
Level A is basic access like keyboard use and simple color contrast requirements. Level AA adds medium contrast levels, better focus markers, and interaction alternatives. Buyers require this level consistently. Level AAA is stricter and rarely asked for by procurement teams.
No, you cannot claim full compliance. Say "Supports with Exceptions. Known issues in [area] fixed by [date]." Honesty helps you build trust.
Professional tests take 2-4 weeks and cost USD 5,000-15,000 typically. Internal tests take 80-120 QA hours of work. Start with automated tools, then manual review.
No, not required. Regulators want AA only, not AAA. AAA is bonus work. Focus on AA for USA, Europe, and India rules.
Replace it right away. Tools without ARIA or keyboard help are risky in business software. Use Recharts, Victory, or Plotly. Or add text tables next to charts.
At least twice yearly or after big changes. New code breaks accessibility often. Assign one QA person to own this and do quarterly tests.
No, WCAG 2.2 is for web only. Apps use Apple's iOS Access Rules or Google's Android Material Design rules. The ideas overlap; good web design helps apps too.
Yes, definitely test again. The nine new WCAG 2.2 rules are not in 2.1 at all. You've tested 72 of 81 rules already. Test and fix the nine new ones. Expect 10-20% of your prior work to repeat itself.