Accessibility

A tag is a compact, static label — it categorises or highlights content and carries no interaction of its own, so it follows no WAI-ARIA pattern; it meets WCAG 2.1 AA by leaning on plain text semantics. An accessible tag reads the same whether the user sees it or hears it: its label is real text, any decorative icon stays out of the assistive-technology tree, and its status is never carried by colour alone.

The styleguide ships no dismissible tag, no selected state, and no interactive affordance of any kind. Don’t bolt a close button or a click handler onto a tag — if the user is meant to act on it, reach for a component built for interaction.

For designers

• The label text against its fill, and every fill/border pairing, must maintain accessible contrast. Each of the seven colours is defined twice — once per surface — so both halves need checking, not just the one you happen to be designing on. Source: WCAG 1.4.3 Contrast (Minimum).
• The colour pairs are supplied per brand, so contrast is a per-brand property. Don’t assume a combination that passes on Toyota passes on Lexus or KINTO. KINTO is in preview, and its default pair is currently known not to meet AA.
• Status must never be conveyed by colour alone — pair each variant (.is-success, .is-danger, .is-info, .is-warning) with text or an icon so the meaning survives for colour-blind and monochrome users. A meaningful icon must not merely duplicate the label; a decorative one carries no meaning at all. Source: WCAG 1.4.1 Use of Color.
• A tag adapts to the surface it sits on rather than being specced light or dark, so it stays legible inside a dark hero or a nested contrast region without adjustment. What it does not do is adapt to an arbitrary background image or brand colour placed behind it — that pairing is untested.
• Tags use no animation or flashing and introduce no visual noise, so they raise no motion concern.

For developers

A plain tag is just text inside a .tng-tag container — it takes no role and no interactive semantics, and a screen reader announces its label like any other text. One decision shapes whether that stays accessible, and it’s wired per element in the Labelling elements section below: whether the leading icon is decorative. Beyond that, one rule holds everywhere — never let a status variant’s colour be the only signal of meaning.

There is no Focus order section here because a tag contributes no tab stops at all. It holds no focusable content, so it never enters the tab sequence.

Labelling elements

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

Tag / Label

The .tng-tag container carries no role — it is presentational. Its accessible name is its own text content (the <span> label), so keep that label short and self-describing; it announces as plain text with no added ARIA.

Decorative icon

The leading <i class="tng-icon"> is decorative: mark it aria-hidden="true" so it is removed from the accessibility tree and never doubles the label. If an icon genuinely adds meaning the label doesn’t, surface that meaning in text rather than leaving it on a hidden icon.

Source: WCAG 4.1.2 Name, Role, Value.

Content / Copy guidelines

Tags should use short, descriptive and consistent labels. The tone should be neutral, informative, and suitable for metadata or UI contexts.

• Text: Mandatory. One to three short words (e.g. “Hybrid”, “Low stock”, “Special edition”).
• Capitalisation: Sentence case (e.g. “In progress”).
• Max length: Aim for 18 characters or fewer to ensure layout stability.
• Icons: Optional. Should visually support the text meaning, not repeat it.
• Do not use emojis or punctuation in Tag labels.
• Avoid using verbs in a Tag label — a tag names a state, it does not ask for an action.