Accessibility link to current page

develop | Release notes

Overview
#

Kolibri products should be accessible to the widest possible audience, in the broadest sense of the word 'accessible'. It should run on wide variety of devices, render correctly on a wide variety of screen sizes and assistive technologies, be understandable to people from a wide variety of backgrounds, and be usable by people with diverse abilities.

At a high level, we follow the web content accessibility guideline that for all users, information should be:

  • Perceivable
  • Operable
  • Understandable
  • Robust

Window size and zoom
#

Users will use devices that have a wide range of screen sizes. Additionally, some users with poor vision may zoom far in, which effectively lowers the size.

We should aim to allow zooming up to 200%, and down to 480x600 px in both profile and landscape. The app should always remain functional in all extreme screen sizes. Depending on the context, we may want to put additional effort into creating custom layouts optimized for particular screen sizes. For example, we should put additional effort into optimizing the mobile Learner experience, while for administrators this might not be as critical.

When designing and building layouts, we use the breakpoints defined by Material Design. These are exposed in our app by the useKResponsiveWindow composable. We should never use CSS media queries. See the See the Layout page for more information.

Keyboard navigation
#

Every interaction that can be performed with a mouse or touchscreen should also be accessible by using the keyboard. As much as possible, we should follow best practices including:

  • high-contrast focus indicators
  • intuitive navigation tab order
  • conventional keyboard shortcuts for common input widgets

Using the built-in components outlined in this guide is a good way to ensure that your UI will be navigable by keyboard. When building custom components, use our standard focus outline $coreOutline as described in the Styling page .

Screen reader support
#

All content that can be read by sighted users should be readable by screen readers. Additionally, the app should leverage screen-reader-specific functionality – such as labels, semantically correct HTML tags, and visually-hidden text – that associates descriptive text with functionality.

Like with keyboard navigation, using the built-in components is a good way to ensure compatibility with screen readers. However, it's also critical to test all new functionality. See this comprehensive list of accessibility testing tools.

Some specific things to watch for:

  • Use ARIA attributes when appropriate. (In general, this is only when using semantically correct HTML is not possible.)
  • Nest header tags properly: h1, h2, h3, etc.
  • alt text on images

Color and contrast
#

Contrast should be at least 3:1 for large text and 4.5:1 for smaller text. Colors should either be color-blindness-safe, or be redundant with a non-color-based representation of information.