agentsclimarketplace

Manual a11y audit

Skill almasumdev/awesome-mobile-accessibility-agent-skills/.github/skills/testing/manual-a11y-audit

Agent skills for building accessible mobile apps across platforms (a11y, screen readers, contrast, motion).

Install
npx -y skills add almasumdev/awesome-mobile-accessibility-agent-skills --skill manual-a11y-audit

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Heuristic audit playbook, user-testing approach, and issue-logging conventions for mobile accessibility. Use this before every major release or at least quarterly on the main flows.

SKILL.md

5.7 KB, as published. Nobody here has run it

Manual Accessibility Audit

Instructions

Automated checks cover the mechanics; manual audits cover experience. This skill is the playbook for a repeatable audit you can run in a day per feature.

1. Scope the Audit

  • Pick one primary user flow (onboarding, checkout, core task).
  • Define success: "a blind user can complete checkout without sighted help in under 3 minutes".
  • Test on real hardware, not only simulators. A wired keyboard + a real switch + TalkBack on a mid-range Android device.

2. Environments to Test

Run the flow once under each of the following configurations. Log every issue as you go.

#Configuration
1Default
2VoiceOver on (iOS)
3TalkBack on (Android)
4Dynamic Type = Accessibility XXL / Font scale largest
5Dark mode
6Increase Contrast / High Contrast Text
7Reduce Motion enabled
8External Bluetooth keyboard only (no touch)
9Switch Control / Switch Access (single-switch auto scan)
10Voice Control / Voice Access
11RTL locale (Arabic or Hebrew test build)
12Slow 3G + flaky network (to observe focus after loading)

3. Heuristics Checklist (Per Screen)

Perceivable

  • Every image/icon has a label or is hidden.
  • Contrast passes 4.5:1 (text) and 3:1 (UI).
  • No info conveyed by color alone.
  • Text reflows at 200% without loss.

Operable

  • Every action reachable without gesture.
  • Touch targets >= 44/48.
  • Keyboard Tab traversal reaches every control.
  • Visible focus indicator, 3:1 contrast.
  • Escape / back always closes modals.

Understandable

  • Labels describe purpose, not appearance.
  • Errors state what's wrong + how to fix.
  • Navigation consistent across screens.

Robust

  • VoiceOver + TalkBack announce role + state + value correctly.
  • Live regions fire at the right moments.
  • No AT crashes on complex screens.

4. Scripted Walkthroughs

For each primary flow, write a short script:

Scenario: Screen reader checkout (iOS, VoiceOver)
Given the cart has 2 items
When I swipe from the top of the cart screen
Then I hear "Cart. Heading." as the first focusable element
 And each item reads "<Title>, <Quantity>, <Price>"
 And the Checkout button is reachable within 6 right-swipes
 And tapping it announces "Payment. Heading."

Run the script literally. Any deviation is a bug.

5. Logging Issues

Use a consistent template — paste into the tracker verbatim.

Title: [A11Y][iOS][VoiceOver] Cart quantity not announced on increment

Severity: Blocker | Major | Minor | Cosmetic
Affected AT: VoiceOver on iOS 18, Dynamic Type XL
Device: iPhone 15, iOS 18.1
Flow: Cart → Increment quantity

Steps:
1. Enable VoiceOver
2. Navigate to cart with 1 item
3. Swipe right until "Increase quantity" is focused
4. Double-tap to activate

Expected: VoiceOver announces the new quantity, e.g. "2".
Actual:   Focus remains; nothing is announced.

WCAG:    4.1.3 Status Messages (AA)
Fix:     Wrap quantity Text with accessibilityLiveRegion(.polite)
         or post announcement via UIAccessibility.post.
Evidence: screen_recording.mov (attached)

Include WCAG reference and a concrete fix suggestion — this keeps the ticket actionable.

6. User Testing

Heuristics plus real users:

  • Recruit at least 2–3 participants per release using AT you have not tested internally (e.g., switch user, low-vision user).
  • Pay participants at market rate (e.g., Fable, AccessWorks networks).
  • Observe; do not help. Record (with consent) for the team to rewatch.
  • Triangulate: if one participant struggles, investigate. If two do, it's a blocker.

7. Prioritization

  • Blocker: the flow cannot be completed with the AT. Fix before release.
  • Major: flow completes but with significant friction or confusion. Fix within the release train.
  • Minor: friction, easily recovered. Fix in next cycle.
  • Cosmetic: a11y polish (redundant label, etc.). Backlog.

8. Rotating Audit Cadence

  • New feature: audit before release.
  • Core flows: audit quarterly against the full matrix above.
  • OS upgrade (iOS / Android major): re-audit known-affected screens within a week of developer preview.

9. Accessibility Review in PR

Beyond tickets, add an "A11y" line to every PR description:

### A11y
- VoiceOver: read on iOS 18 Simulator, focus order correct.
- TalkBack: verified on Pixel 7, Android 14.
- Dynamic Type XXL: no clipping.
- Reduce Motion: transitions crossfade.
- Remaining gaps: none / #1234.

10. Dashboard and Trends

Track:

  • Open a11y bugs by severity and age.
  • Automated violations per build.
  • % of features with a manual audit in last 90 days.

Publish weekly. Regression trends are easier to argue than individual tickets.

11. Common Pitfalls

  • "It works in Simulator" — many AT bugs appear only on real devices.
  • Testing only with VoiceOver on iOS — TalkBack behaves differently.
  • Skipping the large Dynamic Type pass.
  • Auditing only happy paths — errors and empty states are where a11y breaks.
  • Reporting issues without reproduction steps or a WCAG mapping.

Checklist

  • Each release-critical flow audited on both iOS and Android with AT.
  • All 12 environments in §2 exercised for at least one flow.
  • Issues logged with severity, WCAG ref, and fix suggestion.
  • User testing scheduled with AT users at least once per quarter.
  • PR template includes an A11y section.
  • Dashboard tracks open a11y debt and trends.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.