critique-accessibility

Solid

Reviews HTML pages and fragments (markdown where mappable) against WCAG 2.2 AA: contrast, alt text, heading hierarchy for screen readers, link text, and keyboard and screen-reader access. Judges conformance against WCAG, not an interface's general usability, flow, or controls (critique-usability covers that). Use when the user asks for an accessibility review, feedback, a second opinion, a red-line pass, an a11y audit, or a pre-launch quality check on a page or component.

AI & Automation 1 stars 0 forks Updated 4 days ago Apache-2.0

Install

View on GitHub

Quality Score: 80/100

Stars 20%
10
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# critique-accessibility Reviews an HTML page or fragment (markdown where its structure maps cleanly to HTML, such as headings, links, and images) against WCAG 2.2 AA, covering both success-criterion levels A and AA required for AA conformance. The artifact claim is narrow and static: this skill evaluates markup and declared CSS as text, never a rendered page, a running application, or live keyboard and pointer interaction. Four WCAG 2.2 success criteria that require observing a page respond to input over time (No Keyboard Trap, Timing Adjustable, Pointer Gestures, Dragging Movements) are out of this skill's reach for that reason and are not in its registry; see `references/WCAG.md`, "Scope", for the full boundary and reasoning. ## Contract Every finding this skill emits conforms to `contract/critique-contract.schema.json`. See `docs/reference/critique-contract.md` for the field contracts a schema cannot check on its own: location navigable unaided, evidence quoted or measured rather than characterized, violation naming the breach, fix actionable and specific. ## Naming a location A finding names the element it is about, not the region the element sits in. For an HTML artifact, in this order of preference: 1. **The element's `id`, written as a `#hero-image` token**, whenever the markup carries one. This is the first choice every time, and generated or hand-written markup usually carries ids. 2. **A CSS selector in double quotes** for an element with no id: `"main > s...

Details

Author
product-on-purpose
Repository
product-on-purpose/critique-skills
Created
3 weeks ago
Last Updated
4 days ago
Language
Python
License
Apache-2.0

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Solid

critique-usability

Reviews HTML or markdown UI specs, wireframe write-ups, and page mockups against Nielsen's 10 usability heuristics: system status, user control and exits, consistency, error prevention and recovery, recognition over recall, and minimalist design. Judges the interface's flow, controls, and states, not the wording of error or empty-state message text (critique-microcopy covers that), and not conformance against accessibility standards such as contrast or screen-reader access (critique-accessibility covers that). Use when the user asks for a usability review, design feedback, a second opinion, a red-line pass, a heuristic evaluation, or a quality check on a screen, a flow, or an interface spec before it goes to build. Covers static specs and mockups, not live running applications.

1 Updated 4 days ago
product-on-purpose
AI & Automation Listed

accessibility-audit

Adversarially audit a UI (component code, page markup, screenshot, or flow) against WCAG 2.2 AA — findings cited to specific success criteria, centered on the user and assistive tech each one blocks, severity-tagged, with a concrete fix and what a scanner would miss. Use when the user wants an accessibility review, a11y audit, WCAG check, or to find what blocks screen-reader / keyboard / low-vision users before shipping.

2 Updated 6 days ago
sananthanarayan
Code & Development Listed

accessibility-review

Audits a digital product against recognized accessibility standards — WCAG (the W3C Web Content Accessibility Guidelines) and IBM's accessibility requirements — and produces a prioritized findings report mapping each issue to the specific success criterion it fails, with severity and a concrete fix. Use this whenever the user wants an accessibility review, a11y audit, WCAG check, Section 508 / EN 301 549 conformance pass, or wants to know whether a screen, component, flow, PDF, or document is accessible; wants to fix contrast, keyboard, screen-reader, focus, alt-text, form-label, or ARIA problems; or asks which WCAG criterion something violates. Reach for it even when "accessibility" isn't named — any request to make a UI usable for people with disabilities, or to meet a legal accessibility requirement, qualifies.

0 Updated 3 weeks ago
JoaoMonteiro100