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 responsiveWindow Vue component mixin. We should never use CSS media queries.

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.

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 A11y 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.


All user-facing text and iconography needs to be internationalized. For text strings, numbers, dates, and times, this means "wrapping" the messages such that they can be mapped to messages in other languages using the ICU message syntax. See our developer docs for more information.

Icons and phrases that might not be globally understood should be avoided. Also, beware of using terms like 'left' and 'right' in RTL languages.

The built-in components in this guide support right-to-left languages out of the box. If you design or build custom components, these need to be fully tested using an RTL language. We use a webpack plugin to automatically flip most of the CSS, and the global isRtl attribute on all Vue components can be used to customize behavior if necessary.

A subset of icons need to be flipped in RTL languages.