Hi,
I have a question/suggestion regarding the recommended pattern for icon-only buttons in the design system.
The current documentation states that icon-only buttons can use title, aria-label, or a Tooltip to provide an accessible name, and the examples primarily use aria-label:
<button
class="ds-button"
data-icon="true"
data-variant="primary"
type="button"
aria-label="Delete"
>
<svg aria-hidden="true"></svg>
</button>
This is WCAG compliant and works well with screen readers.
However, we recently encountered cases where third-party tooling did not recognise the accessible name because the button contains no actual text node in the DOM.
That made me wonder whether the design system should more explicitly prefer native HTML semantics over ARIA-only naming patterns when practical, for example for icon-only buttons:
<button type="button">
<svg aria-hidden="true"></svg>
<span class="ds-sr-only">Delete</span>
</button>
Potential advantages:
- Native HTML accessible name from content
- Less reliance on ARIA for core semantics
- Better compatibility with analytics/testing/crawling tools
- More robust semantics directly in the DOM
- Aligns with the general principle of preferring native HTML semantics before ARIA when possible
I understand that consumers of the design system are free to implement this differently themselves. However, many developers will naturally follow the examples and recommended patterns shown in the documentation, especially in a public-sector design system intended for broad reuse across teams and platforms.
I am not suggesting that the current aria-label approach is wrong or inaccessible. aria-label is valid and widely used.
The question is more about long-term robustness and interoperability for a public-sector design system intended for broad reuse across many platforms, CMS-es and tooling ecosystems.
I also wonder whether the current wording around title and aria-label could unintentionally imply that these are equally recommended alternatives, even though they have somewhat different characteristics and tradeoffs in terms of accessibility semantics and interoperability.
Has the tradeoff between ARIA-only naming and native HTML text content been discussed previously in the design system?
If this is considered relevant, perhaps the accessibility guidance/documentation for the Button component could also clarify when native HTML text content (for example visually hidden text) may be preferable.
Hi,
I have a question/suggestion regarding the recommended pattern for icon-only buttons in the design system.
The current documentation states that icon-only buttons can use
title,aria-label, or aTooltipto provide an accessible name, and the examples primarily use aria-label:This is WCAG compliant and works well with screen readers.
However, we recently encountered cases where third-party tooling did not recognise the accessible name because the button contains no actual text node in the DOM.
That made me wonder whether the design system should more explicitly prefer native HTML semantics over ARIA-only naming patterns when practical, for example for icon-only buttons:
Potential advantages:
I understand that consumers of the design system are free to implement this differently themselves. However, many developers will naturally follow the examples and recommended patterns shown in the documentation, especially in a public-sector design system intended for broad reuse across teams and platforms.
I am not suggesting that the current
aria-labelapproach is wrong or inaccessible.aria-labelis valid and widely used.The question is more about long-term robustness and interoperability for a public-sector design system intended for broad reuse across many platforms, CMS-es and tooling ecosystems.
I also wonder whether the current wording around
titleandaria-labelcould unintentionally imply that these are equally recommended alternatives, even though they have somewhat different characteristics and tradeoffs in terms of accessibility semantics and interoperability.Has the tradeoff between ARIA-only naming and native HTML text content been discussed previously in the design system?
If this is considered relevant, perhaps the accessibility guidance/documentation for the Button component could also clarify when native HTML text content (for example visually hidden text) may be preferable.