Accessibility

Delivering valuable, inspirational, and accessible experiences for all users, including those with disabilities, is everyone’s responsibility. We are committed to creating products where no one is left behind or faces a confusing or exclusionary experience. We continually iterate on Marigold to provide you with built-in accessibility features across our components, foundations, guidelines, and tooling.

However, how you use Marigold also affects the accessibility of a product. Learn on this page what accessibility means and how to make your apps accessible.

What is accessibility?

Accessibility means making websites and apps easy for everyone to use, including people with disabilities. Disabilities can affect how someone sees, hears, or interacts with an app. The goal is to remove barriers, so everyone has the same access to content and features.

Here are the main areas to focus on:

• Perceivability: Ensure everyone can perceive your app by providing alt text for images and maintaining sufficient color contrast for readability. Also, include text alternatives for multimedia content, like captions for videos, to support users with visual or hearing impairments.
• Operability: Make your app usable with a keyboard to support users who cannot use a mouse. Ensure all interactive elements are accessible via keyboard, and allow users enough time to complete tasks without timing out.
• Understandability: Keep your content simple and easy to navigate. Use concise language, consistent navigation patterns, and clear error messages to help users understand and fix mistakes quickly.
• Robustness: Ensure your app works across devices, browsers, and assistive technologies by using semantic HTML and ARIA labels. Structure content logically with proper headings and labeled inputs to support screen reader users.

Keeping these points in mind makes your app more inclusive and user-friendly for everyone!

Creating accessible apps

Thanks to React Aria, Marigold components come with built-in accessibility features, and we provide guidelines in the component documentation to help you follow best practices. However, it's important to remember that ensuring accessibility compliance when using Marigold components is a team effort. Accessibility is a shared responsibility, and everyone plays a part in making products inclusive for all.

Read on to learn more about how to ensure accessibility in your products and what is already taken care of by Marigold.

ARIA attributes

Marigold implements accessibility support following the WAI-ARIA specification, which defines semantics for UI controls to help assistive technologies like screen readers understand the purpose of DOM elements. When native HTML elements can’t be used for styling or if no native element exists, ARIA is applied to give presentational elements semantic meaning. This allows screen readers and other assistive technology to understand these elements and announce them properly to the user.

However, ARIA only specifies semantics, developers are responsible for implementing behaviors and interactions with JavaScript, using the ARIA Authoring Practices Guide to ensure proper keyboard interactions and accessibility.

Labeling

Marigold includes most of the necessary accessibility features by default, but there’s one key thing you need to add: a text label for each control. This label helps screen reader users understand the control they are interacting with.

For form elements like text fields, checkboxes, or dropdowns, it’s best to provide a visible label. Marigold will automatically link this label with the control so that assistive technologies can describe it correctly.

If a visible label isn’t needed or you’re using a control without a built-in label, you’ll need to use the aria-label or aria-labelledby properties to ensure it’s accessible. Marigold will usually show a console warning if both a visible label and an ARIA label are missing.

To illustrate how labeling works, see the following examples. In the code below, the <Button> only shows an icon (✖), so the aria-label provides a description (“Close”) for screen readers.

<Button aria-label="Close">✖</Button>

In the following example, the aria-labelledby attribute references both the ids of the heading (section-title) and the description (section-description). When the region is focused, a screen reader will announce both “Account Settings” and “Update your username, email, and password here,” providing clear context for the user.

<Headline level="2" id="section-title">Account Settings</Headline>
<Text id="section-description">
  Update your username, email, and password here.
</Text>
<div role="region" aria-labelledby="section-title section-description">
  {/* Form content goes here */}
</div>

Keyboard navigation

All components have built-in keyboard support, making it easy for users who can’t use a mouse or touch screen to navigate. But it also helps users who prefer using the keyboard to move around more quickly. The keyboard behavior follows the W3C’s ARIA Authoring Practices Guide, so it feels natural and familiar to users of common desktop systems.

Keyboard navigation is organized into tab stops, which you can move through using the Tab key (forward) and Shift + Tab (backward). A tab stop can be a single component like a button or text field, or a composite component like a listbox, radio group, or toolbar. Composite components act as one tab stop, with inner elements navigated using the arrow keys.

Check out the demo below to explore how keyboard navigation works. After clicking anywhere in the demo, use the arrow keys to move through the table, press space to select a row, and start typing to jump directly to a specific record.

Focus management

Focus support, like keyboard navigation, is crucial for users who can’t use a mouse or touch screen. It also benefits power users who prefer faster navigation without switching from the keyboard.

A key feature for keyboard users is the focus ring, a visual indicator showing which element is currently focused. This helps keyboard users know where they are on the page. The focus ring should only appear during keyboard navigation to avoid distracting mouse and touchscreen users.

Additionally, overlay elements like dialogs, popovers, and menus have special focus behavior to keep focus within them while open. Once they are closed, focus is returned to the element that initially opened them.

To test this, try the demo below using only your keyboard. Tab through all the elements to see how the focus remains contained within the dialog.

Dynamic content

Apps often dynamically update their user interface, such as when displaying search results or showing alerts. To make these updates accessible, ARIA live regions are used. They enable screen readers to automatically announce changes, ensuring users stay informed without needing to shift focus.

It’s the developer’s responsibility to make sure these dynamic content updates are announce by using ARIA live regions. The aria-live attribute controls how screen readers announce updates to dynamic content. It sets the priority for announcements, with three possible values: off, polite, and assertive.

• aria-live="polite" is the most commonly used setting. It ensures that updates are announced when the user is idle, making it ideal for non-urgent information, such as search results.
• aria-live="assertive" should be reserved for critical, time-sensitive updates. It immediately interrupts any ongoing announcements to grab the user’s attention, but because it can be disruptive, it should be used sparingly.
• aria-live="off" doesn’t prevent updates from being announced but limits them to when the element is focused or interacted with.

Choosing the correct aria-live setting is crucial to ensure the right balance between informing users and avoiding unnecessary interruptions. To learn more, check out the guide on MDN or explore the excellent article by Sara Soueidan.

Below is a demo showcasing the use of aria-live along with an aria-control. Changing the selection will update the UI, and the screen reader will announce this change to ensure accessibility.

Preview

Code

Giggle Grounds

Giggle GroundsWobbling StageChuckle BarnQuirky QuayHysterical HiveBelly Laugh BallroomSnicker SanctuaryThe Jester's JunctionPunning PavilionGuffaw Gardens

View details

Giggle Grounds

Outdoor Venue

Description

A charming open-air venue perfect for comedy shows under the stars, bringing laughter to every corner of Laughville.

Address

123 Main Street

Laughville

Capacity

500

Price

€1K to €5K

Test accessibility yourself

To truly understand the accessibility of your product, test it for yourself using a screen reader. Tools like NVDA, JAWS, and VoiceOver allow you to experience your product as a user who relies on assistive technologies would. Navigate through your app, interact with elements, and listen for how well the content is announced. This hands-on approach helps you catch accessibility issues early and ensure an inclusive experience for all users.

Below is a list of screen readers available for different devices.

macOS

• VoiceOver - Built-in screen reader for macOS.

iOS

• VoiceOver - Built-in screen reader for iPhones and iPads.

Windows

• Narrator - Built-in screen reader for Windows.
• NVDA (NonVisual Desktop Access) - Free, open-source screen reader for Windows.
• JAWS (Job Access With Speech) - A popular screen reader for Windows (commercial).

Ubuntu (Linux)

• Orca - Free, open-source screen reader included with the GNOME desktop environment.