| Category |
Value |
| Labels |
accessibility, a11y, frontend, material-ui, wcag |
| Project |
HRM Core Client |
| Assignee |
@frontend-lead |
Description
Improving front-end accessibility is critical for expanding our user base and meeting legal compliance standards (WCAG). For a highly visual, real-time application like our HRM dashboard, adherence to accessibility guidelines ensures users with screen readers, keyboard-only navigation, or low vision can effectively perceive data, control the workout, and navigate the application.
Given our use of Material-UI and complex dashboard components, we must prioritize fixes for keyboard focus management and semantic ARIA labeling for dynamic content.
I. Perceivable (Color, Text Alternatives, Semantics)
Ensuring all users can perceive information regardless of sensory challenges.
Tasks:
II. Operable (Keyboard and Focus Management)
Guaranteeing that all functionality is reachable and usable via a keyboard.
Tasks:
III. Understandable (ARIA and Status Updates)
Ensuring the application is readable and predictable, especially for screen reader users.
Tasks:
Next Step: The most immediate and high-impact accessibility fix for a real-time dashboard is Task III.A: Implementing ARIA Live Regions for critical state changes (Tabata phase, connection status). In which file will you begin implementing the ARIA Live Regions and announcing critical state changes?
accessibility,a11y,frontend,material-ui,wcagDescription
Improving front-end accessibility is critical for expanding our user base and meeting legal compliance standards (WCAG). For a highly visual, real-time application like our HRM dashboard, adherence to accessibility guidelines ensures users with screen readers, keyboard-only navigation, or low vision can effectively perceive data, control the workout, and navigate the application.
Given our use of Material-UI and complex dashboard components, we must prioritize fixes for keyboard focus management and semantic ARIA labeling for dynamic content.
I. Perceivable (Color, Text Alternatives, Semantics)
Ensuring all users can perceive information regardless of sensory challenges.
Tasks:
A. Color Contrast Ratio: Audit the color palette (defined in
lib/theme.ts) to ensure all foreground text (especially within dashboard tiles like<HrTile />and<TimerDisplay />) meets a minimum 4.5:1 contrast ratio against its background, particularly for the low-contrast or colored heart rate zones.B. Image and Icon Alternatives: Ensure all functional images and icons (e.g., the speaker/mute icons, Spotify controls, and navigation elements) have descriptive
alttext or Material-UI'saria-labelattribute if they are M-UI icons.C. Meaning Conveyed by Color Alone: Verify that the heart rate zone color coding (e.g., green for fat burn, red for cardio) is not the only way to determine the user's current zone. There must be accompanying text (e.g., "Zone 3 - Cardio") or an icon/pattern.
II. Operable (Keyboard and Focus Management)
Guaranteeing that all functionality is reachable and usable via a keyboard.
Tasks:
A. Consistent Tab Order: Audit the focus order across the application, especially the control panel (
app/client/control/ControlPanel.tsx). The logical flow should be preserved without unexpected jumps.B. Visible Focus Indicators: Although the VRT snapshots indicate focus testing exists, ensure the native browser focus ring is highly visible (e.g., a thick, high-contrast outline) for all interactive elements, particularly custom buttons and sliders in
<TimerControls />and<SpotifyControls />.C. Custom Element Role Mapping: For any non-native HTML elements or M-UI components customized to behave like buttons, ensure they have
role="button"and are fully operable with both Space and Enter keys.III. Understandable (ARIA and Status Updates)
Ensuring the application is readable and predictable, especially for screen reader users.
Tasks:
A. Real-Time Status Annunciations (ARIA Live Regions): The core of the application is dynamic state (HR updates, Tabata phase changes:
WORK,REST). Screen reader users need these critical changes announced.<HrTile />,<TimerDisplay />) in anaria-live="polite"region. When the Tabata phase changes (e.g., "Work" to "Rest"), the new phase must be announced to the screen reader.B. Descriptive ARIA Labels: Add
aria-labeloraria-labelledbyto complex controls, such as the volume slider and the Tabata timer steppers, so their purpose is clear out of context.C. Form Labeling: Ensure all input fields (e.g., mock streamer input, future HRM settings) are correctly associated with a visible
<label>element using thehtmlForattribute or M-UI's standard labeling patterns.Next Step: The most immediate and high-impact accessibility fix for a real-time dashboard is Task III.A: Implementing ARIA Live Regions for critical state changes (Tabata phase, connection status). In which file will you begin implementing the ARIA Live Regions and announcing critical state changes?