WCAG 2.2 Level AA: A Practical Guide to Web Accessibility in 2026

Web accessibility helps ensure that websites, applications, LMS platforms, and digital learning content can be used by people with different abilities and assistive technologies. The Web Content Accessibility Guidelines (WCAG) provide a structured framework that organizations can use to identify accessibility barriers and improve digital experiences.

WCAG 2.2 became a W3C Recommendation on October 5, 2023. It introduced nine new success criteria compared with WCAG 2.1, including requirements related to keyboard focus, dragging movements, target size, consistent help, redundant entry, and accessible authentication.

For organizations managing websites, learning management systems (LMS), online courses, training portals, or other digital learning experiences, understanding WCAG 2.2 Level AA can help teams create more accessible and usable learning environments.

“WCAG 2.2 provides 9 additional success criteria since WCAG 2.1.”

This guide explains what WCAG 2.2 Level AA means, its key requirements, accessibility testing methods, common issues, and how organizations can review accessibility across the complete learner journey.

What Is WCAG 2.2?

WCAG stands for Web Content Accessibility Guidelines. It is an international accessibility standard developed by the World Wide Web Consortium (W3C) to help make web content more accessible to people with disabilities.

WCAG is organized around four core principles:

• Perceivable: Users should be able to perceive information and interface elements.
• Operable: Users should be able to operate navigation and controls.
• Understandable: Information and interactions should be understandable.
• Robust: Content should work reliably with different browsers, user agents, and assistive technologies.

WCAG requirements are called success criteria and are grouped into three conformance levels:

• Level A: Minimum accessibility requirements
• Level AA: All applicable Level A and Level AA requirements
• Level AAA: All applicable Level A, AA, and AAA requirements

WCAG 2.2 added nine new success criteria to WCAG 2.1. The existing WCAG 2.0 and 2.1 criteria remain essentially the same, while 4.1.1 Parsing became obsolete and was removed in WCAG 2.2.

For the official specification, organizations should refer to W3C WCAG 2.2.

What Does WCAG 2.2 Level AA Mean?

WCAG 2.2 Level AA means that applicable Level A and Level AA success criteria must be satisfied.

Level AA is therefore not a separate checklist that ignores Level A. An organization targeting Level AA must meet the requirements at both levels.

Level	What It Includes
Level A	Minimum conformance requirements
Level AA	All applicable Level A + Level AA requirements
Level AAA	All applicable Level A + AA + AAA requirements

WCAG 2.2 contains nine new success criteria, but they are spread across different conformance levels. The new Level AA criteria include Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum), and Accessible Authentication (Minimum).

Why Is WCAG 2.2 Level AA Important for eLearning?

Accessibility is particularly important for digital learning because learners interact with many different types of content and functionality.

An online learning experience may include:

• Course navigation
• Videos and audio
• Quizzes and assessments
• Interactive activities
• Forms
• Downloadable resources
• LMS dashboards
• Discussion areas
• Progress tracking
• Login and authentication
• Interactive presentations

Learners may use keyboards, screen readers, magnification software, voice input, switch devices, or other assistive technologies.

An accessibility barrier in any part of the learner journey can make it difficult to access information, complete an activity, or finish a course.

Organizations evaluating their learning environment can also review resources about best learning management systems and consider accessibility as part of their overall LMS selection and evaluation process.

Accessibility should also be considered when reviewing the technology supporting digital training. Teams can learn more about LMS technology when evaluating the technical environment used to deliver online learning.

Key WCAG 2.2 Level AA Requirements

WCAG 2.2 includes several requirements that are particularly relevant when reviewing modern websites and eLearning platforms.

1. Keyboard Accessibility

Applicable functionality should be operable through a keyboard.

Testing should include:

• Navigation menus
• Buttons and links
• Forms
• Interactive activities
• Quizzes
• Dialog boxes
• Course controls
• LMS navigation

A website may appear to work correctly with a mouse while still creating barriers for keyboard users. Keyboard testing should therefore be part of an accessibility evaluation.

2. Focus Not Obscured

Focus Not Obscured (Minimum) is a new Level AA success criterion in WCAG 2.2.

When an interactive component receives keyboard focus, it must not be completely hidden by author-created content.

This can be particularly relevant to:

• Sticky headers
• Fixed navigation
• Floating widgets
• Cookie banners
• Fixed footers
• Overlay components

For example, if a learner navigates through an LMS using the Tab key, the focused button or link should not disappear underneath a sticky footer.

3. Target Size (Minimum)

WCAG 2.2 introduced Target Size (Minimum) at Level AA.

In general, pointer targets should be at least 24 by 24 CSS pixels, subject to the exceptions defined in the success criterion.

This can apply to:

• Buttons
• Navigation controls
• Icons
• Form controls
• Interactive elements
• Mobile interface controls

The requirement is intended to make pointer interaction easier and reduce accidental activation of nearby controls.

4. Dragging Movements

Dragging Movements is another new Level AA requirement in WCAG 2.2.

When functionality requires dragging, there should generally be a way to complete the same task using a single pointer without dragging, unless an exception applies.

This can affect:

• Drag-and-drop exercises
• Interactive learning activities
• Sliders
• Sorting activities
• Interactive diagrams

For example, an eLearning course that asks learners to drag items into categories should provide an accessible alternative when required.

5. Accessible Authentication

Accessible Authentication (Minimum) is a new WCAG 2.2 Level AA requirement.

It addresses authentication processes that require users to perform cognitive function tests, subject to the exceptions and alternatives specified by WCAG.

This can be relevant to:

• LMS login pages
• Course portals
• Account access
• Password workflows
• Verification processes

W3C explains that mechanisms such as password-manager support and allowing copy and paste can reduce unnecessary cognitive effort during authentication.

6. Redundant Entry

Redundant Entry is a new Level A success criterion in WCAG 2.2.

When users have already provided information during the same process, they generally should not have to enter the same information again, subject to the criterion’s exceptions.

For example, if a learner provides their name during one stage of registration, the system may be able to automatically populate that information later rather than asking the learner to type it again.

7. Consistent Help

Consistent Help is another new Level A criterion.

When help mechanisms appear across multiple pages, they should generally appear in a consistent relative order unless the user changes the arrangement.

Examples include:

• Contact links
• Help pages
• Chat support
• FAQ links
• Automated assistance

Consistent placement makes it easier for learners to find support when they need it.

Other Accessibility Areas to Review

WCAG 2.2 Level AA is broader than the new requirements introduced in version 2.2.

A complete accessibility review should also consider:

Images

Meaningful images should have appropriate text alternatives where required. Decorative images should be handled appropriately so they do not create unnecessary noise for assistive technology users.

Forms

Forms should provide appropriate labels, instructions, and error information. Learners should be able to understand what information is required and how to correct mistakes.

Color and Contrast

Important information should not depend only on color. Text and interface components should also meet applicable contrast requirements.

Navigation

Learners should be able to understand where they are within a website or course and move through content using appropriate navigation mechanisms.

Multimedia

Videos and audio should be reviewed for applicable accessibility features such as captions, transcripts, and accessible controls.

Interactive Content

Interactive activities should be evaluated to determine whether learners can complete them using appropriate input methods.

WCAG 2.2 Level AA Checklist

Use this checklist as an initial accessibility review:

Accessibility Area	Question to Check
Keyboard	Can applicable functionality be used without a mouse?
Focus	Is keyboard focus visible and not completely hidden?
Target Size	Are pointer targets appropriately sized or covered by an exception?
Dragging	Is there an accessible alternative to dragging where required?
Authentication	Does the login process avoid unnecessary cognitive barriers?
Forms	Are labels, instructions, and errors clear?
Images	Do meaningful images have appropriate text alternatives?
Contrast	Is important visual information sufficiently distinguishable?
Navigation	Can users understand where they are and move through the interface?
Multimedia	Are appropriate accessibility features provided for video and audio?
Interactive Content	Can activities be completed using accessible interaction methods?

This checklist can support an initial review, but it does not by itself establish WCAG 2.2 Level AA conformance.

Automated Testing vs. Manual Accessibility Testing

Automated accessibility tools can identify many potential issues, but automated testing should not be treated as the entire accessibility evaluation.

Some accessibility requirements require human judgment and interaction testing.

A practical workflow can include:

1. Automated accessibility testing
2. Manual accessibility review
3. Keyboard testing
4. Screen reader and assistive technology testing where appropriate
5. Content review
6. Interactive testing
7. Issue remediation
8. Retesting

W3C’s conformance guidance explains that accessibility evaluation can involve both automated tools and human evaluation.

For organizations implementing or updating an LMS, accessibility can also be considered during the broader LMS implementation process rather than being left until the final QA stage.

Common WCAG 2.2 Accessibility Mistakes

Some common accessibility problems include:

• Making keyboard focus difficult to see
• Testing only with a mouse
• Using very small interactive controls
• Allowing sticky elements to cover focused content
• Providing drag-and-drop activities without an appropriate alternative
• Asking users to repeatedly enter the same information
• Creating unnecessary cognitive barriers during authentication
• Relying entirely on automated accessibility scanners
• Testing individual pages without reviewing the complete learner journey
• Treating accessibility as a final-stage task

Finding accessibility issues earlier in the development process can make remediation easier and reduce the risk of accessibility barriers appearing across multiple course pages.

How to Evaluate a Website for WCAG 2.2 Level AA

A structured evaluation can make accessibility testing easier to manage.

Step 1: Define the Scope

Identify what needs to be evaluated.

For an eLearning organization, this could include:

• Main website
• LMS
• Course pages
• Registration
• Login
• Assessments
• Multimedia
• Interactive activities
• Learner dashboards
• Downloadable resources

Step 2: Identify Applicable WCAG Requirements

Determine which Level A and Level AA success criteria apply to the content and functionality being reviewed.

Not every requirement will apply to every page or feature, so the evaluation should consider the actual content and functionality.

Step 3: Run Automated Tests

Use automated accessibility tools to identify potential issues involving areas such as structure, labels, contrast, and other machine-detectable problems.

Automated results should then be reviewed rather than treated as a final conformance decision.

Step 4: Perform Manual Testing

Review:

• Keyboard navigation
• Focus behavior
• Forms
• Interactive components
• Instructions
• Error messages
• Navigation
• Authentication workflows

Manual testing can identify problems that automated tools may not detect.

Step 5: Review Learning Content

Accessibility also depends on the content itself.

Review:

• Headings
• Links
• Images
• Instructions
• Tables
• Videos
• Captions
• Transcripts
• Error messages
• Downloadable documents

Content teams can also review instructional design practices. For example, TheEduAssist’s guide on Instructional Designer vs Developer explains how instructional design and course development responsibilities differ.

Step 6: Fix and Retest

After accessibility issues are corrected, test the affected content again.

Retesting helps confirm that:

• The original issue has been fixed
• The fix works across relevant interactions
• No new accessibility problems were introduced

WCAG 2.2 and the eLearning Learner Journey

A useful way to evaluate accessibility is to follow the learner’s complete journey:

Login → Course Selection → Course Navigation → Learning Content → Interactive Activities → Assessment → Completion

At each stage, ask:

• Can the learner access the content?
• Can they navigate using their preferred method?
• Can they understand the instructions?
• Can they complete the interaction?
• Can they identify errors?
• Can they move to the next step?
• Can they complete the assessment?

This approach can reveal accessibility problems that may be missed when individual pages are tested separately.

For example, structured LMS onboarding should also consider how learners access instructions, navigate modules, complete activities, and understand the learning path. TheEduAssist’s guide to structured TalentLMS onboarding provides an example of how onboarding can be organized into a structured learning journey.

Similarly, when designing shorter digital learning experiences, accessibility should be considered alongside course structure and interaction. TheEduAssist’s guide on designing microlearning courses with LearnWorlds discusses learning architecture, interactive features, and the mobile learning experience.

How TheEduAssist Can Help With Quality Assurance and Accessibility

Accessibility testing can be included within a broader quality assurance process for digital learning.

TheEduAssist provides Quality Assurance and Accessibility services focused on ensuring learning content is accurate, functional, and accessible. Its services also include eLearning development, LMS implementation and migration, content modernization, and ongoing learning support.

For an organization developing or maintaining an online course, LMS, or digital learning program, combining accessibility review with functional and quality assurance testing can provide a more complete evaluation of the learner experience.

You can explore TheEduAssist’s Quality Assurance and Accessibility services for more information about its learning technology and QA services.

WCAG 2.2 vs. WCAG 2.1

WCAG 2.2 builds on WCAG 2.1 rather than completely replacing its existing success criteria.

WCAG 2.2 introduced nine additional success criteria, while the existing WCAG 2.0 and 2.1 criteria remain essentially the same, with 4.1.1 Parsing becoming obsolete and being removed.

The nine new success criteria are:

1. Focus Not Obscured (Minimum) — Level AA
2. Focus Not Obscured (Enhanced) — Level AAA
3. Focus Appearance — Level AAA
4. Dragging Movements — Level AA
5. Target Size (Minimum) — Level AA
6. Consistent Help — Level A
7. Redundant Entry — Level A
8. Accessible Authentication (Minimum) — Level AA
9. Accessible Authentication (Enhanced) — Level AAA

Organizations updating an existing accessibility program should therefore review the additional WCAG 2.2 requirements instead of assuming that an older WCAG 2.1 review automatically covers every WCAG 2.2 criterion.

Frequently Asked Questions

Is WCAG 2.2 Level AA the same as WCAG 2.2?

No. WCAG 2.2 is the version of the accessibility guidelines, while Level AA is a conformance level. Level AA includes the applicable Level A and Level AA success criteria.

Does WCAG 2.2 replace WCAG 2.1?

WCAG 2.2 builds on WCAG 2.1 by adding nine new success criteria. The earlier success criteria remain essentially the same, with 4.1.1 Parsing becoming obsolete and being removed.

What are the new WCAG 2.2 Level AA requirements?

The new Level AA criteria include Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum), and Accessible Authentication (Minimum).

Can an automated accessibility tool confirm WCAG 2.2 Level AA conformance?

No. Automated tools can identify many potential issues, but a complete accessibility evaluation can require manual testing, human judgment, and interaction testing.

Is WCAG 2.2 Level AA relevant to eLearning?

Yes. Websites, LMS platforms, online courses, assessments, interactive activities, and other web-based learning experiences can contain accessibility barriers that should be evaluated against applicable WCAG requirements.

Should accessibility testing be done only after a course is completed?

Accessibility is generally easier to manage when it is considered throughout design, development, content production, QA, and maintenance rather than being treated only as a final-stage task.

Key Takeaways

• WCAG 2.2 is a W3C Recommendation published on October 5, 2023.
• WCAG 2.2 introduced nine new success criteria compared with WCAG 2.1.
• Level AA requires applicable Level A and Level AA requirements to be met.
• New Level AA criteria include Focus Not Obscured, Dragging Movements, Target Size, and Accessible Authentication.
• Automated testing is useful but should be combined with appropriate manual testing.
• eLearning accessibility should be reviewed across the complete learner journey.
• Accessibility should be considered during design, development, QA, and ongoing maintenance.
• WCAG 2.2 should be evaluated using the official W3C requirements rather than relying only on simplified checklists.

Sources and References

The primary technical source for this article is the official W3C Web Content Accessibility Guidelines (WCAG) 2.2 specification.

1. W3C — Web Content Accessibility Guidelines (WCAG) 2.2
2. W3C WAI — What’s New in WCAG 2.2
3. W3C — WCAG 2.2 Recommendation Announcement
4. W3C — Understanding Conformance
5. W3C — WCAG 2.2 Quick Reference

Source note: The technical requirements and WCAG 2.2 changes discussed in this article are based primarily on the official W3C/WAI WCAG 2.2 documentation. The eLearning examples and practical explanations have been written specifically for TheEduAssist’s audience.

Conclusion

WCAG 2.2 Level AA provides a structured framework for improving the accessibility of websites, LMS platforms, and digital learning experiences.

The standard covers more than automated accessibility checks. It includes requirements related to keyboard access, focus visibility, target size, dragging movements, authentication, forms, navigation, content, and other parts of the user experience.

For eLearning organizations, accessibility should be considered across the entire learner journey, from login and course navigation to interactive activities and assessments.

A combination of automated testing, manual accessibility review, keyboard testing, content evaluation, remediation, and retesting can provide a more complete approach to accessibility evaluation.

For organizations that need support with learning content quality and accessibility, TheEduAssist’s Quality Assurance and Accessibility services can be part of a broader digital learning QA process.