Button / Accessibility

Relevant WCAG Success Criteria

2.4.7 Focus Visible (A)

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

W3C article: Understanding Success Criterion 2.4.7

2.4.7 and the button-component

  • The Button uses shadow (via the Tailwind ring) util to indicate the focus state
  • If you customize the colors of the button, also make sure that the focus ring, and the background color also have a minimum of 3:1 contrast ratio
  • Related: see "1.4.11: Non-text Contrast" below
  • There is a draft for WCAG 2.2 with an enhanced version of this criterion (see 2.4.11: Focus Visible (Enhanced))
2.5.3: Label in Name (A)

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

A best practice is to have the text of the label at the start of the name.

Label: Visible text identifying the control immediately above, inside, or beside the element.

Name: The programmatic name / Accessible Name. Examples include aria-label and alt.

W3C article: Understanding 2.5.3

2.5.3 and the button-component

Example 1: Failure due to label and name mismatch

In the following example the visual textual label Go does not match the programmatic name Search Norsk Tipping.

The "disconnect" lies in that users sees the readable text "Go", but the screen reader reads out "Search Norsk Tipping". This can be confusing on its own, but it can also place an extra cognitive burden on speech input users that cannot use what they see to give speech-commands (e.g. "Search Norsk Tipping" in this case).

One solution in this (contrived) example, is to simply consolidate the programmatic name and the visible label (see A below) or at least have the text of the label in the start of the programmatic name (see B below):

Example 2: Failure due to mismatch caused by .sr-only-usage

This is the same as example 1, the visible text label (Download agreement) does not match the programmatic name (Download customer agreement).

Example 3: Not applicable on non-textual label

In this example the plus-sign (+) is not considered a label (or a "mathematical expressions/formula"), because it is used in a symbolic manner. Consequently, the programmatic name (here, the aria-label) need not "pair" with the label (here, the +-character). The same would be true if the plus-sign was represented in an image (e.g. an icon).

<SquareButton
aria-label='Increment count'
>
+
</SquareButton>
4.1.2: Name, Role, Value (A)

For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

W3C article: Understanding Success Criterion 4.1.2

4.1.2 and the button-component

If you override the component (via the render-prop) and provide a custom element, make sure that this element is a user interface control (e.g. a button or an anchor-tag) or use an appropriate role to denote it (but please use semantic elements where you can!).

1.4.11: Non-text Contrast (AA)

The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):

User Interface Components: Visual information required to identify user interface components AND STATES, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;

Graphical Objects: Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

W3C article: Understanding Success Criterion 1.4.11

1.4.11 and the button-component

  • This criterion must be verified where the button is used since the contrast is calculated from the background surroundings of the button.
  • If the button have text (or icons) that meets the "1.4.3: Contrast Minimum" criterion, the background color of the button need not have a minimum of 3:1 contrast ratio
  • Take extra care to check the contrast ratio if you use transparent/semi-transparent background on top of images / non-uniform backgrounds etc.
  • Also see 2.4.7: Focus Visible above

Tip: Color contrast checker tool (external link).

3.2.4 Consistent Identification (AA)

Components that have the same functionality within a set of Web pages are identified consistently.

W3C article: Understanding Success Criterion 3.2.4.

3.2.4 and the button-component

When labeling buttons it is important to do so consistently for the same functionality across our pages. For example, avoid using "Find/Finn" if "Search/Søk" is used in other places.

2.5.5: Target Size (AAA)

The size of the target for pointer inputs is at least 44 by 44 CSS pixels (...).

W3C article: Understanding Success Criterion 2.5.5.

2.5.5 and the button-component

  • The size=normal corresponds to a height of 44px.
  • The height for size=small is less than the required target. Check the exceptions to make sure that this is OK in your special use-case.
  • Make sure that you check the target size when you modify the button style: font-size, padding, border-width and height/width (of course)
  • The width of the button can be less than 44px depending on the content given the button

This guide is based on version: 4.8.0