Skip to main content

Introduction

Purpose of this documentation​

This documentation aims to guide Data users on how to apply digital accessibility practices when building their applications. Using the tool's native resources, it's possible to create interfaces that are inclusive and comply with the main international accessibility standards, such as the Web Content Accessibility Guidelines (WCAG) and recommended practices for using ARIA (Accessible Rich Internet Applications) attributes.

Basic web accessibility concepts

What is digital accessibility?​

Digital accessibility is the practice of making websites, systems, applications, and online content usable by everyone, including people with some form of disability — whether visual, auditory, motor, cognitive, or otherwise.

When an application is accessible, it allows users with different needs to navigate, understand, interact, and communicate efficiently and independently, whether using screen readers, adapted keyboards, voice commands, or other assistive technologies.

Accessibility Standards and Best Practices

Introduction to WCAG (Web Content Accessibility Guidelines)​

WCAG (Web Content Accessibility Guidelines) is a set of international guidelines created by the W3C (World Wide Web Consortium), aimed at guiding the development of accessible web content for everyone, including people with disabilities.

These guidelines define technical standards and best practices that help ensure websites, systems, and digital applications are accessible, usable, and understandable for the largest possible number of users.

Brief explanation of the levels (A, AA, AAA)​

WCAG is organized into three levels of conformance:

  • Level A (minimum) – Meets basic accessibility requirements.
  • Level AA (recommended) – Meets the main accessibility needs, balancing technical feasibility and inclusion. It's the most widely adopted level worldwide.
  • Level AAA (maximum) – Offers the highest level of accessibility, applicable in very specific cases.

Technical Accessibility Resources

For a web application to be truly accessible, it's essential to correctly use certain technical resources that make navigation, interaction, and comprehension easier for users who rely on assistive technologies, such as screen readers, voice browsers, or keyboard navigation.

These resources can be divided into two main pillars: semantic HTML attributes and ARIA (Accessible Rich Internet Applications) attributes.

Semantic HTML attributes​

Semantic HTML is the foundation of web accessibility. It consists of using the correct tags that have their own meaning, helping to structure information and guide both browsers and users about the function of each element on a page.

When we use tags like <button>, <nav>, <header>, <footer>, <main>, <section>, <article>, or <label>, we're telling assistive technologies what role that content plays in the interface. This allows people navigating with screen readers, for example, to understand the page hierarchy, identify menus, sections, forms, and interact with elements efficiently.

ARIA attributes (Accessible Rich Internet Applications)​

ARIA attributes were developed specifically to fill the gaps that arise when using custom elements that have no native semantic representation in HTML. They allow you to describe the role, state, and properties of complex components, making them understandable to assistive technologies.

For example, if your interface uses a <div> styled as a button, a screen reader won't automatically recognize it as a button. To fix this, you can use role="button" together with attributes like aria-label to provide an accessible name, or aria-pressed to indicate whether that button is currently pressed.

Data² - Accessibility Settings

To understand accessibility settings in DATA², it's important to know that each block is rendered as a <div> in HTML. Additional accessibility settings must be made through the specific accessibility parameters available.

In addition, artboards in DATA² are automatically indexed for Tab-key navigation, following the order in which components appear in the artboard's component tree.

With these two concepts in mind, let's start understanding how to apply accessibility settings:

Tab Index​

Tab Index is one of the most important aspects of accessibility for people with visual impairments, since it determines the order in which screen readers go through an artboard's components.

As mentioned earlier, by default components are read in the order they appear in the component tree. However, this order can be changed manually by configuring the Tab Index.

For example, if three components are created without any Tab Index configuration, they'll be read in creation order. But if the last component is given Tab Index 1, it will be read first, overriding the original order.

This control is especially relevant when using referenced components. If a referenced component has a Tab Index of 1, it will be prioritized in the reading order — even if it's visually positioned after other elements on the artboard.

To avoid unexpected behavior, it's essential that every component on the artboard has its Tab Index properly configured.

For referenced components, it's recommended to create a Tab Index parameter that can be configured directly on the artboard where the component is being used.

How do you set up this parameter?

Since the default reading order follows the component tree, we create a Tab Index parameter for the referenced component and apply that value to all of its navigable elements. This way, when configuring the Tab Index on the artboard, we ensure all of the component's internal elements are read in the expected order before the screen reader moves on to the next items.

Accessibility Role​

This parameter defines the component's ARIA role, telling screen readers what its function is — for example, <button>, <alert>, or <heading> (title). Note: For a full list of roles, see WAI-ARIA Roles | MDN Web Docs

Setting this parameter correctly determines how the component will be interpreted by assistive technologies. By default, its value is none, meaning the component won't have a specific role assigned.

However, as an accessibility best practice and to avoid unwanted interpretations, it's recommended to explicitly force this setting. To do so, turn the parameter's value into a string and set it to "none", ensuring screen readers don't automatically assign an inappropriate role to the component.

Accessibility Level​

This parameter should only be used when the component's Role is set to <heading>. It determines the heading's hierarchical level, equivalent to HTML tags like <h1>, <h2>, <h3>, and so on. Setting this level correctly is essential to maintain a logical heading structure when read by assistive technologies.

Accessibility Label​

This parameter defines the text that will be read by screen readers when the component has no visible text. It's especially useful for images, icons, buttons, or purely visual blocks, ensuring users with visual impairments know the function or content of the element.

Accessibility Hide​

This parameter lets you hide the component from screen readers, preventing it from being read by assistive technologies. However, note that if the component has a Tab Index configured, it will still be read, even with Accessibility Hide enabled. Tab Index overrides this setting, so it should be used with care.

Validation Tools​

  • NVDA
  • VoiceOver

Additional Documentation​