...
The overall compliance of Totara 13: Learn, Perform, and Engage is Partially Supports WCAG 2.1 at Level A and AA. The product supports the majority of Success Criteria at both Level A and AA. The cases where the Success Criteria are classified as Partially Supports are either infrequent cases or have no impact on the user. Read more about our approach and our new and updated Accessibility Conformance Report at Accessibility at Totara.
Implementation
The Uniform set of components include baked-in accessibility. Some of the features:
Every form control has an accessible name (whether it's visible on screen or not, using aria-label or aria-labelledby)
Every group of controls (such as checkboxes, radios, and date selectors) has an accessible name
Error states are programmatically communicated (using aria-invalid) and error messages are programmatically linked (using aria-describedby)
Here's an example with one text input and one set of radios.
...
Tips and known limitations
Test with a keyboard, no mouse or trackpad. It's an accessibility requirement that all functionality is available from the keyboard. Can you see where you are on the page? Look for a visible (focus) indicator as you navigate. Can you interact with every element on the page? Can you use functionality (such as tooltips) that you usually see on a hover action?
Run the axe browser extension. This will pick up any big accessibility problems (such as form controls missing labels). It's quite lenient, as it aims for no false positives. It has links out to 'how to fix' articles. It's widely recognised as the tool of choice.
Use Accessibility Bookmarklets to visually check the content. This checks that semantic HTML was properly used (meaning that screen reader users will be be able to access the content properly).
Ideally, test with a screen reader. It's an important part of accessibility work. It helps anyone who uses that particular assistive technology (such as blind people and people with other visual disabilities). It also helps us check that our code is robust and semantic. Check structure, interactions, alt text, form error handling, and the order of the content. JAWS with Chrome, NVDA with Firefox, and NVDA with Chrome are the most popular combinations, so test with one of those if you can.
Recommended reading
WAI-ARIA Authoring Practices are a good source of patterns.
WebAIM, Deque, and the Paciello Group provide lots of free, useful, resources on designing, developing, and testing more accessibly.
Inclusive Components is a collection of accessible HTML/CSs/JS components.
Some of the tools we've been using to improve the accessibility of Totara:
Automated linting and testing in the codebase using jest-axe
Browser extensions to test rendered code in the browser (Deque's aXe, The Paciello Group's ARC Toolkit)
Manual assessment of WCAG Success Criteria, partially facilitated by Microsoft's Accessibility Insights
Functional testing with Screen Readers (VoiceOver on MacOS, NVDA on Windows, Orca on Ubuntu)