Thorough manual testing across the product, including with screen readers (H2)
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Feature
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- playwright, typescript
- Domain
- accessibility, ci-cd, cli, frontend, testing
Research direction
Complete the team orientation at usabl-dev.github.io/usabl/team-orientation.html, then use the human-tasks.md handoff catalogue entry H2 to identify the four surfaces and the hero bug and repair. Exercise the CLI, overlay, stop hook, PR and CI, onboarding path, and keyboard and screen reader interactions; record findings the automated layer missed. Done means every surface has been manually exercised and the hero bug and its repair are confirmed by ear and keyboard for v0.2.1.
Written by the indexing model from the issue text.
Description
usabl issues machine verdicts on accessibility. The automated layer can miss what a real user catches, so a human has to confirm the tool itself and the fixture behave.
Some screen reader review has already been done. It was a spot check, not broad enough to sign anything off on. What v0.2.x needs is a thorough manual pass across the whole product, with assistive technology as one part of it rather than the whole task.
- Why: a narrow spot check is not evidence that the product holds up. An accessibility product that has only been tested the easy way is the exact failure it exists to catch.
- Scope: all four surfaces (CLI, overlay, stop hook, PR and CI), the hero bug and its repair, and the onboarding path. Screen reader and keyboard-only passes are part of this, not the entirety of it.
- Owner: a teammate with Orca, plus at least one person doing a keyboard-only pass.
- Acceptance: every surface has been exercised by hand; the hero bug and its repair are confirmed by ear and by keyboard, not only by the gate; and every finding the automated layer missed is recorded.
- Target: v0.2.1.
Prerequisite for every human task: complete team-orientation first (usabl-dev.github.io/usabl/team-orientation.html), so the owner shares the result model, the four surfaces, and the claim boundary.
Source: human-tasks.md handoff catalogue (H2).
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 0
- Avg merge
- 2h 48m
- Merged PRs (30d)
- 8
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from usabl-dev/usabl
-
area: engine bug
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
Stop hook allows a stop on an unknown verdict, and the self-check prints IDLE for a null verdictOpenarea: assistants bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
area: engine bug security
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Overlay: browser context failures are counted per plugin, not per browser, and close is not sharedOpenarea: overlay bug
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
-
area: engine enhancement performance
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Similar issues
-
area:agent-view area:tui bug platform:macos
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
anthropics/claude-code#104558 ·
Maintainers usually reply within 1 day
-
updater
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
UniversityOfHelsinkiCS/oodikone#5141 ·
-
maintanance
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
inmanta/web-console#7606 ·
Maintainers usually reply within 1 day
-
bug skills
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
equinor/fusion-framework#5846 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 74/100