new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Radix Primitives · all subjects

accessibility

34 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Radix Primitives reduce accessibility implementation time

Radix Primitives have significantly improved the accessibility standard in CodeSandbox's components. The team spends far less time discussing and implementing keyboard navigation, focus traps, and researching appropriate ARIA techniques for their components.

Alert Dialog WAI-ARIA pattern compliance

Alert Dialog adheres to the Alert and Message Dialogs WAI-ARIA design pattern as defined at https://www.w3.org/WAI/ARIA/apg/patterns/alertdialog.

Accordion accessibility conformance

Accordion adheres to the Accordion WAI-ARIA design pattern as defined at https://www.w3.org/WAI/ARIA/apg/patterns/accordion.

Collapsible accessibility pattern

Collapsible adheres to the Disclosure WAI-ARIA design pattern as documented at https://www.w3.org/WAI/ARIA/apg/patterns/disclosure.

Checkbox accessibility pattern

The Checkbox component adheres to the tri-state Checkbox WAI-ARIA design pattern as documented at https://www.w3.org/WAI/ARIA/apg/patterns/checkbox.

Dialog accessibility

Dialog adheres to the Dialog WAI-ARIA design pattern at https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal. It manages screen reader announcements with Title and Description components, automatically traps focus within modal, supports modal and non-modal modes, and Esc closes the component automatically.

Form accessibility pattern

Form follows the inline errors pattern: label and control are associated using the name provided on Form.Field, when one or more client-side error messages display they are automatically associated with their matching control and announced accordingly, and focus is moved to the first invalid control.

Hover Card accessibility

Hover Card is intended for sighted users only and will be ignored by screen readers. Content will be inaccessible to keyboard users.

Progress accessibility pattern

Progress adheres to the ARIA progressbar role requirements as defined at https://www.w3.org/WAI/ARIA/apg/patterns/meter.

Select accessibility pattern

Select adheres to the ListBox WAI-ARIA design pattern and the W3C Select-Only Combobox example.

Slider accessibility

Slider adheres to the Slider WAI-ARIA design pattern as documented at https://www.w3.org/WAI/ARIA/apg/patterns/slider-multithumb.

Tabs accessibility conformance

Tabs adheres to the Tabs WAI-ARIA design pattern as documented at https://www.w3.org/WAI/ARIA/apg/patterns/tabs.

React 18+ required for server-side ID generation

Primitives in React versions less than 18 rely on hydration for ids used in aria attributes, which causes a delay in time to interactive for screen reader users. To generate ids server-side and improve accessibility experience, upgrade to React 18 or later.

Server/client mismatch with IDs in React <18

In React versions less than 18, Radix Primitives use hydration for id generation to avoid server/client mismatch errors. This means screen reader users must wait for the JavaScript bundle to download and execute before ids in aria attributes are properly generated.

Radix Primitives follow WAI-ARIA authoring practices guidelines

Radix Primitives follow the WAI-ARIA authoring practices guidelines and are tested in a wide selection of modern browsers and commonly used assistive technologies.

ARIA and role attributes, focus management, and keyboard navigation are handled by Radix

Radix Primitives implement difficult accessibility details including aria and role attributes, focus management, and keyboard navigation. Users should be able to use the components as-is in most contexts and rely on functionality to follow the expected accessibility design patterns.

WAI-ARIA specifies semantics for common UI patterns

WAI-ARIA, published and maintained by the W3C, specifies the semantics for many common UI patterns that show up in Radix Primitives. It is designed to provide meaning for controls that aren't built using elements provided by the browser. For example, if you use a div instead of a button element to create a button, there are attributes you need to add to the div in order to convey that it's a button for screen readers or voice recognition tools.

WAI-ARIA authoring practices provide guidance for implementing component behaviors

The WAI-ARIA authoring practices provide additional guidance for implementing behaviors for various controls that come with Radix Primitives. Different types of components have expected behaviors; for example, a button element responds to certain interactions in ways that a div will not, so developers must reimplement those interactions with JavaScript.

WAI-ARIA provides specification for accessible names and descriptions

WAI-ARIA provides a specification for how to provide accessible names and descriptions to controls that are not built with native HTML form controls. For non-form control elements or custom controls like those provided by Radix Primitives, accessible names and descriptions must be provided according to WAI-ARIA specification.

Radix Primitives provide keyboard navigation according to WAI-ARIA practices

Many complex components like Tabs and Dialog come with user expectations on how to interact with their content using a keyboard or other non-mouse input modalities. Radix Primitives provide basic keyboard support in accordance with the WAI-ARIA authoring practices.

Focus management is implemented in Radix Primitives

Proper keyboard navigation and good labelling often go hand-in-hand with managing focus. When a user interacts with an element and something changes as a result, it is helpful to move focus with the interaction so that the next tab stop is logical depending on the new context of the app. For screen reader users, moving focus often results in an announcement to convey this new context, which relies on proper labelling.

Radix Primitives move focus based on user interactions

In many Radix Primitives, focus is moved based on the interactions a user normally takes in a given component. For example, in AlertDialog, when the modal is opened, focus is programmatically moved to a Cancel button element to anticipate a response to the prompt.

Components adhere to WAI-ARIA design patterns

Radix Primitives components adhere to the WAI-ARIA design patterns where possible. The library handles many difficult implementation details related to accessibility, including aria and role attributes, focus management, and keyboard navigation.

aria-controls referencing non-existent elements

Fixed triggers referencing non-existent elements via aria-controls when their content is removed from the DOM.

AccessibleIcon anatomy and import

AccessibleIcon is a utility that makes icons accessible. Import it from 'radix-ui' and use AccessibleIcon.Root as the containing component.

AccessibleIcon.Root props

AccessibleIcon.Root has one required prop: label (type: string). The label provides an accessible text description for the icon, which is visually hidden but announced to screen reader users, similar to alt text for img tags.

AccessibleIcon use case

Most icons have no built-in accessibility. The same visual icon symbol may mean different things (for example, a cross may mean 'close' or 'delete'). AccessibleIcon lets you provide a meaningful label to give the icon its intended meaning.

AccessibleIcon is built with Visually Hidden

AccessibleIcon is built using the Visually Hidden utility component.

AccessibleIcon has no visual difference

AccessibleIcon produces no visual difference in how the icon appears, but ensures it is announced correctly by screen readers.

VisuallyHidden purpose and use

The VisuallyHidden component hides content from the screen in an accessible way. It visually hides content while preserving it for assistive technology like screen readers. This is useful as an alternative to traditional labelling with aria-label or aria-labelledby.

Alert Dialog Title is accessible and announced

The Title part is an accessible title that is announced when the dialog is opened.

Alert Dialog Description is optional and accessible

The Description part is an optional accessible description that is announced when the dialog is opened. To remove the description entirely, remove the Description part and pass aria-describedby={undefined} to Content.

DropdownMenu accessibility - ARIA pattern

DropdownMenu adheres to Menu Button WAI-ARIA design pattern from https://www.w3.org/WAI/ARIA/apg/patterns/menu-button/ and uses roving tabindex to manage focus movement among menu items.

Icon Button accessibility recommendation

It is strongly recommended to include an aria-label or aria-labelledby prop on Icon Button components since they don't contain visible text. Screen readers rely on this label to announce the button's purpose to users.

Give your agent this brain