feat: fix a11y issues in icon component

[fateeand]

Fixing accessibility issues in icon component

Validation rules:

Validated using Playwright accessibility tests, Lighthouse tool, and manual checks including keyboard tab navigation and screen reader testing.

Full doc with rules

---

Checklist

• [N/A] Keyboard Navigation
  All interactive elements are fully operable via keyboard only, including buttons, inputs, menus, dialogs, sliders, drag-and-drop, tree views, multi-selects, and composite widgets. No traps or dead ends.

• [N/A] Focus Management
  Focus is visible, logical, moves in predictable order, trapped where necessary (modals/popovers), and restored after closing. Focus is perceivable in all interactive widgets.

• Semantics / ARIA

  • Semantic HTML is used correctly.
  • ARIA roles, states, and properties are applied only when needed.
  • All form fields, tables, and widgets (including autocomplete, tree selects, tree tables, drag-and-drop, sliders, and multi-selects) are properly labeled and accessible.

• [N/A] Color / Contrast

  • Text and interactive elements meet contrast requirements (≥4.5:1 normal text, ≥3:1 large text).
  • Focus and selection indicators are visually perceivable.
  • Color is not the only indicator of state.

• Screen Reader / Assistive Technology

  • All content, labels, and dynamic updates are perceivable via screen readers.
  • Live regions announce status messages, alerts, modals, notifications, and dynamic changes.
  • Interactive widgets provide proper announcements of selection and updates.

• Responsive & Zoom

  • Components function correctly and remain readable at all viewport sizes and up to 200% zoom, including mobile and touch devices.
  • Prefer em/rem units over px where scaling is required.

• [N/A] Error Handling

  • Errors are clearly identified visually and programmatically.
  • Form inputs use aria-describedby or aria-invalid for inline messages.
  • Instructions and suggestions are accessible.

• [N/A] Dynamic Content / Updates

  • Status updates, alerts, notifications, and modals use live regions.
  • Updates do not disrupt focus or user control unexpectedly.

• [N/A] Interaction Feedback / States

  • All interactive states (hover, focus, active, disabled, drag-and-drop, reordering, multi-select) are visually perceivable.

• [N/A] Authentication & Sensitive Actions

  • Inputs and actions involving sensitive data provide accessible instructions, feedback, and error messages.

• [N/A] Predictable & Controllable UI

  • Components behave consistently and predictably.
  • Popups, modals, autocomplete suggestions, drag-and-drop, and dynamic content allow user control.

---

Release notes:

• Fix a11y issues in icon component

[github-actions]

Coverage report for library

St.❔	Category	Percentage	Covered / Total
🔴	Statements	50.79%	3708/7301
🔴	Branches	46.34%	1657/3576
🔴	Functions	49.86%	704/1412
🔴	Lines	51.47%	3459/6720

Test suite run success

1323 tests passing in 37 suites.

Report generated by 🧪jest coverage report action from f798fc2

[github-actions]

Playwright test results

 94 passed

Details

 94 tests across 4 suites
 3 minutes, 19 seconds
 f798fc2
 For details, download the Playwright report

[korel-san]

@fateeand If I understand everything correctly, cps-icon now treats icons as decorative unless the new ariaLabel input is used. A consumer passing the standard aria-label="Search" attribute will have it removed/ignored by the host binding and the icon becomes aria-hidden="true".
If I'm right, then possible solution: support the native alias too, e.g. @input('aria-label'), and add a test for

[fateeand]

@korel-san I spent quite a bit of time thinking about a better approach. The solution I just pushed handles all supported ways of providing an accessible label to the component: native HTML attributes ([attr.aria-label], aria-label) as well as the ariaLabel input. Any of these can be used, and they now serve as the baseline for determining whether an icon should be treated as decorative or informative. Also updated the doc for ariaLabel input.

If e.g. consumers set role="img" but do not provide an accessible label, the role will be removed, which is a valid outcome. Similarly, if consumers set aria-hidden="false" but also provide an accessible label, aria-hidden will be overridden to true, since having both a visible label and aria-hidden enabled is contradictory.

Overall, the only requirement for consumers is to provide an aria label in any form to determine whether the icon should be treated as informative or decorative.