@tamsensedev/runner 0.0.0-stage → 0.2.1

package/library/agents/ui-tester.md

@@ -0,0 +1,49 @@
+---
+name: ui-tester
+description: Use to check a web UI change in a real headless browser. It starts the app with the project's own command, drives the changed flows at desktop and phone widths, runs the project's E2E specs when they exist, and returns pass or fail per scenario with described screenshots and errors. It never changes product code or the repository's tests.
+tools: Read, Grep, Glob, Bash, Write, Skill
+---
+
+You check whether a UI change works for a person using it, and you bring back evidence. Nobody can answer questions during the run: when something is unclear, decide, write the assumption down and continue.
+
+## Input you expect
+
+The caller should give you the task or acceptance criteria, the repository folder, the base branch, and optionally the scenarios to check. If scenarios are missing, derive them from the criteria and the diff (`git diff origin/<base>...HEAD`).
+
+## How to work
+
+1. Load the `ui-testing` skill with the Skill tool and follow it. Load `accessibility` too when the change adds or alters interactive controls, forms, dialogs or colours. The skills' reference files (the headless check script, Playwright patterns, the keyboard pass) are in the folders the Skill tool reports.
+2. Write the scenario list first: the changed flow, its loading, empty and error states, a 390 px width if layout changed, keyboard use of new controls.
+3. Find the project's E2E setup and how the app starts (scripts, CI workflow, `.env.example`). Check required environment variables by name only.
+4. Run the related E2E specs headless if a suite exists; check what it does not cover with the headless check script written to a new folder in the OS temp directory.
+5. Every browser you open is recorded for the task. In your own scripts, open contexts through the recorder in `TAMSENSE_RECORDER` with a title named after the goal and attempt ("Feature testing", "Second attempt at feature testing") and a one-line purpose, call `mark` at each step of a scenario, and add `video: true` for canvas, maps, video players or iframes from another site, or when the caller asks for a video (the `ui-testing` skill's `references/recording.md`).
+6. Open every screenshot with Read and describe what it shows.
+7. Stop every server you started, by its process id only (never `taskkill /IM`, `pkill` or `killall`: other programs on this computer may run on the same runtime), delete your temp folders, and confirm with `git status` that the repository is unchanged.
+
+If the skills cannot be loaded, the rules below still apply and you write a minimal Node.js Playwright script yourself, in a temp folder, resolving Playwright from the project.
+
+## What to return
+
+```
+UI check: passed | failed | could not run
+How: <commands>, browser, widths
+Recordings: <titles of the replays and videos, and their paths from closeRecorded>
+Scenarios:
+- <scenario>: pass | fail | not checked (reason). Evidence: <what the screenshot or log shows>
+Findings:
+- [Blocker | Serious | Minor] <file:line if traced> <what is wrong, steps to reproduce, expected>
+Not checked: <what and why>
+Assumptions: <test account, local data created, versions>
+Cleanup: servers stopped, temp folders removed, git status clean
+```
+
+Keep it short: quote only the error lines that matter, never whole logs, and never secrets or full connection strings.
+
+## Do not
+
+- Do not edit, create or delete files in the repository, including tests, snapshots and config. Scratch scripts, screenshots, traces and auth state go to the temp folder.
+- Do not open visible windows: no `--headed`, `--ui`, `--debug`, `show-report`, `show-trace`, `cypress open`. Run Playwright with `--reporter=line` and `PW_TEST_HTML_REPORT_OPEN=never`, and start dev servers with `BROWSER=none`.
+- Do not install packages or download browsers. If no headless browser is available, say so and stop.
+- Do not point the check at staging or production, and do not submit forms or trigger writes when the local app talks to a shared backend or database.
+- Do not skip, `fixme` or loosen failing tests, and do not report a pass for anything you did not see. If the app cannot start, report the exact reason (missing variables, services, build error) with the last relevant log lines.
+- Do not push, commit or comment anywhere.

package/library/licenses/Apache-2.0.txt

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/library/skills/accessibility/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: accessibility
+description: Use when building or reviewing web UI people interact with (forms, buttons, links, dialogs, menus, tabs, images, colour, focus, keyboard handling, dynamic messages) or when a task mentions accessibility, a11y, WCAG or screen readers. Checks WCAG 2.2 AA from the code without a browser, plus an optional headless axe scan and keyboard pass.
+---
+
+# Accessibility (WCAG 2.2 AA)
+
+Most accessibility bugs are visible in the code: a clickable `div`, an icon button with no name, an input without a label, a removed focus outline, an error shown only in red. This skill finds them in the changed UI, works without a browser, and adds an automated scan and a keyboard pass when a headless browser is available.
+
+The project's own rules come first: its component library (which may already handle focus and ARIA), its lint rules (`eslint-plugin-jsx-a11y`, `eslint-plugin-vuejs-accessibility`, Svelte's compiler warnings, Angular's template checks), its tests and any stated conformance target. Visual design rules are covered by the `web-interface-guidelines` and `design-review` skills; this skill does not repeat them.
+
+## Process
+
+### 1. Scope
+
+List the UI the change touches: components, templates, styles, routes. Include states the change adds (loading, empty, error, disabled, expanded) and anything that appears on top (dialogs, menus, toasts, tooltips).
+
+### 2. Check the code
+
+Go through the list below for every changed component. Examples are plain HTML; the same rules apply to JSX, Vue, Svelte and Angular templates (`htmlFor` in React, `:aria-label` bindings in Vue, and so on). Full criteria and longer patterns: [references/wcag-checks.md](references/wcag-checks.md).
+
+**Names and semantics (1.1.1, 1.3.1, 2.4.4, 4.1.2)**
+
+- Use native elements: `<button>` for actions, `<a href>` for navigation, `<input>`, `<select>`, `<dialog>`. A `div` with a click handler is not focusable and does not respond to Enter or Space.
+- Every interactive element has an accessible name: visible text, `aria-label` or `aria-labelledby`. Icon-only buttons need one; the icon itself gets `aria-hidden="true"`.
+- The visible label is part of the accessible name (2.5.3): a button showing "Save" must not be labelled "Submit form".
+- Images: meaningful ones get alt text that says what matters; decorative ones get `alt=""`.
+- Link text makes sense out of context ("Download invoice", not "click here").
+- Headings follow the page structure without skipping levels for styling; lists are lists; data tables have `<th>` with scope or headers.
+
+Wrong, then right:
+
+```html
+<div class="icon-btn" onclick="remove()"><svg>...</svg></div>
+
+<button type="button" aria-label="Remove item"><svg aria-hidden="true">...</svg></button>
+```
+
+**Keyboard and focus (2.1.1, 2.1.2, 2.4.3, 2.4.7, 2.4.11)**
+
+- Everything a mouse can do, the keyboard can do. Custom widgets (menus, tabs, comboboxes, sliders) follow the WAI-ARIA Authoring Practices key patterns, or better, come from the project's component library.
+- No traps: Tab and Shift+Tab can leave every component; dialogs trap focus only while open and Escape closes them.
+- Focus order follows the visual order. No positive `tabindex`.
+- Focus is managed: opening a dialog moves focus into it, closing returns it to the trigger; deleting an item moves focus somewhere sensible; client-side route changes move focus to the new content or its heading.
+- Focus is visible. `outline: none` without a replacement style is a bug. Use `:focus-visible` with a style that contrasts at least 3:1 with its background.
+- Sticky headers, footers and banners do not cover the focused element (`scroll-margin` or `scroll-padding` helps).
+
+**Colour and contrast (1.4.1, 1.4.3, 1.4.11)**
+
+- Text contrast at least 4.5:1; large text (at least 24 px, or 18.66 px bold) at least 3:1.
+- Control boundaries, focus indicators, icons that carry meaning and chart elements at least 3:1 against what is next to them.
+- Colour is never the only signal: errors also get text or an icon, links in body text are underlined or otherwise distinct, chart series also differ by label or pattern.
+- Check placeholder text, disabled-looking text that is still important, and text over images or gradients. Compute contrast from the design tokens when you can; say when you estimated.
+
+**Forms and errors (1.3.5, 3.3.1, 3.3.2, 3.3.3, 3.3.7, 3.3.8)**
+
+- Every input has a programmatic label (`<label for>` or a wrapping label). A placeholder is not a label.
+- Personal data fields have the right `autocomplete` value (`email`, `name`, `current-password`, `new-password`, `one-time-code`).
+- Errors: text next to the field that says what is wrong and how to fix it, linked with `aria-describedby`, the field marked `aria-invalid="true"`, and focus moved to the first invalid field (or an error summary) on submit.
+- Required fields are marked in text, not only with colour or an asterisk without explanation.
+- Do not block paste in password or code fields, and offer password manager friendly fields (3.3.8). Do not ask again for data the user already entered in the same flow (3.3.7).
+
+```html
+<label for="email">Email</label>
+<input id="email" type="email" autocomplete="email"
+       aria-invalid="true" aria-describedby="email-error">
+<p id="email-error">Enter an email address like name@example.com.</p>
+```
+
+**Dynamic content (4.1.3)**
+
+- Status messages that appear without a focus change (saved, copied, 3 results, upload finished) are announced: put them in a `role="status"` (polite) or `role="alert"` (urgent, errors) region that exists in the page before the message is inserted.
+- Loading states say so in text, not only with a spinner.
+
+**Pointer, motion and timing (2.2.1, 2.3.1, 2.5.7, 2.5.8)**
+
+- Targets are at least 24 by 24 CSS pixels, or spaced so a 24 px circle around each does not overlap another (inline text links are exempt). Touch-first layouts usually want 44 px.
+- Anything done by dragging also works with single clicks or taps (move up and down buttons, a menu, an input).
+- Animations respect `prefers-reduced-motion`; nothing flashes more than three times a second; auto-playing media can be paused.
+- Time limits can be extended, and sessions warn before expiring.
+
+**Page level (2.4.1, 2.4.2, 3.1.1)**
+
+- `<html lang>` is set; each route has a descriptive `<title>` (single-page apps must update it).
+- Landmarks (`header`, `nav`, `main`, `footer`) and a skip link or equivalent let keyboard users bypass repeated navigation.
+
+**ARIA misuse (4.1.2)**
+
+- No ARIA is better than wrong ARIA. Flag `aria-label` on a `div` or `span` with no role, `aria-hidden="true"` on focusable elements or their parents, `role="button"` without keyboard handling, `aria-expanded` or `aria-selected` that never updates, and duplicate `id`s that break label references.
+
+### 3. Run what the project already has
+
+Accessibility lint rules, component or E2E tests with axe, `pa11y` or Lighthouse CI configs, Storybook accessibility checks. Run them on the changed files or pages. Do not install new tools to do this.
+
+### 4. Optional: scan and keyboard pass in a headless browser
+
+When the app can be started (see the `ui-testing` skill):
+
+- **axe:** the headless check in the `ui-testing` skill (its `references/headless-check.md`) runs axe-core on each page when the project already has the `axe-core` package. If the project has `@axe-core/playwright`, use it in its own tests instead. Never download axe or a browser just for this.
+- **Keyboard pass:** use the snippet in [references/wcag-checks.md](references/wcag-checks.md#keyboard-pass-in-a-headless-browser) as the check's `steps` to record the focus order, whether each focused element shows a visible focus style, and whether Escape closes the open dialog and focus returns. The pass is recorded for the task like any browser run: set the check's title to "Keyboard pass" and its purpose to what you checked.
+
+Automated tools find roughly a third of WCAG problems. Zero axe violations is not conformance; a violation in third-party markup you do not control is still worth naming, but separately.
+
+### 5. Fix or report
+
+In a code step, fix with the smallest change that uses the project's components and patterns: a real `<button>` instead of a clickable `div`, a label, a focus style from the design tokens. Do not add ARIA to paper over the wrong element.
+
+In a review or test step, report. Rate each finding:
+
+- **Blocker:** someone cannot complete the flow (keyboard trap, unlabeled or unreachable control in a core flow, focus lost in a dialog, form errors not perceivable).
+- **Serious:** harder but possible (low contrast on body text, missing status announcements, no visible focus on some controls).
+- **Moderate:** friction (heading order, redundant alt text, small targets in secondary places).
+
+A test-step verdict fails on blockers in the changed flow, and on serious findings the change introduced.
+
+## Report
+
+```
+Accessibility: <checked from code | code + axe | code + axe + keyboard>
+Findings:
+- [Blocker] src/components/DeleteButton.vue:12 icon-only button has no accessible name (4.1.2). Fix: aria-label="Delete project", icon aria-hidden.
+- [Serious] ...
+Not checked: <screen reader output, real devices, pages behind login, and why>
+```
+
+Mention WCAG criterion numbers so findings can be looked up, and say which findings were measured (axe, computed contrast) and which come from reading the code.
+
+## Common mistakes
+
+- Adding `role="button"` and `tabindex="0"` to a `div` instead of using `<button>`.
+- `aria-label` that differs from the visible text, or labels like "button" and "icon".
+- Removing focus outlines for looks.
+- Treating a clean axe run as proof of accessibility.
+- Checking only the default state, not errors, loading and open dialogs.
+- Hiding content with `display: none` when it should stay available to screen readers (use a visually-hidden class), or leaving off-screen menus focusable.
+
+## Done when
+
+- Every changed interactive element has a name, a role, keyboard support and visible focus.
+- Forms label inputs and explain errors in text tied to the field.
+- Colour is never the only signal and contrast meets AA where you could compute it.
+- Findings carry file, line, WCAG criterion, severity and a concrete fix; what could not be checked is listed.
+
+Adapted from addyosmani/web-quality-skills `skills/accessibility` (MIT, commit afa8da942115f2961fdbfa80807ea0b232ff6c00, Copyright (c) 2026 Addy Osmani). Changed: rewritten as a review process for unattended runs, framework-neutral notes added, DevTools MCP and Lighthouse steps replaced by optional headless axe and keyboard checks, large-text threshold corrected to 24 px or 18.66 px bold, severity rules for verdicts added.

package/library/skills/accessibility/references/wcag-checks.md

@@ -0,0 +1,168 @@
+# WCAG 2.2 checks, patterns and scripts
+
+Read this when you need the exact criterion for a finding, a correct markup pattern for a fix, a contrast calculation, or the keyboard pass for the headless check.
+
+## Level A and AA criteria that matter most for web apps
+
+| Criterion | Level | What to check |
+|---|---|---|
+| 1.1.1 Non-text Content | A | Alt text on meaningful images, names on icon buttons, `alt=""` on decorative images |
+| 1.2.2 Captions (Prerecorded) | A | Videos with speech have captions |
+| 1.3.1 Info and Relationships | A | Headings, lists, tables, labels and groups exist in markup, not only in styling |
+| 1.3.2 Meaningful Sequence | A | DOM order matches reading order (CSS `order` and grid placement can break it) |
+| 1.3.5 Identify Input Purpose | AA | `autocomplete` on fields about the user |
+| 1.4.1 Use of Color | A | Colour is not the only way information is shown |
+| 1.4.3 Contrast (Minimum) | AA | 4.5:1 text, 3:1 large text (24 px, or 18.66 px bold) |
+| 1.4.4 Resize Text | AA | Usable at 200% zoom |
+| 1.4.10 Reflow | AA | No two-dimensional scrolling at 320 CSS px wide (except maps, tables, editors) |
+| 1.4.11 Non-text Contrast | AA | 3:1 for control boundaries, focus indicators, meaningful icons and graphics |
+| 1.4.12 Text Spacing | AA | No clipped text when line and letter spacing increase (avoid fixed heights on text boxes) |
+| 1.4.13 Content on Hover or Focus | AA | Tooltips and popovers can be dismissed (Escape), hovered and stay until dismissed |
+| 2.1.1 Keyboard | A | Every function works with the keyboard |
+| 2.1.2 No Keyboard Trap | A | Focus can always move away |
+| 2.1.4 Character Key Shortcuts | A | Single-key shortcuts can be turned off or only work when a component has focus |
+| 2.2.1 Timing Adjustable | A | Time limits can be extended |
+| 2.2.2 Pause, Stop, Hide | A | Moving or auto-updating content can be paused |
+| 2.3.1 Three Flashes | A | Nothing flashes more than three times per second |
+| 2.4.1 Bypass Blocks | A | Skip link or landmarks |
+| 2.4.2 Page Titled | A | Descriptive, unique titles per route |
+| 2.4.3 Focus Order | A | Order preserves meaning; dialogs and route changes manage focus |
+| 2.4.4 Link Purpose (In Context) | A | Link text says where it goes |
+| 2.4.6 Headings and Labels | AA | Headings and labels describe their content |
+| 2.4.7 Focus Visible | AA | A visible focus indicator |
+| 2.4.11 Focus Not Obscured (Minimum) | AA | Focused element not fully hidden by sticky or overlay content |
+| 2.5.1 Pointer Gestures | A | Multi-finger or path gestures have a single-pointer alternative |
+| 2.5.2 Pointer Cancellation | A | Actions fire on release, not on press |
+| 2.5.3 Label in Name | A | Accessible name contains the visible label |
+| 2.5.7 Dragging Movements | AA | Dragging has a single-pointer alternative |
+| 2.5.8 Target Size (Minimum) | AA | 24 by 24 CSS px, or enough spacing |
+| 3.1.1 Language of Page | A | `<html lang>` |
+| 3.1.2 Language of Parts | AA | `lang` on passages in another language |
+| 3.2.1 On Focus / 3.2.2 On Input | A | Focusing or changing a field does not navigate or submit unexpectedly |
+| 3.2.3 Consistent Navigation | AA | Navigation in the same order across pages |
+| 3.2.6 Consistent Help | A | Help links or contact options in the same place across pages |
+| 3.3.1 Error Identification | A | Errors described in text and tied to the field |
+| 3.3.2 Labels or Instructions | A | Labels and format hints |
+| 3.3.3 Error Suggestion | AA | Say how to fix it when known |
+| 3.3.4 Error Prevention (Legal, Financial, Data) | AA | Review, confirm or undo for important submissions |
+| 3.3.7 Redundant Entry | A | Do not ask again for data entered earlier in the same process |
+| 3.3.8 Accessible Authentication (Minimum) | AA | No memory or puzzle test without an alternative; allow paste and password managers |
+| 4.1.2 Name, Role, Value | A | Custom controls expose name, role and state |
+| 4.1.3 Status Messages | AA | Status updates announced without moving focus |
+
+Criteria 2.4.12, 2.4.13 and 3.3.9 are AAA and new in 2.2; 4.1.1 Parsing was removed in 2.2, so do not report it.
+
+## Patterns
+
+**Visually hidden text** (for screen readers only):
+
+```css
+.visually-hidden {
+  position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px;
+  overflow: hidden; clip: rect(0, 0, 0, 0); white-space: nowrap; border: 0;
+}
+```
+
+Use the project's existing utility if it has one (`sr-only`, `visually-hidden`, a component).
+
+**Dialog:** prefer native `<dialog>` opened with `showModal()`, which makes the rest of the page inert and closes on Escape. Give it a name (`aria-labelledby` pointing at its heading), move focus inside on open, and return focus to the trigger on close. A custom dialog needs `role="dialog"`, `aria-modal="true"`, a focus trap, Escape handling and an inert or `aria-hidden` background.
+
+**Skip link:**
+
+```html
+<a class="skip-link" href="#main">Skip to main content</a>
+<main id="main" tabindex="-1">...</main>
+```
+
+with CSS that keeps it off-screen until it receives focus.
+
+**Error summary on submit:** a heading like "2 problems need fixing" with links to each invalid field, focused after a failed submit; each field keeps its own inline error with `aria-describedby`.
+
+**Tabs:** `role="tablist"` containing `role="tab"` elements with `aria-selected` and `aria-controls`; panels with `role="tabpanel"` and `aria-labelledby`. Only the active tab has `tabindex="0"`; arrow keys move between tabs.
+
+**Disclosure and menus:** a button with `aria-expanded` that toggles the controlled region. Do not use `role="menu"` for site navigation; it promises application-style keyboard behaviour.
+
+**Live region:** render the container empty on page load, then change its text:
+
+```html
+<div role="status" class="visually-hidden" id="announcer"></div>
+```
+
+Clearing it before writing the same message again makes screen readers repeat it.
+
+**Reduced motion:**
+
+```css
+@media (prefers-reduced-motion: reduce) {
+  *, *::before, *::after {
+    animation-duration: 0.01ms !important;
+    animation-iteration-count: 1 !important;
+    transition-duration: 0.01ms !important;
+    scroll-behavior: auto !important;
+  }
+}
+```
+
+Or scope it to the animations the change adds, if the project handles motion per component.
+
+## Contrast from design tokens
+
+When colours come from tokens or CSS variables, compute the ratio instead of guessing. Run with `node -e` or in a temp file:
+
+```js
+function luminance(hex) {
+  const value = hex.replace('#', '')
+  const full = value.length === 3 ? value.split('').map(c => c + c).join('') : value
+  const [r, g, b] = [0, 2, 4].map(i => parseInt(full.slice(i, i + 2), 16) / 255)
+    .map(c => (c <= 0.04045 ? c / 12.92 : ((c + 0.055) / 1.055) ** 2.4))
+  return 0.2126 * r + 0.7152 * g + 0.0722 * b
+}
+function contrast(foreground, background) {
+  const [light, dark] = [luminance(foreground), luminance(background)].sort((a, b) => b - a)
+  return (light + 0.05) / (dark + 0.05)
+}
+console.log(contrast('#6b7280', '#ffffff').toFixed(2))
+```
+
+Semi-transparent colours must be blended with their real background first. For dark mode, check both themes.
+
+## Keyboard pass in a headless browser
+
+Use as the `steps` function of the `ui-testing` headless check. It records the first stops of the Tab order, whether each one shows a focus style, and whether Escape closes an open dialog. The focus-style test is a heuristic (it looks for an outline or box shadow); confirm doubtful cases on a screenshot.
+
+```js
+async function steps(page) {
+    const stops = []
+    for (let i = 0; i < 25; i++) {
+        await page.keyboard.press('Tab')
+        const stop = await page.evaluate(() => {
+            const el = document.activeElement
+            if (!el || el === document.body) return null
+            const style = getComputedStyle(el)
+            const hasOutline = style.outlineStyle !== 'none' && parseFloat(style.outlineWidth) > 0
+            const hasShadow = style.boxShadow && style.boxShadow !== 'none'
+            const label = el.getAttribute('aria-label') || el.innerText || el.getAttribute('title') || el.getAttribute('name') || ''
+            return {
+                element: el.tagName.toLowerCase() + (el.getAttribute('role') ? `[role=${el.getAttribute('role')}]` : ''),
+                name: label.trim().replace(/\s+/g, ' ').slice(0, 60),
+                visibleFocus: Boolean(hasOutline || hasShadow),
+                inViewport: (() => { const r = el.getBoundingClientRect(); return r.bottom > 0 && r.top < innerHeight })(),
+            }
+        })
+        if (!stop) break
+        stops.push(stop)
+    }
+    let escapeClosesDialog = null
+    const dialog = page.locator('dialog[open], [role="dialog"]').first()
+    if (await dialog.isVisible().catch(() => false)) {
+        await dialog.locator('button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])').first().focus().catch(() => {})
+        await page.keyboard.press('Escape')
+        escapeClosesDialog = !(await dialog.isVisible().catch(() => false))
+    }
+    return { stops, escapeClosesDialog }
+}
+```
+
+Read the result: stops with an empty `name` are unnamed controls; `visibleFocus: false` needs a screenshot check; the order should follow the visual layout; stops that repeat in a loop inside one component suggest a trap. To test a dialog, open it in `steps` first (click its trigger), then run the same loop and check focus stays inside it and returns to the trigger after Escape.
+
+Adapted from addyosmani/web-quality-skills `skills/accessibility/references/WCAG.md` and `A11Y-PATTERNS.md` (MIT, commit afa8da942115f2961fdbfa80807ea0b232ff6c00, Copyright (c) 2026 Addy Osmani). Changed: limited to A and AA criteria relevant to web apps with "what to check" notes, patterns condensed, contrast and keyboard-pass scripts added.