WCAG 2.2 AA for Surveys: Accessible Survey Design Checklist

What Is WCAG?

The Web Content Accessibility Guidelines (WCAG) are the international standard for digital accessibility, published by the World Wide Web Consortium (W3C). WCAG 2.2, released in October 2023, is the current version. The AA conformance level, the middle of three levels (A, AA, AAA), is the standard most commonly adopted by legislation, procurement policies, and organizational accessibility requirements. For survey research, WCAG 2.2 AA defines how to design and deliver surveys that people with disabilities can complete independently.

Who Needs to Comply?

• Government agencies and departments: Canadian federal accessibility requirements (Accessible Canada Act) and provincial legislation reference WCAG 2.0/2.1 AA; WCAG 2.2 AA is the current best practice
• Organizations subject to the Accessible Canada Act: federally regulated sectors including banking, telecommunications, and transportation
• Ontario organizations subject to the Accessibility for Ontarians with Disabilities Act (AODA), which requires WCAG 2.0 AA for public-facing web content
• Research platforms and survey tools: accessibility of the survey instrument itself falls under WCAG when surveys are public-facing or used by government
• Any organization conducting research funded by or on behalf of a government entity, as accessibility is frequently a procurement condition
• EU organizations under the European Accessibility Act (effective 2025), which references harmonized accessibility standards

Gray areas: WCAG compliance for surveys exists on a spectrum. A private company running an internal employee engagement survey has fewer legal obligations than a federal agency surveying the public. However, inaccessible surveys exclude people with disabilities from research participation, introducing sampling bias regardless of legal requirements. The ethical and methodological case for accessible surveys exists independent of compliance mandates.

Key Requirements for Research Teams

Perceivable

Survey content must be presentable in ways that all participants can perceive. For survey design, this means providing text alternatives for images used in image-choice questions, ensuring sufficient color contrast between text and backgrounds (minimum 4.5:1 ratio for normal text, 3:1 for large text), not relying solely on color to convey information (e.g., red for required fields without an asterisk or text label), and ensuring that multimedia content (video stimuli, audio clips) includes captions or transcripts. Rating scales should have text labels, not just color gradations.

Operable

Participants must be able to navigate and interact with the survey using various input methods. Every survey element, questions, response options, navigation buttons, progress indicators, must be operable via keyboard alone (Tab, Enter, Space, arrow keys). Interactive elements like sliders, drag-and-drop ranking questions, and matrix grids are common accessibility barriers. Provide keyboard-accessible alternatives for any interaction that requires mouse precision. Touch targets on mobile must be at least 24x24 CSS pixels (a new requirement in WCAG 2.2). Set adequate time limits, or let participants extend them, for surveys with auto-advance or timeout features.

Understandable

Survey content and interface behavior must be predictable and comprehensible. Use clear, plain language in questions and instructions. Identify the language of the survey in the HTML (critical for screen readers). Provide instructions before complex question types (e.g., "Select up to 3 options" before a multi-select question). Error messages must identify the specific field with the error and suggest how to fix it, "Please select a response for question 7" rather than a generic "Form error." Navigation should be consistent throughout the survey, don't change button locations or interaction patterns between pages.

strong

Survey markup must be compatible with current and future assistive technologies. Use semantic HTML for survey forms, proper <label> elements associated with <input> fields, appropriate ARIA roles for custom components, and valid HTML structure. Screen readers rely on this markup to interpret survey structure. Custom question types (sliders, card sorts, heatmaps) require ARIA attributes that communicate the element's role, state, and value to assistive technology. Test with actual screen readers (NVDA, JAWS, VoiceOver), not just automated accessibility checkers.

New in WCAG 2.2 for Surveys

WCAG 2.2 introduced several criteria particularly relevant to survey design. Focus Not Obscured (2.4.11): When a survey element receives keyboard focus, it must not be entirely hidden by other content (e.g., a sticky header or progress bar). Dragging Movements (2.5.7): Any functionality that uses dragging (ranking questions, card sorts) must have a non-dragging alternative. Target Size Minimum (2.5.8): Interactive targets must be at least 24x24 CSS pixels. Consistent Help (3.2.6): If you provide help mechanisms (contact links, tooltips), they must appear in the same location across pages. Redundant Entry (3.3.7): Don't ask participants to re-enter information they've already provided earlier in the survey.

Compliance Checklist

• All images (including image-choice question options) have meaningful alt text
• Color contrast ratios meet 4.5:1 for normal text and 3:1 for large text
• Information is never conveyed by color alone, text labels, icons, or patterns supplement color coding
• Every survey element is reachable and operable via keyboard (Tab, Enter, Space, arrows)
• Custom interactive elements (sliders, drag-and-drop) have keyboard-accessible alternatives
• Touch targets on mobile are at least 24x24 CSS pixels
• Survey language is identified in the HTML lang attribute
• Instructions precede complex question types, explaining expected interaction
• Error messages identify the specific field and provide correction guidance
• Multimedia stimuli include captions, transcripts, or audio descriptions
• Screen reader testing has been conducted with at least one major reader (NVDA, JAWS, or VoiceOver)
• Form elements use semantic HTML with proper label associations and ARIA attributes where needed

How This Compares to Previous WCAG Versions

How Quali-Fi Helps You Comply

Quali-Fi's survey engine is built to meet WCAG 2.2 AA standards at the platform level, so research teams start from a compliant baseline rather than retrofitting accessibility into each survey. All standard question types, multiple choice, rating scales, open-ended, matrix, NPS, render with semantic HTML, proper label associations, and keyboard navigation support out of the box. Screen reader compatibility is tested across NVDA, JAWS, and VoiceOver as part of the platform's QA process, not left to individual survey creators.

For interactive question types that pose accessibility challenges, sliders, ranking questions, image choice. Quali-Fi provides keyboard-accessible alternatives that comply with WCAG 2.2's dragging movements criterion. The platform's theming engine enforces minimum contrast ratios, preventing survey creators from accidentally publishing inaccessible color combinations. Mobile rendering meets the 24x24 CSS pixel target size requirement, and responsive layouts adapt to orientation changes without losing content or functionality.

Quali-Fi's Enterprise plan includes full WCAG 2.2 AA compliance certification, making it suitable for government surveys, public-facing research instruments, and projects where accessibility is a procurement requirement. Combined with multi-language support (50+ languages with proper HTML lang attributes) and customizable consent flows that meet both accessibility and privacy standards, Quali-Fi provides a platform where compliance and research quality reinforce each other rather than competing for attention.

FAQs

Is WCAG compliance legally required for surveys?

It depends on your jurisdiction and context. In Canada, the Accessible Canada Act and provincial legislation like Ontario's AODA create legal obligations for specific organizations. Government-funded research and public-facing surveys typically require WCAG AA compliance. Private organizations face less explicit legal obligation but increasing procurement pressure and growing case law around digital accessibility. Beyond legal requirements, inaccessible surveys exclude participants and compromise data quality.

Can I make any question type accessible?

Most standard question types can be made accessible with proper implementation. Multiple choice, rating scales, open-ended text, and matrix questions all have well-established accessible patterns. More complex interactions, heatmap clicks, drag-and-drop card sorts, video annotation, are harder to make fully accessible. The WCAG 2.2 approach is to provide equivalent alternatives: a keyboard-operable ranking list instead of drag-and-drop, typed coordinate input instead of click-on-image.

Do automated accessibility tools catch all survey issues?

No. Automated tools (axe, WAVE, Lighthouse) catch approximately 30-40% of WCAG issues, primarily markup errors, missing alt text, and contrast violations. They cannot evaluate whether alt text is meaningful, whether keyboard navigation follows a logical order, or whether screen reader announcements make sense in context. Manual testing with assistive technology is essential, and testing with users who have disabilities is the gold standard.

How does accessibility affect survey completion rates?

Research shows that accessible surveys have higher completion rates across all populations, not just participants with disabilities. Clear layouts, logical navigation, readable text, and mobile-friendly design benefit every respondent. Organizations that have implemented WCAG-compliant surveys consistently report lower abandonment rates and higher data quality.

What about PDF surveys: does WCAG apply?

WCAG applies to all web content, including PDFs. However, making PDFs fully accessible is significantly harder than making web-based surveys accessible. If you are distributing surveys as downloadable PDFs, each document needs tagged structure, reading order, alt text, and form field labels. Web-based surveys are inherently easier to make accessible and should be preferred over PDF instruments whenever possible.

Related Compliance Topics

• Consent Management in Surveys. Accessible consent flow design
• Children and Survey Compliance. Accessibility considerations for minors
• Research Ethics Compliance, Ethical obligations for inclusive research
• PIPEDA Compliance for Research. Privacy alongside accessibility
• Canadian Government Research Compliance. Federal accessibility and procurement
• Indigenous Data Sovereignty. Inclusive research design principles