feat: fix a11y issues in progress linear component

[fateeand]

Fixing accessibility issues in progress linear 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

---

Playwright axe-core validation results:

State before:

Notification	aria-roles
Progress linear	-

---

State after:

Notification	aria-roles
Progress linear	✅

---

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.

• 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 progress linear component

[github-actions]

Coverage report for library

St.❔	Category	Percentage	Covered / Total
🔴	Statements	47.9%	3545/7401
🔴	Branches	43.56%	1590/3650
🔴	Functions	46.97%	666/1418
🔴	Lines	48.44%	3303/6819

Test suite run success

1216 tests passing in 34 suites.

Report generated by 🧪jest coverage report action from 236c2d7

[github-actions]

Playwright test results

 92 passed

Details

 92 tests across 4 suites
 3 minutes, 8 seconds
 236c2d7
 For details, download the Playwright report

[korel-san]

@fateeand same here, not sure I'm right, but it seems aria-label="Uploading file" from consumers is overwritten by the ariaLabel() signal default, so the accessible name becomes "Loading". So we need to add an aria-label input alias, or explicitly document and test only ariaLabel