What You Need to Know About WCAG Accessibility Compliance

WCAG might be the global benchmark, but compliance alone doesn’t guarantee your learning content is truly accessible. It’s about making sure every learner, regardless of ability, can actually navigate, understand, and engage with what you create.

Created by the World Wide Web Consortium (W3C), the Web Content Accessibility Guidelines (WCAG) set the standard for accessible digital design worldwide. They’re recognized in most major regions—including Australia, the U.S., the U.K., Canada, and the EU—as the foundation for accessibility policy. In Australia, WCAG compliance supports the Disability Discrimination Act 1992, while in the U.S., it’s used to assess accessibility under Section 508 and the Americans with Disabilities Act (ADA).

The latest WCAG 2.2 update raises the bar again—refining how we think about logins, navigation, input methods, and interactive elements. In this guide, we’ll break down what’s new, what’s essential, and how to design eLearning that’s inclusive by default, not just technically compliant.

What is accessibility?

Spoiler: accessibility is not just about good color contrast.  

There are certain standards in place to ensure that disabled users can access, navigate, and understand online resources.  

The first thing to do is define what accessibility is in an eLearning context, since it differs from just fulfilling a set of technological criteria—especially when catering to a global audience.  

The Disability Discrimination Act 1992 (DDA), enacted by the Australian Government, gives a starting point for a definition, as it prohibits many kinds of discrimination (such as access to information and education) against individuals with one or more disabilities.  

In Australia, the Australian Human Rights Commission (AHRC) interprets digital inaccessibility as potential non-compliance under the DDA, which means Australian Government organizations have a legal and ethical obligation to ensure their digital learning tools are accessible by default. Using a platform that already meets WCAG 2.2 standards—such as Acorn’s PLMS—can remove much of the complexity from accessibility compliance while ensuring a consistent experience for all learners.

And when we say disabilities, we’re talking about a broad spectrum of impairments. 

• Sensory disabilities such as:  
  • – Hearing disabilities and deafness. 
  • – Visual impairments such as a partial or complete inability to see out of one or both eyes, sensitivity to bright colours and flashing lights, and colour blindness. 
• Cognitive/neurological disabilities, including learning difficulties, memory problems, distractibility, and inability to focus on and process large quantities of information. 
• Physical impairments, including an inability to use a mouse and/or keyboard, as well as a lack of fine motor skills. 

Accessibility is for everyone 

Each of these disability categories require specific adaptations to eLearning content, but it is worthwhile investing the time to ensure your content caters to a diverse audience. 

And you’re not just helping those with disabilities with accessible measures. For example:  

• Providing an accessible text-only alternative to image, audio or video data allows for screen reader users to engage with the content and deaf users to read transcripts of audio only content and also gives users with poorer internet connections a more reliable alternative to access course material. 
• Breaking a complex infographic or diagram into smaller steps makes it easier for a course creator to describe the image’s alt-text (or provide text instructions for that step), which in turn makes it easier for a screen reader user to interpret. Chunking the content into steps also makes the content significantly easier to understand and complete in stages for any user, regardless of cognitive ability. (Hello, microlearning.) 

Then there are also rights to accessibility, freedom of expression, and access to information to consider. In addition to the previously mentioned DDA, the Australian Government helped to ratify the United Nations’ Convention on the Rights of People with Disabilities, which includes multiple guiding articles on the aforementioned. 

Within the Australian Public Service (APS), accessibility also forms part of the Digital Transformation Agency (DTA)’s broader digital inclusion agenda. That means it’s not just an issue of accessibility, but how government organizations deliver information and learning to employees and citizens alike.

When it comes to really defining accessibility, there’s a more applicable meaning that comes from the W3C. Their guidelines are an extensive, frequently revised range of recommendations for making any kind of web content more accessible. The first ever formalised version of these guidelines was created in 1999, and in 2023, after 5 years of ongoing development, the W3C released its latest published list of recommendations—otherwise known as WCAG 2.2. 

What defines WCAG 2.2 compliance?

There are three different levels of WCAG compliance:  

1. Level A (the minimum level) 
2. Level AA (the standard benchmark in many regions) 
3. Level AAA (the highest, though not always practical). 

For Australian Government agencies, Level AA is the minimum compliance requirement under national accessibility policy. In procurement terms, this means any LMS or PLMS purchased must be demonstrably accessible—usually proven through WCAG 2.2 certification and a Voluntary Product Accessibility Template (VPAT).

There are then four principles that underpin these accessibility guidelines. Below are their definitions and what that may look like for digital content creation.

1. Perceivable 

Definition:  Information and User Interface components must be presentable to users in ways they can perceive. 

Any resources you include should be navigable and perceivable to all users with relative ease. Where there is information that relies on sight or sound (such as graphics, audio or video), an accessible text alternative should also be included. 

2. Operable 

Definition: User Interface components and navigation must be operable. 

Your content should be constructed in a way that a user does not need to rely on fine-motor skills to access it. This means you should not make content that can only be accessed using a mouse or touch device, and your content should be tested for keyboard-only navigation, and screen reader technologies where applicable. 

3. Understandable 

Definition: Information and the operation of the user interface must be understandable. 

The meaning and purpose of your content should be relatively clear and unambiguous in nature. Any content-specific jargon or abbreviations should also be explained as part of the content. If your content allows, courses should follow an established and consistent pattern to allow for easier navigation by users as they get more familiar with them. 

4. Robust 

Definition: Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies. 

Your content should be tested on multiple screen sizes, pixel densities, devices, browsers and operating systems — not all browsers are made equal! Where possible, manual testing should be performed with a screen reader in addition to any automated testing done. 

Of note, WCAG 2.2 also introduces new requirements that are particularly relevant for eLearning applications. 

• 3.3.8 – Accessible authentication: Where possible, login and verification processes cannot rely solely on memory or cognitive tests (for instance, requiring the user to remember a one-time code or a puzzle). Instead, systems need to enable password entry via recognised password managers, or provide an alternate method. 
• 2.5.7 – Dragging movements: All tasks must be possible without drag-and-drop, and keyboard or button-based alternatives must be in place.  
• 2.5.5 & 2.5.8 – Target size: Interactive elements (like buttons or controls) should have a clickable area of at least 24x24px for Level AA compliance, or 44×44px for AAA compliance, except for when the clickable information is within a sentence or block of text.  
• 2.4.11 – Focus not obscured: When navigating by keyboard, the current point of focus needs to remain visible on screen. Progressive rendering of content should not push the focused element off-screen while focus remains on it.  

For a complete overview of what WCAG 2.2 contains, we recommend that you check out the entire document. 

Your WCAG 2.2 compliance checklist

Beyond those core principles, there are a few foundational guidelines worth building into every piece of eLearning content—or, really, any online resource—if accessibility is the goal. 

Alternate descriptions

Always include alternative text or image descriptions for any visuals in your eLearning content. This ensures learners with visual or cognitive impairments can access the same information through screen readers.  

For more complex visuals like charts, infographics, or data visualizations, include extended descriptions that explain the meaning behind the image, not just what it looks like. The key is clarity and context; describe what’s essential to understanding the learning content, not every visual detail. 

Be intentional about when you use alt text, too. Not every image needs it. If an image doesn’t convey new information or serve an instructional purpose, it’s decorative and adding alt text can actually make navigation harder for learners using screen readers.  

In short: describe what matters, skip what doesn’t, and stay consistent in how your team defines “information-bearing” images across your content. 

True headings

Headings aren’t just about visual hierarchy. They provide structure. Use true heading styles (H1, H2, H3, etc.) to define the order and flow of your content, rather than relying on bold text or larger font sizes to signal importance. Screen readers depend on these heading levels and ARIA landmarks (essentially, signposts with a page’s code) to help learners navigate efficiently, so getting this right directly impacts accessibility. 

In Acorn’s Rich Text Editor, it’s simple: highlight your text, then go to Format → Blocks to assign the correct heading level. We recommend starting from H2 downward, since most pages already include an H1 in their markup. Adding more than one H1 per page can trip WCAG compliance, so save it for the main page title and let your subheadings do the organizing. 

Video transcripts & captions

Provide captions and/or transcripts for pre-recorded media. For audio files, a transcript will suffice. For video, both captions and transcripts are essential. Where visual details are critical, include audio descriptions.  

Captions should be accurate. Auto-captioning tools are useful and may still help those who are partially deaf or have auditory processing disorders, but manual verification is still needed to confirm if the transcripts are accurate and representative enough for a deaf audience. 

Sign language

For video or audio content, provide sign language options where possible. In their accessibility guidelines, the NSW Government recommends that Auslan, the Australian sign language, be included for health and safety information as well as information about compliance.

Colour accessibility

Don’t rely on color alone to present information, especially for style changes in response to user input. Ensure minimum contrast ratios (4.5:1 for normal text, 3:1 for large text) and provide alternatives for color-dependent content. Alternatives can include screen reader feedback, addition of text messages, and changes to the size, shape, or representative graphics used.

Target size & input methods

For SCORMs and other interactive content, elements such as buttons and links should have minimum target size of 24×24 pixels. Also avoid requiring dragging gestures for core functionality—make alternatives available for users with mobility limitations.

Keyboard & focus visibility 

Ensure that all functions can be accessed via keyboard. Provide a clear, visible focus indicator and make sure it isn’t hidden behind sticky navigation, layout changes, or other page elements.

File formats

Ensure that downloadable eLearning content (Microsoft Word documents, PDF files, PowerPoint presentations, and so on) are as accessible as possible. Tagged PDFs, logical reading order, and alt text for images are essential. (A list of techniques that can make PDFs WCAG 2.0 compliant is available from the W3C.) 

Where possible, any rich HTML content, such as SCORMs or complex layouts created in your rich text editors, should be held to the same WCAG guidelines as any other website or application.  

How to self-assess compliance

Being able to self-assess the accessibility of your eLearning content is an undeniably handy skill to have. The W3C provides a list of updated web accessibility evaluation tools to determine if your online resources meet WCAG 2.2 requirements at your target level, however it is important to note that any automated auditing software is only going to be as useful to you as your ability to manually test and verify its findings, and should not be used as a complete replacement for manual or third party testing. 

With that in mind, a self-assessment is only worthwhile if your company’s internal ICT policy and procedures are in line with the W3C’s accessibility guidelines. These guidelines should already be integrated into communication policies and practices, and all eLearning content—both new and old—should at least be on the path to WCAG 2.2 compliance. 

In practice, organizations often supplement self-assessments with a Voluntary Product Accessibility Template (VPAT), which documents conformance against WCAG standards on their web application at a very broad level. External audits can also provide assurance and will usually go more in-depth based on how those audits are scoped. For example, within the bounds of the scope, Acorn’s most recent external audit confirmed WCAG 2.2 AA compliance across our PLMS. 

A marathon, not a sprint 

As technologies change, so too do the guidelines for accessibility within the context of the web. WCAG 3.0 is still being developed, ongoing since 2021. The most recent public working draft was released in early September 2025, and it’s not expected to be the recommended guideline version for a few years yet, but it is worth keeping an eye on it in the not-too-distant future.  

Additionally, browsers, devices and screen readers go through changes all the time, so it is always important to check content regularly to see if any change impacts the accessibility of your content for assistive devices. 

A final say on WCAG guidelines 

In general, it’s best to make your eLearning content easy to access, navigate and understand. Some best practices to follow: 

• Provide the full expansion of all abbreviations and acronyms when they are first used 
• Use clear language and, when possible, language suited for your intended audience 
• Avoid very small font sizes, as well as excessive use of italics or bold 
• Underline links and make them stand out in other ways 
• Try to reduce confusion wherever possible.  

Remember: If in doubt, provide a clear, text-based alternative. 

By following WCAG 2.2 AA, you’re not only meeting compliance standards—you’re creating learning experiences that are more usable, inclusive, and effective for everyone. 

At Acorn, accessibility isn’t an afterthought. Our platform is independently certified to WCAG 2.2 Level AA and regularly tested through annual VPAT reporting and regular repeat audits, so your learners can engage without barriers and your business can confidently meet global accessibility obligations. 

Learn more about how we consistently ensure accessibility in our platform here: