Accessibility

Owned by Dave Wallace
Last updated: May 30, 2024 by Fabian D.
3 min read

Overview

The overall compliance of Totara TXP: 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.

Resources

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.

<Uniform v-slot="{ getSubmitting }" :initial-values="initialValues" :errors="errors" :validate="validate" @change="handleChange" @submit="submit" > <FormRow label="Name" required> <FormText name="name" :validations="v => [v.required()]" /> </FormRow> <FormRow label="Favourite colour" required> <FormRadioGroup name="favouritecolour" :validations="v => [v.required()]"> <Radio value="red">Red</Radio> <Radio value="green">Green</Radio> <Radio value="blue">Blue</Radio> </FormRadioGroup> </FormRow> <FormRowActionButtons :submitting="getSubmitting()" @cancel="cancel" /> </Uniform>

There are several custom components that come with WAI-ARIA-compliant accessibility built-in in terms of keyboard interaction and WAI-ARIA Roles, States, and Properties. These include Popover, Collapsible (our accordion), Dropdown (our menu), Modal, Notification, and Tabs. The Weka editor has extensive aria support and communicates the identity, operation, and state of each its controls. It follows the WAI-ARIA patterns for a Menu.

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

Some of the tools we've been using to improve the accessibility of Totara:

Â