Development

Note

This section covers development accessibility. Developers should also be familiar with accessibility fundamentals, content, and design.

Overview

While our elements themselves were developed and tested with accessibility in mind, components can still be rendered inaccessible in how they are used. The HTML slotted within a component could be inaccessible, or CSS variables and part selectors could be used in a way that renders the component inaccessible. Therefore, you should always consider how your particular use of a component may impact its accessibility.

Icons and SVGs

Meaningful icons

Icons must adhere to the same accessibility rules as other images. When icons are used for interactivity (e.g., as buttons or links), they are considered meaningful, unless they are either accompanied by sufficient text within that interactive element, or the interactive element itself is already labeled (e.g., via aria-label). Visit our Content section for more information on image accessibility.

Avoiding icon fonts

Icon fonts are a nifty visual hack that you shouldn’t use.

• They put your site at risk of failing WCAG Success Criterion 1.1.1.
• Because assistive tech can’t reliably interpret them, the icons may be rendered “inaccurate, nonsensical, redundant, or unpredictable.”
• And if the font file doesn’t load (or is overridden by the user), the icons may not display properly for visual users.

To make icon fonts accessible, you often have to re-hack what’s already a hack. So best just to avoid them altogether.

SVG accessibility

Describing SVGs

As with any other image, SVGs that are loaded into your page via an <img> tag should include alt attributes. This attribute should be descriptive for meaningful SVGs and null for decorative SVGs. In addition, we recommend adding a role="img" attribute to the <img> element for SVGs: