Introduction Foundations Components Patterns Directives Pipes Motion Brand
Accessibility Colors Copywriting Error handling Grid Illustrations Layouts Spacing Typography Forms

Accessibility and Internationalisation

We connect over millions of users globally. They interact with our user interfaces through language. It is important to consider different cultures, languages and user disabilities when we design our elements by making it accessible.

Examples of things to consider

Labels above fields

Having labels above input field accommodates lengthy text especially when it gets translated into other languages. It also reduces the risk of overlapping text and breaking layouts.

Use of familiar icons

Don’t give other meaning to universally recognizable icons such as save, help and delete.

Adapt elements that surround it

Always keep in mind to view your user interface in a different language, to get an understanding of how the layout might change.

Currencies

Consider how currency values would look in different currencies (eg. larger numbers, or different decimal places).

Resources:

Color contrast checker
International Standard for Currency Codes
WCAG (Web Content Accessibility Guideline)

Accessibility Testing

Familiarity with Web Content Accessibility Guideline (WCAG) will prove useful in building accessible websites so we recommend going through it. But to make things easier, we can leverage some tools to automate accessibility audits for us. For consistency's sake, we'll be using Lighthouse which you can readily use in Google Chrome.

Manual Audit

Run Lighthouse and make sure that new components or any updates to existing ones are passing. This can flag things like low-contrast text, form elements not having associated labels, etc. Do note that there are some areas which automated audits cannot test. We will cover those in the next sections below.

Keyboard Accessible

Interactive elements should be operable via keyboard only. It is important to make controls accessible for those who cannot or do not use a mouse.

Things to look out for when reviewing keyboard accessibility:

Interactive elements can be reached by tabbing through items in your page.
The order in which elements are focused should make sense.
Display a focus indicator (e.g focus ring) so users can see which element they are on.
Avoid adding focus to non-interactive content.
Complex controls such as dropdown items should be usable, i.e items inside it can be reached via keyboard.
Everytime you add event handlers like click, consider keyboard access and appropriate mobile behavior. Does the action need to react to enter keypress and touch events? How will the mouse events like hover translate in mobile devices?

Perceivable

Your components and page as a whole should be accessible and presentable for assistive technologies such as screen readers. We use ChromeVox extension in Google Chrome to emulate a screen reader. In the absence of visual cues, it is important to add information like the role, status, relationship, sequence, etc.

Here are some general guidelines:

Writing semantic markup goes a long way. They are already tagged with proper roles and assistive technologies already know how to navigate and interpret them.

Images should have alt text. It is a way for screen readers to describe the content of an image. An exception to this rule is for when an image is used primarily for presentation, usually they have an adjacent text that sufficiently describes it. In such cases, add an empty alt="" string so they can be skipped by a screen reader.

Custom controls should be labeled appropriately, e.g add appropriate role, label, etc. For more details on how to provide semantics for custom controls, see Introduction to ARIA.