Accessibility – ReGraph Docs

Designing accessible products means they can be used effectively by as many people as possible, providing an inclusive experience for people with impairments and different needs.

Accessible design improves the product for everyone, as well as creating a better user experience for users with disabilities. In addition, most countries support accessibility with laws and regulations on both public and private sector organizations.

There is no single universal standard, so we recommend that you always check what policies are relevant for you. However, the W3C's Web Content Accessibility Guidelines 2.1 are most often referenced as an acceptable standard.

Compliance with Regulations

ReGraph is not a complete application by itself, it is a toolkit that you integrate into your own product. This means that accessibility should be considered at the level of the end product to give your application users the best user experience possible.

ReGraph as a visual medium is often exempt from compliance requirements because the functionality cannot always be fully reproduced in an accessible way. To help you with your accessibility audits, we have prepared a table that summarizes the guidelines of WCAG 2.1 and how they relate to ReGraph:

#wcagGuidelinesTable.docs-text-collapsable.hidden

Guideline	Relevance to ReGraph
1.1 Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.	Exempt. ReGraph provides a visual component that cannot be fully reproduced in text. The end product can deliver high level information about the visual component in another format - see for example ARIA Support and Charts and Audio.
1.2 Provide alternatives for time-based media.	Not applicable. Should be ensured by the end product.
1.3 Create content that can be presented in different ways (for example simpler layout) without losing information or structure.	Not applicable. ReGraph provides a visual component only, any alternative ways of presenting content should be ensured by the end product.
1.4 Make it easier for users to see and hear content including separating foreground from background.	ReGraph provides features that can assist with making charts compliant with this. See accessible styling for more details.
2.1 Make all functionality available from a keyboard.	ReGraph lets you add custom keyboard navigation.
2.2 Provide users enough time to read and use content.	ReGraph is designed to display any text (such as labels or glyphs) long enough to be readable, as long as the features are implemented correctly.
2.3 Do not design content in a way that is known to cause seizures.	All ReGraph default animations and features (incl. ping) are below "Three Flashes or Below Threshold".
2.4 Provide ways to help users navigate, find content, and determine where they are.	Not applicable. Should be ensured by the end product.
3.1 Make text content readable and understandable.	Not applicable. Should be ensured by the end product.
3.2 Make Web pages appear and operate in predictable ways.	Not applicable. Should be ensured by the end product.
3.3 Help users avoid and correct mistakes.	Not applicable. Should be ensured by the end product.
4.1 Maximize compatibility with current and future user agents, including assistive technologies.	Not applicable. Should be ensured by the end product. However, ReGraph provides the ability to set all ARIA properties.

We are always working on implementing features that make ReGraph more accessible and easier to use. Some tips using various ReGraph features are listed below.

Keyboard Controls

ReGraph doesn't have any native keyboard navigation behavior, which means that you can customize keyboard controls without having to override any default actions. To help you do this, ReGraph offers a number of native chart events and time bar events that you can respond to. It also supports standard element events such as keydown, focus and others.

This example shows how to customize keyboard navigation behavior by calling the pan() and zoom() instance methods in a handler triggered by a keydown event listener:

Keyboard Shortcuts

If you want more control over the exact way the chart view changes on a key press, you can update the view prop to change the view of the chart instead.

Some browsers support some keyboard navigation by default, e.g. using the Tab key to iterate through form controls. When planning keyboard shortcuts, you should avoid overriding native browser and operating system shortcuts that affect the browser behavior.

Accessible Styling

Text

We recommend using simple sans-serif fonts as they are generally easier to read for most users. Alongside text, you should also convey the meaning in another way that doesn't require reading or understanding the language, such as font icons, glyphs or images.

Color

The colors you use should always have a sufficient contrast ratio. Online tools such as this WebAIM Contrast checker can help you check your color combinations for accessibility. When styling nodes, you can also consider using SVG images with patterns and textures instead of colors.

Show meaning in multiple ways

You should not rely on a single method, such as color, to convey a meaning. On nodes you can also use advanced styling to add labels, images, font icons or glyphs, while on links you can use text-based labels, glyphs, dashed and dotted line styles or flow animation.

Separate and foreground content

To make charts as readable as possible, choose the layout that best represents the type of your data and connections. Consider what is the best tightness for your chart. To reduce the cognitive load, consider foregrounding and backgrounding relevant or selected items. See more in the Neighbors story.

ARIA Support

ARIA (Accessible Rich Internet Applications), is a set of roles and attributes that can supplement HTML elements or attributes that don't have built-in accessible semantics or behavior.

ReGraph lets you set ARIA properties on the DOM element. The Playground lists all supported ARIA props in the code-autocomplete when you start typing.

Note that there is no programmatic access to nodes/links rendered on the canvas. You can use aria-hidden property to hide it from screen readers.

<div
  style={{ height: '100%' }}
  aria-label={ `A simple chart` }
  aria-description=
  { `A simple chart with ${Object.keys(items).length} green node(s)` }
>
<Chart aria-hidden={true} items={{ node1: { color: '#2dcda8' } }} />
</div>

Charts and Audio

Seeing a chart is essential for spotting and understanding the patterns and connections revealed in the data, which makes it challenging to make charts accessible e.g. for screen readers. As an alternative, you can hide the chart's div from screen readers using the aria-hidden property, and instead supply a text in the aria-description that summarizes the chart to the extent needed in your context, for example:

The element here is a chart made of nodes and links, where nodes represent employees from several departments and links represent their email communications. The chart communicates that most emails are sent between management and marketing.

You can also use audio as an additional channel to written information or as an extra method of alerting or highlighting, but remember to never rely on audio alone.

Text To Speech