Compatibility listing for link-purpose installs from AccessLint's marketplace skill set.
Real-world examples not captured yet
This skill shows a gallery of live HTML demos (CDN libraries welcome — GSAP, Three.js, etc.) rendered inline via srcdoc.
Skill markdown
This is the semi-automated manual tier of a WCAG assessment: the checks that need interaction (keyboard, focus, state changes, reflow) or human review (focus visibility, error recovery, reading order), which a static rule engine can't decide. Work against the running page; use source only to map a finding to `file:line`. Locate and assess — don't fix (that's `accesslint:accessibility-fix`). The automated tier is `accesslint:accessibility-scan`; `accesslint:accessibility-audit` runs both under WCAG-EM. The shared rules — severity, the no-proxy boundary, high-risk patterns, conformance, grounding — are in [`../shared/methodology.md`](../shared/methodology.md). Read it when a call needs judgment. The rules that always apply are below. ## Grading Tag each finding with a severity (user impact) and an evidence basis (what you can support). Keep the two separate. - ● Verified — deterministic and reproducible. Cite the selector, the interaction, and the observed a11y-tree or DOM fact. Without that proof it is not ●. - ◐ Flagged — you have evidence, but the decision needs a person. Attach the evidence and your opinion; don't decide it yourself. - ○ Human-required — needs assistive technology or lived experience. Hand it off; don't emulate it. When unsure between two evidence grades, use the lower one. The icons show evidence basis by fill, not color. A finding that stacks a deterministic fact on an interpretive call takes the lower grade. The machine-checkable half (e.g. no programmatic status in the a11y tree — a 1.3.1 fact) is ● evidence *inside* a ◐ finding; the interpretive conclusion (e.g. that color is the sole carrier of the meaning — 1.4.1) stays ◐. Citing the ● half does not upgrade the whole. Severity (user impact, separate from evidence basis): - Critical — blocks a core task, with no workaround. - Serious — a major barrier; the task is possible but difficult. - Moderate — noticeable friction; the task still completes. - Minor — a small inefficiency or polish issue. ## The ledger — a denominator, not a script The checkpoint areas below are the run's denominator: every criterion in them ends the run in exactly one state, and the report says which. - **● verified** or **◐/○ flagged** — you drove the check and have the evidence. - **N/A** — the triggering feature isn't on the page (no form, no media, no drag UI). Decided from the snapshot; free. - **Not exercised** — the feature is present but you didn't drive it. Reported as **undetermined**, never silently dropped, and never as a pass. Not-exercised is a legitimate, honest outcome and it costs nothing. Drive only what the page's features and the engine's gaps demand; don't work through checkpoints to make the report look thorough. An "undetermined — not exercised" line and a driven-and-verified line differ in evidence, not in honesty. Dedup **before** driving, not after: the engine (`accessibility-scan`) owns the statically-detectable criteria — name/label presence, `lang`, `autocomplete`, semantic markup, contrast of text on flat backgrounds. If a scan result set or engine-owned SC list was provided (as `accessibility-audit` does), never re-check those criteria; ledger them as engine-owned. Without one, read what you can from the initial snapshot rather than re-deriving what the engine would catch. | Area | SCs | Trigger to drive | |------|-----|------------------| | Keyboard & focus | 2.1.1, 2.1.2, 2.4.3, 2.4.7, 2.4.11 | Always — one batched walk (below) | | Structure & semantics | 1.3.1, 1.3.2, 2.4.1, 2.4.6 | Always — read from the initial snapshot; no extra driving | | Names, roles, states | 4.1.2, 2.5.3, 4.1.3 | Custom widgets / stateful controls present (static name presence is engine-owned) | | Visual adaptation | 1.4.1, 1.4.4, 1.4.10, 1.4.12, 1.3.4, 2.3.3, 1.4.11 | Reflow/zoom on every page (one resize each); motion checks only if motion is present | | Forms & errors | 3.3.1–3.3.3, 1.3.5, 3.3.7, 3.3.8 | A form is present (label/`autocomplete` presence is engine-owned) | | Media & timing | 1.2.x, 2.2.1, 2.2.2 | `<video>`/`<audio>`, autoplay, or timeouts present | | Pointer & target | 2.5.1, 2.5.7, 2.5.8 | Target size comes free from the batched walk; drag checks only if drag UI | | Content & navigation | 3.1.1/2, 2.4.4, 3.2.3/4, 3.2.6 | `lang` and link purpose from the snapshot; cross-page consistency is `accessibility-audit`'s (not exercised here) | Per-checkpoint procedure and default grades: [`references/checkpoints.md`](references/checkpoints.md). Read it when a triggered area needs its detailed steps, or when the user asks for a deep pass (`--deep`: drive every triggered area through its full procedure). ## Evidence budget — cap spend by grade Calibrated uncertainty must be cheaper than false certainty. The grade a finding can reach bounds the evidence worth gathering: - **●** — full proof, gathered once: selector, interaction, observed DOM or a11y-tree fact. Don't repeat an interaction you already recorded. - **◐** — hard cap: …
More from AccessLint
- Accessibility DiffRegression check that diffs a live page's accessibility violations against a baseline from uncommitted changes or a branch.
- Accessibility ScanRun the AccessLint rule engine against a live page and return a worklist of WCAG 2.2 violations grounded to DOM selectors and source locations.
- Audit And FixAccessibility auditing and remediation workflow that combines detection, prioritization, and practical fixes for WCAG issues.
- Contrast CheckerCompatibility listing for contrast-checker installs from AccessLint's marketplace skill set.
- RefactorCompatibility listing for refactor installs from AccessLint's marketplace skill set.
- Use Of ColorCompatibility listing for use-of-color installs from AccessLint's marketplace skill set.