Accessibility

The Feature List is static content: the styleguide owns the layout and typography, and leaves the semantics, the accessible naming of any info button, and the behaviour behind it to you. An accessible feature list keeps the label and its value clearly related, reads top to bottom in the order it appears, survives text resizing and zoom without clipping, and never leans on colour alone to signal which line is the value. It meets WCAG 2.1 AA.

For designers

• The label and the data must both meet minimum colour contrast in light and dark themes — the label is deliberately muted, so check it rather than assuming. Source: WCAG 1.4.3 Contrast (Minimum).
• The info icon must meet the same contrast minimum in both themes.
• Never let the label/data hierarchy ride on colour or weight alone — the wording has to make clear which is the attribute and which is the value. Source: WCAG 1.4.1 Use of Color.
• The reading order must follow the visual order, top to bottom.
• The list must tolerate text resizing without clipping, overlap, or loss of information, and stay legible and adequately spaced at supported zoom levels. Source: WCAG 1.4.4 Resize Text.
• Where an info icon is used, it needs an accessible name that says what kind of information it reveals — not a bare “info”.
• Optional rows that are hidden must be hidden properly, so they reach neither the screen reader nor the keyboard.

For developers

The list ships as a <ul> of <li> items, each stacking a label and a data line. Because the component sets list-style: none, add role="list" on the container — Safari with VoiceOver drops the implicit list role when the markers are removed, and with it the item count and position. The rows themselves are static text and take no focus.

Keep the relationship between the two lines explicit. The markup above pairs them by containment, which is enough for a visual reader but tells assistive technology nothing about which line describes which. Where that pairing matters — a specification table people navigate rather than skim — use a description list instead: the classes are presentational, so they apply just as well to <dl> / <dt> / <dd>.

<dl class="tng-feature-list">
  <div class="tng-feature-list-item">
    <dt class="tng-feature-list-label">Fuel consumption</dt>
    <dd class="tng-feature-list-data">43.4 - 45.5 (l/100 km)</dd>
  </div>
</dl>

Fuel consumption

43.4 - 45.5 (l/100 km)

Avoid truncating values — a clipped specification is a loss of information, so let long values wrap instead. If you hide optional rows, remove them from the DOM or use hidden, rather than visually hiding them where they stay reachable by keyboard and screen reader.

The info button

The styleguide ships the info button as a visual affordance with no behaviour attached, so everything that makes it accessible is yours to add. It is a real <button>, so it is focusable and keyboard-operable already, and the glyph inside is aria-hidden="true" — but an unwired button that announces itself and then does nothing is worse than no button. Either wire it up or leave it out.

When you do wire it up, give it an accessible name describing what it reveals (“How fuel consumption is measured”, not “info”), reveal the explanation with Popover rather than a bespoke tooltip, and make sure the revealed content is announced — associate it with aria-describedby, or manage focus into it — so the interaction isn’t silent for a screen reader.

Two constraints worth checking against your own layout:

• Touch target. is-xs renders a 22 px button, which is under the 24 × 24 px minimum. It can still pass via the spacing exception when no other target falls within a 24 px circle around it — but in a dense list, two info buttons on adjacent rows can easily breach that. Step up a size, or space the rows, where the buttons sit close together. Source: WCAG 2.5.8 Target Size (Minimum).
• Focus visibility. The button keeps the standard focus ring; don’t suppress it, and check it against both the neutral and contrast surfaces. Source: WCAG 2.4.7 Focus Visible.

Keyboard interaction

The list itself is not interactive. Only the optional info buttons take focus.

Key	Action
Tab / Shift + Tab	Move focus between info buttons
Enter / Space	Activate the focused info button

Focus order

Focus moves through the info buttons in document order — down the list, and within an item from the label’s button to the data’s button. The text takes no focus, and right-to-left preserves this logical order while mirroring the layout.

• Fuel consumption

  43.4 - 45.5 (l/100 km)

• Boot capacity

  580 LITRES

12

1. 1First info button
2. 2Second info button

Labelling elements

Give every element the role, name, and state assistive technology needs.

List container

A <ul> with an explicit role="list", since the styling removes the markers. It needs no aria-label when the surrounding heading already names the block — a redundant label only adds noise. Use <dl> instead when the label/value pairing needs to be exposed rather than implied.

Label

Plain text naming the attribute. It carries no role of its own, so it must read as a self-describing attribute name — or become a <dt> when you need the pairing exposed.

Data

Plain text carrying the value and its unit together, so the fact is complete when read on its own — or a <dd> in the description-list form.

Info button

An icon-only <button> with no visible text, so give it aria-label describing what it reveals. The icon-info glyph is aria-hidden="true", so the button announces as its label alone. Only include it when it actually does something.

Source: WCAG 4.1.2 Name, Role, Value.