WCAG, or the Web Content Accessibility Guidelines, are a set of international standards that provide guidance on how to make web content more accessible to people with disabilities. These guidelines inform the standards for eLearning courses, and documents and mobile apps, too. Here’s how WCAG applies to digital assets other than websites:

E-Learning

• Perceivable: Information and user interface elements must be presentable to users in ways they can perceive (provide alternatives for visual and auditory content)
  • Text alternatives for non-text content: Images, videos, and other multimedia should have text descriptions (alt text) so screen readers can convey the information to users with visual impairments.
  • Captions and transcripts for audio content: Videos and audio recordings should have captions for people who are deaf or hard of hearing, and transcripts for those who prefer to read the content.
  • Audio descriptions for video content: For videos with important visual information, audio descriptions should be provided to narrate the visual elements for people with visual impairments.
  • Sufficient colour contrast: Text and interactive elements should have sufficient colour contrast against their background to be visible to people with low vision.
• Operable: User interface components and navigation must be operable (ensure that users can interact with the eLearning course using a variety of input methods)
  • Keyboard accessibility: All functionality should be operable using a keyboard, so people who cannot use a mouse can still navigate and interact with the course.
  • Time limits: If there are any time limits, users should be able to pause, stop, or extend them.
  • Seizures and physical reactions: Content should not contain anything that flashes more than three times in a second, as this can trigger seizures in some people.
• Understandable: Information and the operation of the user interface must be understandable.
  • Clear and consistent language: Use clear and concise language, and avoid jargon or technical terms.
  • Consistent navigation: Navigation should be consistent throughout the course, so users can easily find their way around.
  • Error prevention: Help users avoid making mistakes by providing clear instructions and error messages.
• Robust: Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
  • Valid code: Use valid HTML and CSS to ensure that the course can be interpreted correctly by different browsers and assistive technologies.
  • Compatibility with assistive technologies: Test the course with different assistive technologies, such as screen readers and keyboard-only navigation, to ensure that it is accessible.

 

Documents

WCAG also applies to documents used in eLearning, such as PDFs, Word documents, and presentations. To make these documents accessible, you should:

• Provide alternative text for images and other non-text content.
• Use headings and subheadings to structure the document.
• Use lists and tables correctly.
• Ensure sufficient colour contrast between text and background.
• Make sure the document is navigable using a keyboard.
• Use a logical reading order.
• Save the document in an accessible format, such as tagged PDF.

Mobile Apps

The four core principles of WCAG (POUR) remain the foundation for mobile app accessibility:

Perceivable:
Users must be able to perceive the app’s content.

• Provide text alternatives for images and other non-text content.
• Offer captions and transcripts for audio/video.
• Ensure sufficient colour contrast.
• Make sure content adapts to different screen sizes and orientations.

Operable:
Users must be able to operate the app.

• Make all functionality available through a keyboard or alternative input.
• Provide enough time for users to complete tasks.
• Avoid content that triggers seizures.  
• Make it easy to navigate and find information.

Understandable:
The app’s interface and information must be understandable.

• Use clear and consistent language.  
• Provide helpful error messages.
• Ensure the app’s layout and navigation are predictable.

Robust:
The app must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies. 

• Use valid code.
• Ensure compatibility with screen readers and other assistive technologies.
  

Mobile-Specific Considerations

WCAG has evolved to address the specific challenges of mobile apps:

• Touch: WCAG 2.1 introduced success criteria related to touch targets (buttons, links) to ensure they are large enough and have enough spacing around them for easy tapping. WCAG 2.2, which builds upon WCAG 2.1, added Success Criterion 2.5.7: Dragging Movements. This criterion focuses on users who may have difficulty with dragging actions, often requiring fine motor skills. It requires that content that uses dragging (like sliders or draggable items) must offer an alternative method to accomplish the same task. The goal is to ensure that people who have difficulty with precise movements can still use the content effectively.
• Orientation: Apps should support both portrait and landscape orientations, and content should adapt accordingly.
• Gestures: Complex gestures (e.g., multi-touch) should be avoided or have alternatives, as they can be difficult for some users.
• Zoom and Scaling: Users should be able to zoom in and out without loss of content or functionality.
• Assistive Technologies: Mobile apps need to be compatible with built-in mobile accessibility features like screen readers (VoiceOver on iOS, TalkBack on Android) and magnification tools. 

Exceptions

When developing mobile apps, the goal is always to make them as accessible as possible. There are times when exceptions to the WCAG guidelines may apply. These exceptions are limited and should be carefully considered. For instance, some content in the app might not be essential to its functionality or understanding. Decorative content, such as an image that doesn’t convey any meaningful information, might not require a text alternative. It’s important, though, to ensure that this content truly serves no purpose in the app’s design or experience. Similarly, content from third-party sources—like embedded maps or social media feeds—may not meet WCAG guidelines, and while it might be considered an exception, developers should still strive to ensure the app’s overall accessibility.

There are also cases where the nature of the app itself creates challenges for full accessibility. For example, games often rely on gestures or visual cues that can be difficult to make fully accessible. However, developers can still aim to make games as accessible as possible by providing options for customization, alternative input methods, and clear audio cues. Similarly, apps using virtual or augmented reality often face unique accessibility challenges due to their immersive experiences. While full WCAG compliance might not always be feasible, developers should look for creative solutions—like offering alternative ways to interact or providing audio descriptions—to improve accessibility.

In some cases, developers may face a “disproportionate burden” when making a particular feature accessible. If implementing accessibility features would involve excessive cost, effort, or time, and the feature is rarely used, this exception might apply. However, developers should carefully document their reasoning for claiming the exception and explore alternative solutions that can still offer a reasonable level of accessibility.

Exceptions shouldn’t be seen as a free pass. Even when they apply, developers are encouraged to make their apps as accessible as possible. It’s essential to document reasons for any exceptions and the steps taken to improve accessibility. Most importantly, developers should continuously seek feedback from users with disabilities to understand their needs and identify any accessibility barriers that may remain.