It really matters

Nucleus cares deeply about inclusivity. To help everyone, the aim is to understand the impact of every decision made.

Accessibility is a key foundation of Nucleus. In addition to accessibility principles and starting points to accommodate different types of barriers, it has been ensured that Nucleus components integrate WCAG 2.1 Level AA practices.

The following guidance has been provided by the Nucleus accessibility partner Digital Accessibility Centre (DAC).

Colour

A high level of colour contrast assists people with sight loss, including colour blindness, as well as people with cognitive disabilities.

There are two primary rules to follow for accessibility related to colour.

• We never use colour as the only means of providing information or requesting an action.
• The combinations of text and their background colours do not fall below the WCAG recommended threshold ratio of 4.5:1 for standard or small text and 3:1 for larger text.

There are several tools listed in the Accessibility Tools section lower down this page that may help.

Audio and video

• Audio and video content including important speech or sound must have a text equivalent.
• Captions are provided for all pre-recorded audio content in synchronised media, except when the media is a media alternative for text and is clearly labelled as such.
• Audio and/or video embedded in an application (including audio that is part of a video or multimedia file) must play for no more than 3 seconds before pausing or plays only when the user chooses.
• When pressing play a screen reader user must be able to use a single button press to pause it again.
• Disabled users have access to clearly labelled play and pause controls for the audio/video player.

Forms

• All form fields are labelled or, where it is not possible to label a form, a descriptive aria-label attribute is used.
• Where errors occur on a form, the user is informed as to which fields need attention and why.
• Provide informative error messages and a means of navigating away from an error message back to useful information.

Gestures

• Gestures must be intuitive and consistent.
• The solution will allow the use of familiar gesture controls such as finger swipe, taps, zoom pinch/pull.
• Do not insert functions that can only be managed via gestures (such as swiping motion).
• Always add a button/link so that users who have limited dexterity can tap a button to navigate.

Images

• All images must have valid alt attribute values.
• Link images describe the destination page.
• Button images have an alt attribute that describes the function of the button.
• Images used for decorative and spacing purposes rather than providing essential, contextual and functional guidance must have a null alt attribute (aria-hidden="true" or alt="") to hide it from screen readers.

Links

• The solution must clearly show via text and label where each link will take the customer.
• Where a link to content that differs in file format is presented, the format and size will also be presented in the link title.
• Image links and buttons have an alt text that describes their purpose.
• All links are visible or become visible when they receive focus.

Motion

• Images do not flicker at a rate that may trigger seizures in susceptible individuals.
• Content should not flash more than 3 times in any 1 second period.
• Movement on the page is limited to 5 seconds.
• If movement takes longer than 5 seconds, use a control on the page that stops moving, blinking or auto-updating content.

Navigation

• Ensure that material that is central to the meaning of the page precedes material that is not.
• Divide pages into usable but limited-size portions.
• Create a logical order through links, form controls and objects.
• Users will be able to use external hardware to navigate the solution, such as Bluetooth keyboards.
• All aspects of the navigation can be accessed using keyboard-only control and screen readers.

Types of barriers

Inclusivity and accessibility are fundamental. No one should be left out. Ever.

Physical barriers

When designing experiences for users who have physical disabilities which impact their mobility, it is important to acknowledge the following:

• Provide shortcuts.
• Make large clickable actions.
• Give form fields space.
• Design with mobile and touch screen in mind.
• Design for keyboard or speech only use.

Cognitive development

When designing experiences for users who have cognitive disabilities, it is important to acknowledge the following:

• Reading age may be lower.
• Busy page layout can be confusing (Keep it simple!).
• Ambiguous labels and icons can be confusing.
• Users may be easily distracted by moving animation.
• Short-term memory may be affected.

Hearing loss

When designing experiences for users who have hearing loss, it is important to acknowledge the following:

• Provide synchronised captions for all video content.
• Do not use audio features.
• Provide transcripts for all audio content.
• Deaf users require captions if the video does not make sense when the sound is turned off.

Sight loss

When designing experiences for users who have sight loss, it is important to acknowledge the following:

• The contrast between the text and the background may not be sufficient (W3C ratio 4.5:1).
• Text may not be large enough to read so would need to resize or zoom into content.
• Do not cause content to update elsewhere on the screen after selecting an item.

Screen readers are used to translate written text into speech:

• All non-text elements (images, multimedia) require a text alternative.
• Visual structure must be represented in a logical order, use headings.
• Navigation must be obvious to users (scrolling content can be confusing).

Permanent vs. temporary

Some barriers are permanent, some temporary. Suffering from an injury or illness can limit the use of a limb. Not being fluent in a language lowers our reading age. We might want to watch a video with its sound muted but not have any headphones at hand.

It’s likely that everyone experiences these barriers at some point in their lives. Whether temporary or permanent, our abilities should not be considered any less than those of others. It’s simply a different approach to getting on and taking action.

Accessibility Tools

Here are some accessibility tools you might find helpful:

Nucleus Checker

https://github.com/centrica-engineering/nucleus-checker Nucleus Checker is a browser developer tool extension that can help verify standards by highlighting any issues relating to how the Nucleus components are being used.

SortSite

https://www.powermapper.com/products/desktop/try/ A website accessibility checking tool.

Total Validator

https://www.totalvalidator.com/ Total Validator will validate HTML and CSS, check that pages are accessible, run a spell check, and check for broken links. Performing a one-click validation of a website.

WAVE Web Accessibility Evaluation Tool

http://wave.webaim.org/ Web accessibility evaluation tool.

Colour Contrast Analyser

https://developer.paciellogroup.com/resources/contrastanalyser/ The Colour Contrast Analyser (CCA) helps determine the legibility of text and the contrast of visual elements, such as graphical controls and visual indicators.

Sim Daltonism

https://michelf.ca/projects/sim-daltonism/ Sim Daltonism visualises colours as they are perceived with various types of colour blindness. It uses the camera on a iOS device, or on the Mac app to filter a region of the screen. Sim Daltonism is open source.

Stark for Figma

https://www.getstark.co/figma/ An easy-to-use plugin that has clear results. Use of the contrast ratio checker with an eye dropper is free, or sign up for the full version to unlock other useful features to use right in the workspace when designing.

Using another tool?

If there are any other tools that you think should be included here, please get in contact with the Nucleus Design System Team.