manual-testing — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited manual-testing (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Canonical source:examples/MANUAL_ACCESSIBILITY_TESTING_GUIDE.mdinmgifford/ACCESSIBILITY.mdThis skill is derived from that file. When in doubt, the example is authoritative.
Apply these rules when planning or reviewing manual accessibility testing.
| Level | Meaning |
|---|---|
| Critical | Issue completely blocks a core task for one or more disability groups |
| Serious | Significantly impairs access; workaround unreasonable to expect |
| Moderate | Creates friction; workaround exists and is not too burdensome |
| Minor | Best-practice gap; marginal impact on access |
Manual testing reveals issues that automated tools cannot detect, including:
Perform manual testing:
Getting started: test keyboard-only first (easiest entry point), then learn basic screen reader commands for your platform. Practice on familiar websites before testing your own. Focus on one component or flow at a time.
Every interactive element must be reachable and operable by keyboard alone.
Steps:
Key shortcuts to verify:
| Key | Expected behaviour |
|---|---|
| Tab | Move focus forward |
| Shift+Tab | Move focus backward |
| Enter | Activate links, buttons, submit forms |
| Space | Activate buttons, toggle checkboxes |
| Arrow keys | Navigate within components (menus, tabs, radio groups) |
| Escape | Close dialogs, cancel operations |
| Home / End | Jump to start/end of component |
Component-specific checks:
appear and are announced; Enter submits; can cancel/reset if applicable
focus moves appropriately after activation
selected value announced
closes (unless critical); focus returns to trigger on close
patterns; arrow keys and Home/End work as documented; state changes are clear
Recommended platform pairings:
Basic test procedure:
<nav>, <main>, <header> identified?Component-specific screen reader checks:
aria-hidden); informativeimages have descriptive alt text; complex images have longer descriptions
"click here"); external links/new windows indicated
disabled state announced
instructions/hints, error messages, and success messages all announced
states and progress communicated
row headers announced with each cell; table purpose clear (caption or aria-label)
announced (e.g., "selected", "expanded"); instructions provided for complex widgets
For each interactive element, verify:
Why automated tools miss this: forced colors is triggered by an OS-level setting that replaces all author-defined colors with a constrained system palette. Automated tools cannot simulate the OS-level override, detect which elements become invisible when custom colors are stripped, or assess whether focus indicators/icons/custom controls survive the substitution.
How to enable:
Alt+Left Shift+Print Screen)activeabout:config → ui.forcedColors → set to 1 (-1 to reset)Always verify with real OS settings before release — DevTools emulation is convenient but not fully equivalent.
What to look for:
CanvasText on Canvas)form fields have visible borders
outline is preserved; box-shadow may not be)currentColor for fill/stroke)toggle state shown via text/ARIA/outline, not color alone
fields marked with text or icons, not only color
Common fixes:
| Issue | Fix |
|---|---|
box-shadow focus ring disappears | Replace with outline |
| SVG icon invisible | Use currentColor for fill/stroke |
| Custom checkbox invisible | Add visible border; use forced-color-adjust override |
| Error marked by color only | Add icon, text label, or aria-invalid |
Input invisible (border: none) | Add border: 1px solid ButtonBorder in @media (forced-colors: active) |
| Background image removed | Add visible text, caption, or aria-label |
CSS system color keywords for patching:
@media (forced-colors: active) {
:focus-visible {
outline: 3px solid Highlight;
outline-offset: 2px;
}
.custom-checkbox::before {
forced-color-adjust: none;
border: 2px solid ButtonBorder;
background-color: ButtonFace;
}
.custom-checkbox[aria-checked="true"]::before {
background-color: Highlight;
}
}Relevant keywords: Canvas, CanvasText, ButtonFace, ButtonText, ButtonBorder, Highlight, HighlightText, LinkText, VisitedText, GrayText.
Use forced-color-adjust: none only as a last resort — it opts the element out of forced colors entirely and can negate the user's accessibility settings.
Test with: WebAIM Contrast Checker, browser DevTools. Test light and dark color modes separately.
These are two distinct success criteria with different tests. A page can pass one and fail the other, and horizontal scrolling at 200% zoom is not automatically a failure of either.
SC 1.4.4 Resize Text (AA): content must be resizable up to 200% without loss of content or functionality. Checks text enlargement specifically — it does not itself require eliminating horizontal scrolling.
SC 1.4.10 Reflow (AA): content must be presented without loss of information or functionality, and without requiring scrolling in two dimensions, at a viewport width equivalent to 320 CSS pixels (a common way to test this on desktop is a 1280px-wide viewport at 400% zoom — the two are equivalent).
non-excepted content — see the exception below
relying on the original visual layout
The exception, precisely: SC 1.4.10 exempts only parts of content that require two-dimensional layout for their usage or meaning — not the page as a whole. Normative examples: data tables, maps, diagrams, video players, games, presentations, interfaces requiring a persistently visible toolbar. An excepted component does not exempt the rest of the page (the heading above a data table, filters, search, pagination must still reflow). Within an excepted component, individual sections may still need to reflow. "Requires" is a meaning test, not a convenience test — a component that merely looks better in a wide fixed layout, without losing information or functionality if it reflowed, is not exempt.
A page that triggers horizontal scroll at 400% zoom (or the 320px equivalent) is a high-value indicator that Reflow has not been achieved, but investigate whether the overflowing content falls within the exception before concluding a failure. See Behavioral Accessibility Automation (skills/behavioral-a11y/SKILL.md) for a reusable, tested Playwright Reflow risk indicator and its documented limitations — it is an indicator, not a Reflow conformance check; human judgment is still required to confirm the exception, verify content isn't cut off, and test actual content at 400% zoom.
SC 2.4.7 Focus Visible (AA): every keyboard-focusable element must have a visible focus indicator. Binary check — either a visible indicator exists or it does not.
SC 1.4.11 Non-text Contrast (AA): focus indicators on UI components must have a contrast ratio of at least 3:1 against adjacent colors. Applies to the indicator itself, not the component's normal state.
against the indicator color and the adjacent background/component color
SC 2.4.13 Focus Appearance (AAA): stricter than SC 2.4.7 — requires a minimum area equal to the focusable element's perimeter × 2 CSS pixels, a 3:1 contrast ratio between focused and unfocused states, and the indicator must not be fully obscured by author-created content. Projects targeting AA are not required to meet this, but meeting it provides stronger accessibility; document whether your project targets it.
Behavioral screenshot-difference testing: the CWAC project's FocusIndicatorAudit sends real Tab presses and compares whole-page screenshots before/after each press, reporting a finding when no pixels changed. It does not measure contrast (SC 1.4.11), prove a detected change is local to the focused element (its comparison is whole-page), determine an indicator is sufficiently perceptible, or distinguish a missing indicator from one obscured by other content. This repository's own reusable implementation (skills/behavioral-a11y/SKILL.md, focus-visible-risk.mjs) is an independent reimplementation of the documented method that instead captures a fresh unfocused/focused screenshot pair scoped to a padded region around each element, closing some of CWAC's whole-page limitations while introducing its own documented tradeoffs. Neither implementation, nor any screenshot-diff approach alone, verifies SC 1.4.11 (contrast) or SC 2.4.13 (minimum area). Use screenshot-difference testing as a supplementary check alongside manual verification, not as a sole focus indicator test.
Forms: navigate to form with keyboard only → fill all fields (check Tab order) → trigger validation errors → verify errors appear and are announced → correct and revalidate → submit with Enter/Space → verify success message is announced. With a screen reader, also confirm field labels/instructions/types are announced and errors are in logical reading order.
Modal dialogs: activate trigger → verify focus moves into modal → Tab through all elements → verify Tab doesn't leave modal (focus trap) → Escape or close button dismisses → verify focus returns to trigger. With a screen reader, confirm the modal is announced (role="dialog", aria-labelledby) and content is in logical reading order.
Single Page Applications: click a navigation link → verify content changes → verify focus moves to main heading/content → verify page title changes → verify the route change is announced or focus provides context. Confirm the back button works and new page structure (landmarks, headings) is clear.
For each issue found, record: component/page tested (URL or name), issue description, expected behavior, numbered steps to reproduce, assistive technology name/version, browser name/version, OS name/version, and severity. Optionally include a screenshot/recording and the WCAG success criterion violated.
## Accessibility Issue: [Brief Description]
**Component:** [URL or component name]
**Issue:** [Description of what doesn't work]
**Expected:** [What should happen]
**Severity:** [Critical/High/Medium/Low]
**Steps to Reproduce:**
1. [Step 1]
2. [Step 2]
**Testing Environment:**
- **Screen Reader:** [Name and version]
- **Browser:** [Name and version]
- **OS:** [Operating system and version]
**WCAG Criterion:** [If applicable]
**Suggested Fix:** [If you have one](For structured findings, use skills/bug-reporting/SKILL.md.)
People with disabilities are the experts in identifying barriers and validating solutions — their lived experience surfaces issues automated tools and non-disabled testers miss, and validates that fixes actually work.
timeframes, asynchronous feedback, compensation for testing time, accessible issue-reporting formats
control users, users with cognitive disabilities, users with multiple disabilities
30-minute keyboard-only test: Tab start to end; focus visible everywhere; activate all buttons (Enter/Space) and links (Enter); fill and submit a form; open/close a modal; use custom widgets; navigate menus; check for keyboard traps.
30-minute screen reader test: navigate by headings, landmarks, and form fields; read full page content; activate buttons/links; fill and submit a form; test a custom widget; verify images have alt text; verify dynamic content updates are announced.
Visual accessibility quick check: 200% zoom; focus indicator visibility; color contrast (text and UI components); content readable without color alone; light and dark modes; forced colors mode.
skills/behavioral-a11y/SKILL.md — Reflow risk and Focus Visible risk automated indicators, and their documented limitationsStandards horizon: These rules target WCAG 2.2 AA. Monitor: <https://www.w3.org/TR/wcag-3.0/>
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.