Skip to content

A11y/usage bar progressbar - #237

Merged
tsouth89 merged 2 commits into
tsouth89:mainfrom
Vermitrude:a11y/usage-bar-progressbar
Aug 8, 2026
Merged

A11y/usage bar progressbar#237
tsouth89 merged 2 commits into
tsouth89:mainfrom
Vermitrude:a11y/usage-bar-progressbar

Conversation

@Vermitrude

@Vermitrude Vermitrude commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Adds role="progressbar" with aria-valuenow/aria-valuemin/aria-valuemax and a meaningful aria-label to the usage-bar__track div, per #76.

aria-valuenow and the label use the clamped pct (not rawPct), so the announced value never exceeds aria-valuemax={100}. Visible text still shows raw overshoot; flagging in case you'd rather these match.

Added UsageBar.test.tsx covering role, aria-valuenow, label with/without the label prop, and the clamp-to-100 case.

No visual change; only ARIA attributes added

Summary by CodeRabbit

  • Accessibility

    • Improved usage bar support for assistive technologies with progress indicators, value ranges, and percentage labels.
    • Ensured usage values above 100% are displayed safely.
  • Documentation

    • Added contribution guidance, including links to beginner-friendly issues and project guidelines.

@Vermitrude
Vermitrude requested a review from tsouth89 as a code owner August 7, 2026 14:27
@coderabbitai

coderabbitai Bot commented Aug 7, 2026

Copy link
Copy Markdown

Review Change Stack

Warning

Review limit reached

@tsouth89, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 58 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: d6d96d25-9000-479e-940d-f4bdfea5d5d8

📥 Commits

Reviewing files that changed from the base of the PR and between 7ec4f66 and 021b528.

📒 Files selected for processing (2)
  • apps/desktop-tauri/src/surfaces/tray/UsageBar.test.tsx
  • apps/desktop-tauri/src/surfaces/tray/UsageBar.tsx
📝 Walkthrough

Walkthrough

The PR adds ARIA progressbar semantics and coverage to UsageBar. It also adds README guidance for new contributors, including links to good-first-issue tickets and CONTRIBUTING.md.

Changes

UsageBar accessibility

Layer / File(s) Summary
Progressbar semantics and validation
apps/desktop-tauri/src/surfaces/tray/UsageBar.tsx, apps/desktop-tauri/src/surfaces/tray/UsageBar.test.tsx
UsageBar now exposes progressbar values and accessible labels. Tests cover labeled and unlabeled bars, value bounds, and clamping above 100%.

Contributor guidance

Layer / File(s) Summary
Contributor onboarding guidance
README.md
The README links contributors to good-first-issue tickets and CONTRIBUTING.md.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related issues

Possibly related PRs

Suggested reviewers: tsouth89, finesssee

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly identifies the main change: adding accessibility progressbar semantics to the usage bar.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
apps/desktop-tauri/src/surfaces/tray/UsageBar.test.tsx (1)

43-50: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Assert that the visible percentage stays raw.

The overshoot test checks only the clamped ARIA value and label. For usedPercent: 140, the visible percentage should remain 140% while aria-valuenow remains 100.

Suggested assertion
     expect(track).toHaveAttribute("aria-label", "Session usage: 100%");
+    expect(screen.getByText("140%")).toBeTruthy();
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/desktop-tauri/src/surfaces/tray/UsageBar.test.tsx` around lines 43 - 50,
Extend the overshoot test for UsageBar with an assertion that the visible
percentage remains the raw 140%, while preserving the existing aria-valuenow and
aria-label assertions at 100%.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@apps/desktop-tauri/src/surfaces/tray/UsageBar.test.tsx`:
- Around line 43-50: Extend the overshoot test for UsageBar with an assertion
that the visible percentage remains the raw 140%, while preserving the existing
aria-valuenow and aria-label assertions at 100%.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: acb621a8-2c7f-4263-b0a5-addde9e83f62

📥 Commits

Reviewing files that changed from the base of the PR and between 9a82e0b and 7ec4f66.

📒 Files selected for processing (3)
  • README.md
  • apps/desktop-tauri/src/surfaces/tray/UsageBar.test.tsx
  • apps/desktop-tauri/src/surfaces/tray/UsageBar.tsx

Signed-off-by: cromewar <c.akachukwu.c@gmail.com>
@Vermitrude
Vermitrude force-pushed the a11y/usage-bar-progressbar branch from 7ec4f66 to 34da593 Compare August 7, 2026 14:35

@slegarraga slegarraga left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ARIA progressbar semantics are correct: aria-valuenow stays within 0-100, the labels are meaningful with and without label, and the tests cover the clamp. One coordination note: this PR also carries README contributing changes that overlap with #236, so it may be worth keeping the README change in one PR. Also consider asserting the visible raw 140% in the overshoot test, since that is the deliberate behavior. Not blocking.

@tsouth89

tsouth89 commented Aug 8, 2026

Copy link
Copy Markdown
Owner

Thanks for flagging this — let's keep aria-valuenow clamped (the ARIA spec requires it never exceed aria-valuemax), but swap the aria-label to use rawPct instead of pct. Right now at 140% usage, sighted users see "140%" in the visible text while a screen reader announces "100%" — silently hiding the over-limit state, which is exactly the kind of thing this app tries to be truthful about elsewhere. One-line change in the label template, plus updating the third test case's expected label. Once that's in, happy to merge.

aria-valuenow correctly stays clamped to aria-valuemax per the ARIA spec,
but the label was built from the same clamped value. At 140% usage, sighted
users saw "140%" in the visible text while a screen reader announced only
"100%" — silently hiding the over-limit state from exactly the audience that
needs it most.
@tsouth89

tsouth89 commented Aug 8, 2026

Copy link
Copy Markdown
Owner

Sorry for the delay getting back to you — this turned out to be a one-line fix so we just pushed it to your branch directly rather than bouncing it back for another round. Thanks for catching the ARIA semantics gap, merging now.

@tsouth89
tsouth89 merged commit 765676b into tsouth89:main Aug 8, 2026
5 of 6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants