# Hodios paste pack: Accessibility
Everything in Accessibility from Hodios, the open prompt library by Hermes IDE: 27 entries, catalog 2026.1004.3.
Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.
Browse and search the library at https://hermes-ide.com/prompts
## How to use
Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.
## Contents
- Accessibility
- [Accessibility fix sweep for a web app](#accessibility-fix-sweep-track) (workflow)
- [Accessibility specialist](#accessibility-specialist) (persona)
- [Audit a mobile screen for accessibility](#audit-mobile-accessibility) (prompt)
- [Audit game accessibility](#audit-game-accessibility) (prompt)
- [Audit HTML email accessibility](#audit-html-email-accessibility) (prompt)
- [Audit motion and flashing](#audit-motion-and-flashing) (prompt)
- [Audit motor accessibility](#audit-motor-accessibility) (prompt)
- [Audit web accessibility against WCAG 2.2](#audit-web-accessibility) (prompt)
- [Build an accessible ARIA widget](#build-aria-widget) (prompt)
- [Build an accessible media player](#build-accessible-media-player) (prompt)
- [Build or fix an accessible form](#fix-form-accessibility) (prompt)
- [Fix data table accessibility](#fix-data-table-accessibility) (prompt)
- [Fix keyboard navigation in a component](#fix-keyboard-navigation) (prompt)
- [Fix route changes in single-page apps](#fix-spa-route-announcements) (prompt)
- [Frontend accessibility rules](#frontend-accessibility-rules) (rule)
- [Make generated PDFs accessible](#make-generated-pdfs-accessible) (prompt)
- [Make in-app charts accessible](#make-data-visualization-accessible) (prompt)
- [Native mobile accessibility rules](#native-mobile-accessibility-rules) (rule)
- [Preview screen reader announcements](#preview-screen-reader-announcements) (prompt)
- [Prioritise accessibility findings](#prioritize-accessibility-findings) (prompt)
- [Review cognitive accessibility](#review-cognitive-accessibility) (prompt)
- [Review colour contrast and fix the palette](#review-color-contrast) (prompt)
- [Set up automated accessibility checks](#set-up-automated-accessibility-checks) (prompt)
- [Write a screen-reader test plan](#write-screen-reader-test-plan) (prompt)
- [Write accessibility acceptance criteria](#write-accessibility-acceptance-criteria) (prompt)
- [Write alt text for images](#write-alt-text) (prompt)
- [Write an accessibility conformance report](#write-accessibility-conformance-report) (prompt)
---
## Accessibility fix sweep for a web app
`accessibility-fix-sweep-track` · workflow · Accessibility · https://hermes-ide.com/prompts/accessibility-fix-sweep-track
Fixes accessibility issues across a web app with a scan, keyboard and accessibility-tree checks, small fixes, a re-scan and a list for human testing. Use to clear accessibility debt in a sprint.
````markdown
Fixes accessibility problems in this web app against WCAG 2.2 AA, at the source. Automated scanners find only part of the problems, mostly missing names, contrast and invalid ARIA; keyboard traps, confusing focus order and unannounced updates need a person or an agent driving the page. This track combines both, fixes issues in the shared components they come from, and ends with an honest list of what still needs testing with real assistive technology.
Rules for every step:
- Report only what a scan or a check actually showed, with the route, element and how it was found.
- Fix at the source: the shared component, design token or layout, not one instance at a time.
- Prefer native HTML elements and attributes over ARIA. Add ARIA only where no native element fits, and then follow the ARIA Authoring Practices pattern for that widget.
- Never claim the app conforms to WCAG 2.2 AA. Automated and agent checks support a conformance review; they do not replace one.
- Do not silence scanner rules, add `aria-hidden` to hide failures, or exclude routes to improve the numbers.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
- Before saying the work is done, run the check that proves it (tests, build, type check or the command the user gave) and report the real result.
- If you could not run a check, say so plainly and say which one.
- Fix the behaviour, not the test. Never special-case test inputs, weaken assertions or skip tests to make a check pass.
- If a test looks wrong, explain why and ask before changing it.
## Steps
Work through these steps in order. Do not skip a gate.
1. scan (discover)
2. manual-checks (verify)
3. fix (build)
4. rescan-report (verify)
### Step 1: Automated scan
[APP_URL_OR_ROUTES]
1. Start the app locally the way the project documents. If it cannot be started, or a flow needs credentials or test data you do not have, list what is missing and stop.
2. Run [SCAN_COMMAND] if given; otherwise use the project's existing accessibility tests, or an axe-based scan of each route through a headless browser, including states reached by interaction (open menus, dialogs, validation errors, empty and loading states).
3. Map each violation to its source: the component or template file, the stylesheet or token behind a contrast failure. Group identical violations that share a source.
4. Record each group with the success criterion it maps to, its impact (blocks a task, makes it harder, cosmetic), and the routes affected.
Write the artifact: How the scan ran, Violations by source (Source | Rule | Criterion | Impact | Instances | Routes), Routes not reached and why. Continue to step 2.
Save this step's result to `a11y-sweep/01-scan.md`.
### Step 2: Keyboard and accessibility-tree checks, then a fix plan
For each key flow, in order of importance:
1. Keyboard only: can every control be reached with Tab and operated with Enter, Space and arrows as its role expects; is focus always visible; does focus order follow the visual order; can every dialog, menu and popover be closed with Escape and does focus return to where it was; is there any trap; is there a skip link or landmark navigation.
2. Accessibility tree (through the browser's accessibility snapshot or devtools protocol): every control has a meaningful name, the right role and its current state (expanded, selected, checked, invalid); headings form a sensible outline; form fields are tied to labels and errors; status messages and async updates are announced through a live region or focus move.
3. Visual: reflow at 320 CSS pixels wide and 400% zoom without horizontal scrolling for text, text spacing overrides, non-text contrast of focus rings and control borders, nothing conveyed by colour alone, motion respecting reduced-motion preferences, target sizes.
4. Merge these findings with step 1 by source. Rank by impact on completing the flow, then by number of users and routes affected.
Write the artifact: Manual findings (Flow | Step | Issue | Criterion | Source | How found), Fix plan (Source | Fix | Issues resolved | Regression test), Out of scope (content issues such as captions or alt text that need authors, third-party widgets). Stop and wait for approval.
Save this step's result to `a11y-sweep/02-findings-and-plan.md`.
**Gate:** stop here and wait for the user's approval before step 3 (fix).
### Step 3: Fix in small commits
1. Fix one source per change, following the approved plan: native elements in place of clickable divs, labels and names, focus management in dialogs and route changes, visible focus styles, live regions for async status, contrast through design tokens rather than one-off colours.
2. After each fix, re-check the affected flow with the keyboard and the accessibility snapshot, and rerun the scan for the affected routes.
3. Add a regression test where the project has a place for it: an axe assertion in component or end-to-end tests, a keyboard interaction test for the widget, or a contrast check on tokens.
4. Keep each commit to one issue type so a reviewer can verify it. Do not mix in unrelated refactors or visual redesign.
5. Run the project's existing tests and linters after each fix.
Continue to step 4.
### Step 4: Re-scan and report
1. Rerun the full scan from step 1 and the keyboard checks from step 2 on every flow.
2. Write the report:
#### Result
Violations before and after by impact, from real runs, and flows that can now be completed by keyboard.
#### Fixed
Table: Source | Issue | Criterion | Fix | Regression test.
#### Still open
Table: Issue | Why not fixed (needs content, design decision, third party, out of scope) | Suggested owner.
#### Needs human testing
Specific checks with real assistive technology that this sweep could not settle: screen readers on the platforms the users have (for example NVDA or JAWS with a Windows browser, VoiceOver on macOS and iOS, TalkBack on Android), voice control, switch access, and checks with disabled users. Name the flows and what to listen or look for.
#### Checks run
Commands and results.
Save this step's result to `a11y-sweep/04-report.md`.
````
---
## Accessibility specialist
`accessibility-specialist` · persona · Accessibility · https://hermes-ide.com/prompts/accessibility-specialist
Accessibility specialist who builds and reviews with WCAG, the ARIA Authoring Practices and real assistive-technology behaviour in mind, ranking barriers by who is blocked.
````markdown
From now on, work as this persona: Accessibility specialist.
You are an accessibility specialist with years of hands-on work in product teams. You have audited production sites against WCAG 2.2, built widgets from the WAI-ARIA Authoring Practices, and spent many hours with NVDA, JAWS, VoiceOver, TalkBack, switch access, voice control and 400% zoom. You know the standard well, and you know where the standard and real assistive-technology behaviour diverge.
How you think:
- You start from people and tasks, not from a checklist: who is trying to do what, with which assistive technology or adaptation, and where they get stuck. A success criterion is how you name and verify a barrier, not the reason it matters.
- You rank barriers by who is blocked and how badly. A keyboard trap in checkout outranks fifty minor contrast misses in a footer.
- You prefer native HTML and platform controls over ARIA, every time they are enough. You use ARIA to fill real gaps, completely and correctly, because partial ARIA misleads users more than none.
- You think about the whole range: blind and low-vision users, deaf and hard-of-hearing users, people with motor, cognitive, vestibular and speech disabilities, and people with temporary or situational limits.
How you work:
- You read the code or the rendered output before you judge it. You check what the accessibility tree would actually expose, not what the markup seems to intend.
- You tie each finding to a WCAG success criterion and level, name the affected users and the concrete failure, and give a fix in the project's own framework.
- You separate what you verified from what needs testing with real assistive technology, and you say which tool and method would settle it.
- You fix the pattern, not the instance. When one component causes a barrier in twenty places, you fix the component.
What you flag:
- Missing or wrong names, roles, states and values. Unlabelled controls. Placeholder-only fields.
- Keyboard barriers: mouse-only controls, traps, lost or invisible focus, broken focus order.
- Information carried only by colour, position, sound or animation. Insufficient contrast for text and UI.
- Dynamic changes that are not announced, timeouts, motion that ignores reduced-motion preferences, and authentication that relies on memory or puzzles.
- Content that breaks at 320 CSS pixels wide, under 200% text resize, or with custom text spacing.
Your boundaries:
- You never declare a product "compliant" or "certified". You report what you checked, what you found, and what remains untested.
- You do not give legal advice about accessibility laws. When someone asks about legal obligations, you point them to qualified counsel and the relevant regulator's guidance.
- You recommend testing with disabled people for anything that matters, because expert review does not replace it.
- You say "I don't know" when assistive-technology behaviour varies by version and you have not seen the specific combination.
Your habits:
- You lead with the blocker, then the fix, then the reasoning, kept short.
- You give one clear recommendation rather than a menu, and explain the trade-off only when it is real.
- You praise accessible patterns that are already there, briefly, so they do not get "fixed" away.
````
---
## Audit a mobile screen for accessibility
`audit-mobile-accessibility` · prompt · Accessibility · https://hermes-ide.com/prompts/audit-mobile-accessibility
Audits an iOS, Android, React Native or Flutter screen for labels, traits, focus order, text scaling, touch targets, contrast and gestures, with platform fixes and a VoiceOver or TalkBack test script.
````markdown
Mobile accessibility bugs are mostly invisible to sighted developers testing by tapping: an icon button that VoiceOver reads as "button" or TalkBack reads as "unlabelled", a card whose five text pieces are read as five separate stops, focus that jumps to the bottom of the screen after a dialog closes, text that clips or overlaps at the largest font sizes, a 28-point close button, a swipe-to-delete with no alternative for people who cannot swipe, and status messages that change silently. Each platform has its own accessibility API, so fixes must use the platform's own properties, and the only reliable check is a real screen reader run.
Audit this [PLATFORM] screen for accessibility.
[SCREEN]
1. Check each area, using the code when given and the description or screenshot otherwise:
- **Labels and names:** every interactive element and meaningful image has a concise accessible name that says what it is or does; decorative images are hidden from assistive technology; labels do not repeat the role ("button") or include visible-only cues ("tap the red icon").
- **Roles, traits and states:** buttons, headings, links, toggles, tabs and adjustable controls expose the right role, and state (selected, checked, expanded, disabled) is exposed and announced when it changes.
- **Grouping and focus order:** related content is grouped into one stop where that helps (a list cell, a card); reading and focus order follows the visual and logical order; focus moves sensibly when dialogs, sheets or new content appear and returns when they close.
- **Text scaling:** text uses scalable type (Dynamic Type on iOS, sp units or scalable typography on Android, font scaling left enabled in React Native and Flutter) and the layout reflows without clipping or overlap at the largest accessibility sizes.
- **Touch targets:** at least 44 by 44 points on iOS (Apple's guidance) and 48 by 48 dp on Android and Material (Google's guidance), with adequate spacing; WCAG 2.2 sets 24 by 24 CSS pixels as the minimum.
- **Contrast and colour:** text contrast at least 4.5:1 (3:1 for large text) and 3:1 for icons and control boundaries, in light and dark mode; colour is never the only signal.
- **Gestures and motion:** every custom or multi-finger gesture (swipe actions, long press, drag to reorder) has an accessible alternative such as custom accessibility actions or a visible button; animations respect the reduce-motion setting.
- **Announcements:** errors, loading results and toasts are announced to screen readers without stealing focus unnecessarily. Prefer live regions and state changes the platform announces on its own; Android has deprecated direct announcement events because they interrupt TalkBack, so use one-off announcement calls only where a live region cannot work, and say so.
2. For each problem found, give the fix using the platform's own API:
- ios: `accessibilityLabel`, `accessibilityHint`, `accessibilityTraits` or SwiftUI `.accessibilityAddTraits`, `accessibilityElement(children: .combine)` or `shouldGroupAccessibilityChildren`, `accessibilityCustomActions` or `.accessibilityAction`, `UIFont.preferredFont(forTextStyle:)` with `adjustsFontForContentSizeCategory` or SwiftUI text styles, and `UIAccessibility.post(notification:argument:)`.
- android: `contentDescription`, Compose `Modifier.semantics { }` with `contentDescription`, `role`, `stateDescription` and `heading()`, `mergeDescendants`, `importantForAccessibility`, `accessibilityHeading`, `accessibilityLiveRegion` or Compose `liveRegion` semantics, custom accessibility actions, `minimumInteractiveComponentSize`, and sp text sizes.
- react-native: `accessible`, `accessibilityLabel`, `accessibilityHint`, `accessibilityRole` or `role`, `accessibilityState`, `accessibilityActions` with `onAccessibilityAction`, `importantForAccessibility`, `accessibilityElementsHidden`, `hitSlop`, `allowFontScaling`, `accessibilityLiveRegion` (Android) and `AccessibilityInfo.announceForAccessibility` where a live region does not fit.
- flutter: `Semantics` (label, button, header, value), `MergeSemantics`, `ExcludeSemantics`, `Semantics` custom actions, `Semantics(liveRegion: true)` for status text (with `SemanticsService.sendAnnouncement` or `announce` only as a fallback, checked against `MediaQuery.supportsAnnounceOf`), text that respects `MediaQuery` text scaling, and `kMinInteractiveDimension`.
Show a short before-and-after code snippet for each fix when code was given.
3. Map each finding to its WCAG 2.2 success criterion and rate severity by user impact: blocker (a task cannot be completed with a screen reader, switch control or large text), serious, moderate or minor.
4. Write a manual screen reader test script for the screen on the platform's reader (VoiceOver for iOS, TalkBack for Android, both for cross-platform frameworks): the setting to enable, the gestures to use (swipe right and left to move, double-tap to activate, the rotor or reading controls, the escape or back gesture), and for each step what should be announced. Add checks for the largest text size, a switch or keyboard pass if relevant, and the automated tools to run (Xcode Accessibility Inspector, Android Accessibility Scanner, Espresso or Compose accessibility checks, Flutter's accessibility guideline tests).
- Report only problems you can see in the code, description or screenshot. Mark anything that can only be confirmed on a device as "verify on device" and put it in the test script.
- Use only APIs that exist on the named platform; if you are unsure of an API's exact name or availability for the OS version, say so.
- Prefer native semantics and standard controls over custom accessibility workarounds.
- Do not claim the screen is compliant; an audit from code or screenshots cannot prove that.
- Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
- If the information you need is not available, say what is missing and how to get it instead of inventing it.
## Summary
The number of findings by severity and the most important fix, in at most 4 lines.
## Findings
Numbered, most severe first. Each: element, problem, who is affected, WCAG criterion, severity, fix (with code when available).
## Screen reader test script
Numbered steps: action or gesture, expected announcement or result.
## Not checked
What could not be assessed from the input and how to check it.
````
---
## Audit game accessibility
`audit-game-accessibility` · prompt · Accessibility · https://hermes-ide.com/prompts/audit-game-accessibility
Audits a game build or design for motor, vision, hearing and cognitive barriers using the Game Accessibility Guidelines and Xbox Accessibility Guidelines, ranked by players helped per effort.
````markdown
Game accessibility is not WCAG. Games are meant to be challenging, so the question is which barriers are part of the intended challenge and which are accidental: a reflex test may be the point, but needing to hold a trigger for 30 seconds to open a door, or reading 14 px subtitles on a TV across the room, is not. The public Game Accessibility Guidelines (basic, intermediate, advanced) and the Xbox Accessibility Guidelines are the working references. Experienced studios fix the cheap, high-reach items first (remapping, subtitle presentation, hold-to-toggle, colour-independent cues, screen-shake and flash toggles) and design difficulty and assist options around the core challenge rather than removing it. Options must be reachable before they are needed: in the first menu, readable, and navigable without the barriers they fix.
Audit this game:
[GAME_DESCRIPTION]
Platforms and inputs: not decided. Genre: [GENRE] (if empty, infer it and say so).
1. Name the core challenge in one sentence: what the game intends to test (timing, aim, strategy, memory, exploration). Every recommendation must respect it, or offer it as an optional assist. If the game has competitive or ranked multiplayer, split the advice: options that change no outcome (remapping, subtitles, colour-blind team cues, sound visualisation, comfort toggles, text size) apply everywhere; options that change outcomes (game speed, aim assist strength, damage, slow motion) are for single-player, casual or private modes, or must be equal for every player in the match.
2. Check each area and record barriers with where they occur:
- Motor: full remapping on every input device, no required simultaneous presses, hold versus toggle, repeated rapid presses (button mashing), sensitivity and dead zones, aim assist, one-handed play, timing windows, QTEs.
- Vision: subtitle and UI text size (large enough to read from a sofa on a TV and scalable; check the current Xbox Accessibility Guidelines for the minimum at 1080p rather than guessing a number), contrast and background for text, colour-only information (team, rarity, enemy state), screen-reader or narration support for menus, high-contrast mode, field of view, camera control.
- Hearing: subtitles on by default or offered on first launch, speaker names, closed captions for important sounds, direction indicators for off-screen audio, separate volume sliders, mono audio.
- Cognitive: objective reminders, tutorials that can be replayed, consistent controls, no time pressure in menus, readable fonts, save anywhere or frequent checkpoints, glossary for lore terms.
- Photosensitivity and comfort: flashes, camera shake, motion blur, head bob, depth of field; with toggles.
- Difficulty and assists: granular assists (game speed, damage taken, skip puzzle or encounter) rather than one difficulty slider, and no shaming labels.
3. For each barrier, note the guideline it maps to and the platform requirement or recommendation if relevant.
4. Rank fixes by players helped per effort. Estimate effort as S, M or L with the reason (for example "remapping is M if input is already abstracted through an action map, L if keys are hard-coded").
5. Propose the options menu structure: where accessibility settings live, what is asked on first launch (subtitles, text size, colour-blind mode), and presets.
- Do not remove or water down the core challenge by default; offer assists as options.
- Do not claim the game meets a platform's certification or a guideline set; point the team to the current official guidelines to verify.
- If the description is too thin to audit (no controls, HUD, audio, text or difficulty details), ask for those first and stop; if only some are missing, audit what you have and list what you could not assess instead of guessing.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
## Summary
The core challenge, the three biggest barriers, and who they exclude.
## Barriers
Table: Area | Barrier | Where in the game | Guideline | Players affected | Severity (blocks play, major, minor).
## Recommended options
Table: Option | What it changes | Effort (S, M, L) and why | Priority (1 to 3).
## Quick wins
Five to eight changes that fit in one sprint.
## Playtesting
How to recruit disabled players, what to observe, and which barriers need their input before a final decision.
````
---
## Audit HTML email accessibility
`audit-html-email-accessibility` · prompt · Accessibility · https://hermes-ide.com/prompts/audit-html-email-accessibility
Audits HTML email code for screen-reader and low-vision problems specific to email clients, then returns fixed markup that still renders across Outlook, Gmail and Apple Mail.
````markdown
Email is the web from fifteen years ago with stricter rules. Layout still needs tables in many clients, CSS support varies by client, and some clients strip or rewrite `head` styles, `lang` and ARIA. Screen-reader users get the worst of it: every layout table read as a data table ("table with 3 columns, 12 rows"), images-off emails that read file names, "Click here" links, and a preheader that repeats as noise. Low-vision users hit 11 px text, light-grey footers, and dark-mode inversion that leaves dark logos on dark backgrounds. A good fix keeps rendering in Outlook for Windows, Gmail and Apple Mail, so it uses techniques email developers trust rather than web-only CSS.
Audit this transactional email:
[EMAIL_HTML]
Check, in this order:
1. Document: `` and `dir`, a meaningful ``, `meta charset`, and a wrapping element with `lang` and `dir` as well, because some clients drop the `html` attributes.
2. Layout tables: every table used for layout has `role="presentation"` (and no `summary`, `caption` or `th`). Real data tables, such as order line items, keep `th` with `scope`.
3. Reading order: the source order matches the visual order when columns stack on mobile and when read linearly.
4. Headings: real `h1` to `h3` for the main message and sections, styled inline, not bold `td` text.
5. Images: meaningful alt on every content image; `alt=""` on spacers and decorative images; no important text only in images (the order total, the reset link, the date); bulletproof (HTML and CSS) buttons instead of image buttons; styled alt text so the images-off view is still readable.
6. Links and buttons: link text that makes sense out of context ("Reset your password", not "Click here"); underlines or another non-colour cue in body text; tap targets at least 44 by 44 px for main actions.
7. Text: body at least 14 px (16 px preferred), line-height around 1.5, left-aligned body text, no all-caps paragraphs, contrast 4.5:1 including footer and legal text.
8. Dark mode: logos and icons on transparent backgrounds that disappear when inverted, colours forced by client inversion, `color-scheme` meta and `prefers-color-scheme` styles where supported.
9. Hidden content: the preheader is hidden from sight and from screen readers once read where possible, and invisible spacer characters are not read aloud as noise.
10. transactional-specific: for transactional mail, the action and key figures come first in text; for newsletters and marketing, a clear heading structure and an accessible unsubscribe link.
</task>
<constraints>
- Every fix must work in table-based email; do not suggest flexbox, grid or external CSS as the only fix. Note the clients where a fix degrades.
- Do not rewrite copy beyond link text and alt text; flag copy problems in one line.
- If the HTML is truncated or the templating hides structure, say what you could not check.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
</constraints>
<output_format>
## Summary
Two or three sentences: the most serious barriers and who they affect.
## Findings
Table: # | Issue | Who is affected | Location | Fix. Highest impact first, at most 15.
## Fixed HTML
The corrected email, complete, with brief comments at changed places.
## Test plan
Numbered: images-off view, a screen reader on at least one webmail and one desktop client, dark mode in Apple Mail and Outlook, 200% zoom on mobile, and a rendering test service run.
</output_format>
````
---
<a id="audit-motion-and-flashing"></a>
## Audit motion and flashing
`audit-motion-and-flashing` · prompt · Accessibility · https://hermes-ide.com/prompts/audit-motion-and-flashing
Audits animations, parallax, carousels and video for vestibular and seizure risk against WCAG 2.2.2, 2.3.1 and 2.3.3, then adds reduced-motion handling and pause controls.
````markdown
<context>
Motion can make people ill and flashing can cause seizures. Two groups are at risk: people with vestibular disorders, migraine or concussion, for whom parallax, large zooms, scroll-jacking and spinning transitions can trigger dizziness and nausea for hours; and people with photosensitive epilepsy, for whom flashes in the wrong frequency, size or colour can trigger a seizure. Common misses: treating `prefers-reduced-motion` as "turn off everything", which breaks loading feedback, or as "slow it down", which does not help; carousels that auto-advance with no pause; background video that loops forever; and saturated red flashes, which carry their own threshold.
</context>
<task>
Audit this web UI for motion and flashing risk:
<ui_code>
[UI_CODE]
</ui_code>
1. Inventory every effect: what moves or flashes, its trigger (load, scroll, hover, interaction, auto), area of the viewport, distance or scale, duration, repetition and whether it can be stopped.
2. Flashing (WCAG 2.3.1, level A): flag anything that flashes more than three times in any one-second period unless it is below the general and red flash thresholds. As a working rule, a flash covering more than about a quarter of a 10-degree field of view (roughly 341 x 256 px at typical viewing distance) or any saturated red flash is high risk. Say when a frame-by-frame measurement (for example with a photosensitive epilepsy analysis tool) is needed rather than guessing.
3. Auto-moving content (2.2.2, level A): anything that starts automatically, lasts more than 5 seconds and runs alongside other content needs pause, stop or hide. Auto-updating content needs pause or control of frequency.
4. Motion from interaction (2.3.3, AAA, but treat as required where it is large): parallax, zoom, scroll-linked and full-screen transitions can be disabled unless essential.
5. Classify each effect: essential (conveys information that cannot be conveyed another way, such as a progress indicator), functional (feedback that can be a cross-fade or colour change instead), or decorative (remove under reduced motion).
6. Fix with the platform API: CSS `@media (prefers-reduced-motion: reduce)` and `matchMedia` in script for web; `UIAccessibility.isReduceMotionEnabled` and its notification on iOS; `Settings.Global.ANIMATOR_DURATION_SCALE` or `ValueAnimator.areAnimatorsEnabled()` on Android; an in-game motion and flashing setting (camera shake, screen flashes, motion blur, field of view) that also reads the system setting where available. Replace motion with a fade or instant change rather than deleting feedback.
7. Add visible pause controls for carousels, background video and animated illustrations; stop animated GIFs or provide a still. Respect the user's choice across pages.
</task>
<constraints>
- Never declare content seizure-safe from code alone; say what to measure and with what kind of tool.
- Keep essential feedback such as loading and focus indicators, in a reduced form.
- If the description lacks size, speed or frequency for an effect, list the effect with "needs measuring" rather than inventing numbers.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
</constraints>
<output_format>
## Risk summary
Two or three sentences: the highest risk and who it affects.
## Findings
Table: Effect | Trigger | WCAG SC | Risk (seizure, vestibular, distraction) | Severity (blocker, serious, minor) | Essential, functional or decorative.
## Fixes
Code for web: the reduced-motion handling, pause controls and replacements, with comments.
## Checks
Numbered: turning on the system reduced-motion setting and expected result per effect, flash measurement if needed, and a check that the pause control is keyboard and screen-reader operable.
</output_format>
````
---
<a id="audit-motor-accessibility"></a>
## Audit motor accessibility
`audit-motor-accessibility` · prompt · Accessibility · https://hermes-ide.com/prompts/audit-motor-accessibility
Audits a web or mobile UI for people using voice control, switch access, head pointers or one hand, covering label-in-name, target size, gestures, dragging and timing, with code fixes.
````markdown
<context>
Keyboard access is necessary but not enough for people with motor disabilities. Voice-control users (Voice Control on iOS and macOS, Voice Access on Android, Dragon or Windows Voice Access on desktop) say what they see: "Tap Send". If the accessible name is "submit-btn-2" or "Paper plane icon", nothing happens. Switch users scan through every control one by one, so a screen with 60 focusable items is exhausting and a carousel that moves on its own is impossible. People with tremor or using a head pointer miss small, tightly packed targets and cannot complete precise drags, pinches or long presses. A good audit checks these specific barriers, not only tab order.
</context>
<task>
Audit this web UI for motor accessibility:
<ui_code>
[UI_CODE]
</ui_code>
1. List interactive elements with their visible label, accessible name, size and spacing (as far as the code shows).
2. Check, citing the criterion:
- Label in name (2.5.3): the accessible name contains the visible label text, ideally starting with it. Icon-only controls have a short name a user would guess and say ("Search", not "Magnifying glass").
- Target size (2.5.8, AA): at least 24 by 24 CSS px or enough spacing; recommend 44 by 44 pt on iOS and 48 by 48 dp on Android, and 44 by 44 px for primary web actions (2.5.5, AAA).
- Pointer gestures (2.5.1): multi-point or path-based gestures (pinch, two-finger swipe, swipe patterns) have a single-pointer alternative such as buttons.
- Dragging (2.5.7): every drag (reorder, slider, map pan, kanban move) has a non-drag alternative such as move up and down buttons or a menu.
- Pointer cancellation (2.5.2): actions fire on up-event, so a slip can be undone; no destructive action on down-event.
- Motion actuation (2.5.4): shake-to-undo or tilt has a button alternative and can be turned off.
- Timing (2.2.1): toasts with actions, auto-advancing content and timeouts are adjustable or long enough.
- Scanning load: the number of focus stops before the main action, repeated controls that could be combined, and a skip mechanism.
- Hover and long-press-only actions: provide a visible control or menu equivalent.
- Accidental activation: destructive actions are separated from frequent ones and confirm or undo.
3. Fix each issue with code for web: names (`aria-label` that starts with the visible text, `accessibilityLabel`, `contentDescription`), size via padding or hit-area extension without changing layout, alternatives for gestures and drags, `onClick` instead of `onPointerDown`, accessibility actions (`accessibilityCustomActions` on iOS, `AccessibilityAction` or Compose `customActions` on Android) for swipe-to-delete.
</task>
<constraints>
- Keep visual design where possible; enlarge hit areas before enlarging visuals.
- Do not remove gestures power users like; add alternatives.
- If sizes or names cannot be determined from the input, mark them "needs measuring" rather than guessing.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
</constraints>
<output_format>
## Summary
The two or three barriers that would stop a voice or switch user, in two to four sentences.
## Findings
Table: # | Element | Problem | WCAG SC | Who is affected (voice, switch, pointer, one-handed) | Severity.
## Fixes
Code for web, grouped by finding number.
## Test with assistive input
Numbered steps for the platform's voice control and switch access, plus a target-size check, with expected results.
</output_format>
````
---
<a id="audit-web-accessibility"></a>
## Audit web accessibility against WCAG 2.2
`audit-web-accessibility` · prompt · Accessibility · https://hermes-ide.com/prompts/audit-web-accessibility
Audits markup or components against WCAG 2.2 and reports each issue by success criterion with user impact, severity and a concrete code fix. Use before a release or a compliance review.
````markdown
<context>
An accessibility audit is useful when each finding names who is blocked, cites the exact success criterion, and comes with a fix a developer can paste. It is harmful when it pads the report with false positives, such as an `aria-label` "missing" on an element whose visible text already names it, or when it implies a page conforms because code review found nothing. Automated checkers catch only a minority of WCAG failures. Judgement and assistive-technology testing cover the rest.
</context>
<task>
Audit [TARGET] against WCAG 2.2 level AA.
1. Get the material. Read the code, or fetch and inspect the rendered page if given a URL. If you can only see part of it (one component, no CSS, no scripts), say so and limit your claims to that part.
2. Work through every criterion at the target level. These are the ones most often failed, grouped the way users meet them; also check media (1.2.x), timing (2.2.x), flashing (2.3.1), resize text (1.4.4) and input purpose (1.3.5) whenever the target contains them:
- **Perceivable:** text alternatives (1.1.1), info and relationships (1.3.1), meaningful sequence, use of colour (1.4.1), contrast (1.4.3, 1.4.11), reflow (1.4.10), text spacing (1.4.12), content on hover or focus (1.4.13).
- **Operable:** keyboard (2.1.1) and no keyboard trap (2.1.2), bypass blocks (2.4.1), page titled, focus order (2.4.3), link purpose, focus visible (2.4.7), focus not obscured (2.4.11), pointer gestures, dragging movements (2.5.7), target size minimum of 24 by 24 CSS pixels (2.5.8), label in name (2.5.3).
- **Understandable:** language of page, on focus and on input (3.2.1, 3.2.2), consistent help (3.2.6), error identification and suggestion (3.3.1, 3.3.3), labels or instructions (3.3.2), redundant entry (3.3.7), accessible authentication (3.3.8).
- **Robust:** name, role, value (4.1.2) and status messages (4.1.3). Note that 4.1.1 Parsing is obsolete in WCAG 2.2.
3. Confirm each suspected issue against the code before reporting it. Check what the accessibility tree would really expose: native semantics, ARIA overrides, and hidden or `inert` content.
4. Rate severity by user impact:
- **Blocker:** some users cannot complete the task.
- **Serious:** the task is possible only with great effort or a workaround.
- **Moderate:** a confusing or tiring experience.
- **Minor:** polish.
5. Write the fix for each issue as code in the target's own framework. Prefer native HTML over ARIA.
</task>
<constraints>
- Report only criteria at or below AA. Mention higher-level wins in one line at the end, if any.
- Never state or imply that the target "is compliant" or "conforms". Say what you checked and what you found.
- Group repeats of one root cause into a single issue that lists every location.
- Leave out personal opinions on visual design unless they map to a criterion.
- Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
- If the information you need is not available, say what is missing and how to get it instead of inventing it.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>
<output_format>
## Summary
Issue counts by severity, then the three changes that unblock the most users.
## Issues
Numbered, most severe first. Each one:
- **SC x.x.x Name (level)** — severity
- Where: `path:line` or selector
- Who is affected and what happens to them
- Fix: a code block
## Needs manual testing
What cannot be judged from the code alone, with the assistive technology or method to use (screen reader, 400% zoom, keyboard only, voice control).
## Not covered
Parts of the target you could not see or did not check.
</output_format>
````
---
<a id="build-aria-widget"></a>
## Build an accessible ARIA widget
`build-aria-widget` · prompt · Accessibility · https://hermes-ide.com/prompts/build-aria-widget
Implements a combobox, tabs, dialog, menu, disclosure, tree or listbox per the ARIA Authoring Practices pattern, using native elements whenever they suffice. Use for custom interactive widgets.
````markdown
<context>
The first rule of ARIA is not to use it when a native element does the job: WebAIM's yearly scans of the top million home pages keep finding more errors on pages that use ARIA than on pages that do not. When a custom widget is justified, it has to match the APG pattern exactly: the roles, the states that update as the user acts, and the keyboard model screen-reader users already know from desktop apps. Half a pattern, such as `role="menu"` without arrow-key support, is worse than plain buttons.
</context>
<task>
Build an accessible [WIDGET] in react.
Existing code or usage: [EXISTING_CODE] (if empty, build from scratch with a minimal, typical API).
1. **Decide native or custom first,** and state the decision:
- dialog: use `dialog` with `showModal()`. It provides the top layer, an inert background and Escape for free.
- disclosure: use `details` and `summary`, or a `button` with `aria-expanded` and `aria-controls`.
- listbox: use `select` unless options need rich content or multi-select with custom rendering.
- menu: `role="menu"` is for app-style command menus. For site navigation or a list of links, build a disclosure with links instead, and say so.
- combobox: a text `input` with a custom popup. `datalist` is acceptable only for simple suggestions.
- tabs and tree have no native equivalent, so build them custom.
2. If custom, implement the APG pattern completely:
- The roles and their required owned elements (`tablist` and `tab` with `tabpanel`; `tree`, `treeitem` and `group`; `combobox` and `listbox` with `option`).
- States kept in sync with the UI: `aria-expanded`, `aria-selected`, `aria-checked`, `aria-activedescendant`, `aria-controls`, and `aria-level`, `aria-setsize` and `aria-posinset` when items are virtualised.
- Accessible names for the widget and each item.
- One Tab stop for composite widgets, using roving `tabindex` or `aria-activedescendant`, with the APG keyboard model: arrow keys, Home and End, Escape, Enter and Space, and type-ahead where the pattern specifies it.
- Focus management on open and close: where focus goes, and where it returns.
3. For tabs, choose automatic or manual activation and justify it (manual when showing a panel is slow). For combobox, implement the ARIA 1.2 pattern, where `role="combobox"` sits on the input itself and `aria-autocomplete` matches the actual behaviour.
4. Reuse the project's existing components and styles. Make focus visible.
5. Write tests that query by role and accessible name (Testing Library style or the framework's equivalent), assert state attributes after interactions, and drive the keyboard model.
</task>
<constraints>
- Do not add ARIA that duplicates native semantics, such as `role="button"` on a `button`.
- Do not use `aria-hidden="true"` on anything focusable.
- If [WIDGET] is the wrong pattern for the described use, say so, recommend the right one, and build that instead.
- Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
- If the information you need is not available, say what is missing and how to get it instead of inventing it.
</constraints>
<output_format>
## Native or custom
The decision and why, in two or three sentences.
## Keyboard
| Key | Context | Result |
## Roles states and properties
| Element | Role | Attributes and when they change |
## Code
Each file in its own code block, headed by its path.
## Tests
Code, then one line per test.
## Manual checks
A short list to verify with NVDA plus Firefox or Chrome, and with VoiceOver plus Safari: what should be announced on focus and after each action.
</output_format>
````
---
<a id="build-accessible-media-player"></a>
## Build an accessible media player
`build-accessible-media-player` · prompt · Accessibility · https://hermes-ide.com/prompts/build-accessible-media-player
Builds or fixes a web video or audio player with captions, transcripts, audio description, operable controls and no autoplay traps, mapped to the WCAG 1.2 media criteria.
````markdown
<context>
Media accessibility has two halves that teams often confuse: the content (captions, transcripts, audio description) and the player (controls people can find, operate and understand). A perfect caption file is useless if the captions button is an unlabelled icon that keyboard users cannot reach; a polished custom player fails if there is no caption track. Common failures: custom controls built from `div`s, a single toggle that never exposes its pressed state, a volume slider with no value text, seek bars that only respond to dragging, autoplaying video with sound, captions burned into the video so they cannot be resized, and transcripts that leave out visual information. Native `video` controls are often the most accessible choice; replacing them takes real work to match.
</context>
<task>
Build or fix a video player using plain HTML and JavaScript.
<player_code>
[PLAYER_CODE]
</player_code>
If the code is empty, build a minimal custom player; otherwise fix the given one with the smallest change that meets the requirements.
1. Map the media requirements for video at WCAG 2.2 AA: captions for prerecorded (1.2.2) and live (1.2.4) audio; audio description for prerecorded video when visuals carry information not in the dialogue (1.2.5); a transcript for audio-only (1.2.1) and as good practice for all video; audio control for anything that plays sound for more than 3 seconds (1.4.2); pause for moving content over 5 seconds (2.2.2).
2. Tracks: load captions as `track kind="captions"` with `srclang` and `label`, WebVTT with speaker identification and sound cues ("[door slams]"). Use `kind="descriptions"` only if the player will voice it; otherwise provide a described version or extended audio description as a separate source. For live streams, name the real-time captioning path (CART or the streaming platform's live captions) rather than a file.
3. Controls: real `button` elements with accessible names for play or pause, mute, captions, audio description, transcript, fullscreen and settings; toggles expose state with `aria-pressed`, or swap the name ("Pause" or "Play"), never both. The seek and volume controls are native `input type="range"` or follow the ARIA slider pattern with `aria-valuetext` in human terms ("1 minute 32 seconds of 4 minutes 10 seconds", "Volume 60%"). Arrow keys seek in 5-second steps, Page Up and Page Down by 10 percent.
4. Keyboard and focus: every control reachable in a logical order; visible focus that contrasts 3:1; controls do not hide while one has focus; single-key shortcuts only while the player has focus (2.1.4); Escape exits fullscreen and focus returns to the fullscreen button.
5. Autoplay: no autoplay with sound. Muted autoplay only for short decorative loops, with a visible pause control, and none when `prefers-reduced-motion: reduce` is set.
6. Captions display: user-adjustable size and background contrast, captions positioned to avoid covering controls, no burned-in captions as the only option.
7. Transcript: an expandable or linked text transcript with speakers and important visual information, available without starting playback; optionally interactive, with timestamps that seek.
8. Do not announce time updates continuously; a live region is only for state changes the user triggered and cannot see.
</task>
<constraints>
- Prefer native media elements and controls; build custom controls only when the design requires it, and then meet every point above.
- Do not write caption, transcript or description content for media you have not been given; list what the team must produce and who usually does it.
- Do not invent player library APIs. If the library is unknown to you, ask for its docs or show the plain HTML approach.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
</constraints>
<output_format>
## Media requirements
Table: Requirement | WCAG SC | Applies to this video? (yes, no, depends with the reason) | Met by.
## Player code
Complete markup, script and CSS in plain HTML and JavaScript, with short comments at each accessibility decision. For a fix, a diff or the changed parts with context.
## Content the team must supply
Bullets: caption files per language, audio description script or described version, transcript, with format and quality notes (for example 99% accurate, speaker labels, sound cues, synchronised).
## Test checklist
Numbered: keyboard-only pass, screen reader pass with NVDA or VoiceOver hearing each control's name and state, captions on at 200% text size, reduced-motion setting, 320 px width, and automated scan.
</output_format>
````
---
<a id="fix-form-accessibility"></a>
## Build or fix an accessible form
`fix-form-accessibility` · prompt · Accessibility · https://hermes-ide.com/prompts/fix-form-accessibility
Builds or repairs a web form with programmatic labels, grouping, autocomplete, helpful error messages and announced validation. Use for sign-up, checkout, settings or any data-entry form.
````markdown
<context>
Forms are where accessibility failures cost the most: a person who cannot complete sign-up or checkout leaves. The recurring faults are a placeholder used as the only label, radio buttons with no group label, errors shown only in red, errors that are not announced or not tied to their field, focus left on the submit button after a failed submit, a disabled submit button that never says why, and password or one-time-code fields that block paste.
</context>
<task>
Build or repair this form (framework: [FRAMEWORK]; if empty, use plain HTML and minimal JavaScript):
[FORM]
1. If you were given code, list its barriers first, each with its WCAG criterion. If you were given a spec, skip to building.
2. **Labels and structure:**
- Every control has a visible `label` tied by `for` and `id`, or by wrapping. A placeholder is never the label.
- Related radios, checkboxes and multi-part fields (date of birth, address) sit in a `fieldset` with a `legend`.
- The label text matches the accessible name (2.5.3).
3. **Input purpose (1.3.5):** set `autocomplete` tokens for personal data (`name`, `given-name`, `email`, `tel`, `street-address`, `postal-code`, `cc-number`, `one-time-code`, `new-password`, `current-password`). Use the right `type` and `inputmode`: `type="email"` and `type="tel"`, and `inputmode="numeric"` instead of `type="number"` for codes and card numbers.
4. **Required fields and instructions:** use the native `required` attribute, plus a visible indicator that does not rely on colour alone. Tie format hints to their field with `aria-describedby`, and show them before the user types.
5. **Errors (3.3.1, 3.3.3):**
- Validate on submit, and on blur only for a field that already has an error.
- On a failed submit, either move focus to an error summary at the top that links to each field, or move focus to the first invalid field. Pick one and use it consistently.
- Each field error is text that says how to fix it ("Enter a date like 21/04/1990"), is linked by `aria-describedby`, and sets `aria-invalid="true"`. Clear it as soon as the input becomes valid.
- Announce async results (such as "username taken") through a polite live region that exists in the DOM before it changes.
6. **Do not** disable the submit button to signal invalid input. Do not block paste in password or code fields (3.3.8). Do not ask again for information already given in the same process (3.3.7). Keep targets at least 24 by 24 CSS pixels (2.5.8).
7. Keep the existing visual design and validation rules. Change only what accessibility requires, and say where it required a visible change.
</task>
<constraints>
- Native HTML first. Add ARIA only where HTML cannot express it.
- With a form library, use its own error and registration APIs rather than working around them.
- Do not invent validation rules the form or spec did not have. List any you think are missing in one line each.
- Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
- If the information you need is not available, say what is missing and how to get it instead of inventing it.
</constraints>
<output_format>
## Issues
| # | Problem | WCAG SC | Field or line | Fix |
Write "Built from spec" instead when no code was given.
## Code
The complete fixed or new form.
## Validation behaviour
Numbered: when validation runs, where focus goes, and what is announced.
## Test checklist
Keyboard-only and screen-reader checks for filling, failing, fixing and submitting the form.
</output_format>
````
---
<a id="fix-data-table-accessibility"></a>
## Fix data table accessibility
`fix-data-table-accessibility` · prompt · Accessibility · https://hermes-ide.com/prompts/fix-data-table-accessibility
Rebuilds a complex data table (grouped headers, sorting, sticky headers, row actions, responsive collapse) so screen readers announce each cell's context, with before and after markup.
````markdown
<context>
Admin panels and dashboards are full of tables that look fine and are unusable with a screen reader. The common failures: tables built from `div`s so table navigation keys do nothing; header cells that are plain `td` in bold; two-level headers with no association, so a cell reads "42" instead of "Q2, Returns, 42"; sort buttons that are clickable `th` elements with an arrow icon and no state; `aria-sort` placed on every column or on the button instead of the header; sticky headers built by cloning the header into a second table; row actions that all read "Edit, Edit, Edit"; and a mobile layout using `display: block` on table elements, which strips table semantics in several browsers. The fix is usually to return to a real `table` and add a few precise attributes, not to add a grid role.
</context>
<task>
Fix this table, written in html:
<table_code>
[TABLE_CODE]
</table_code>
1. Decide what the table is. A static or sortable data table stays a native `table`. Only an editable spreadsheet-like widget where users move cell by cell with arrow keys justifies `role="grid"`; say so if it does, and do not add it otherwise. Layout tables become CSS layout.
2. Structure: `caption` (visible, or visually hidden if a visible heading already names it, referenced rather than duplicated), `thead`, `tbody`, `tfoot` for totals, `th` for every header cell.
3. Header association: `scope="col"` and `scope="row"` for simple tables; `scope="colgroup"` with `colgroup` elements for grouped column headers; `headers` with ids only when cells relate to headers that scope cannot express (irregular or multi-level row headers). Make the first meaningful cell of each row a row header (`th scope="row"`), usually the name or id column.
4. Sorting: put a `button` inside the `th` containing the column label; set `aria-sort` (`ascending` or `descending`) on the currently sorted `th` only, and remove it from the others. Icons are `aria-hidden`. After a sort, announce the result once in a polite live region ("Sorted by Due date, ascending"). Keep focus on the button.
5. Row actions and selection: give each action a name with row context (visually hidden text or `aria-label` such as "Edit invoice INV-104"), and label row checkboxes the same way. The "select all" checkbox reflects the mixed state. Expandable rows use a `button` with `aria-expanded` and `aria-controls`.
6. Sticky headers: use `position: sticky` on `th` in the one table. Never clone the header row into a separate table.
7. Responsive: if the table collapses to cards, either keep table semantics and scroll horizontally in a focusable, labelled region (`tabindex="0"`, `role="region"`, `aria-labelledby` pointing at the caption), or render a real list of cards with the header text repeated as labels. If `display: block` or `grid` is set on table elements, restore roles explicitly (`role="table"`, `row`, `columnheader`, `cell`) and say why.
8. Large and paged data: state the total ("Showing 1 to 50 of 1,240") as text; for virtualised rows set `aria-rowcount` on the table and `aria-rowindex` on rows. Empty and loading states are text inside the table body, announced politely.
9. Keep the visual design, the public props and the data flow. Note any change you had to make to them.
</task>
<constraints>
- Prefer native table semantics. Never add `role="grid"`, `tabindex` on every cell or arrow-key handlers to a read-only table.
- Do not invent columns, data or library APIs. If the sort or paging code is missing and the fix depends on it, ask for it or mark the spot as [X].
- If the input is not a data table, say so and give the right structure instead.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
- Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
- If the information you need is not available, say what is missing and how to get it instead of inventing it.
</constraints>
<output_format>
## Diagnosis
Table: Problem | Effect for a screen-reader user | WCAG SC (1.3.1, 4.1.2, 1.3.2, 2.4.6 or 4.1.3) | Fix. At most 10 rows.
## Fixed markup
The corrected component in html, complete enough to paste. Mark changed lines with short comments.
## What a screen reader now announces
Three or four examples in a table: Action (for example "move down one cell in the Status column") | Before | After. Say these are typical, not exact, and vary by reader.
## Verification
Numbered checks a developer can run in ten minutes: table navigation keys in NVDA (Ctrl+Alt+arrows) and VoiceOver (VO+arrows), the browser accessibility tree for header association and `aria-sort`, a sort with the live announcement, 400% zoom, and one automated rule set to run in tests.
</output_format>
````
---
<a id="fix-keyboard-navigation"></a>
## Fix keyboard navigation in a component
`fix-keyboard-navigation` · prompt · Accessibility · https://hermes-ide.com/prompts/fix-keyboard-navigation
Finds and fixes keyboard barriers in a UI component (focus order, traps, invisible focus, mouse-only controls) and adds a keyboard test checklist. Use when a widget fails without a mouse.
````markdown
<context>
Keyboard access is the base layer for screen-reader users, switch and voice-control users, and people who cannot use a mouse. The barriers are usually small and mechanical: a `div` with a click handler, `outline: none` with no replacement, a positive `tabindex`, focus that falls to the top of the page when a dialog closes, a menu that opens only on hover, or a custom widget that ignores the arrow keys every other app uses for it.
</context>
<task>
Fix keyboard access in this component (widget type: [WIDGET_TYPE]; if empty, infer it from the code and say what you inferred):
[COMPONENT_CODE]
1. Trace the component as a keyboard user would: Tab into it, operate each control with Enter, Space, the arrow keys and Escape as its role demands, and Tab out. Note each place this fails.
2. Check for these, citing the WCAG criterion for each failure:
- Mouse-only controls (2.1.1): click handlers on non-focusable elements, hover-only reveals, drag-only actions without an alternative (2.5.7).
- Traps (2.1.2): focus that cannot leave, or a modal that lets focus escape behind it.
- Focus order (2.4.3): positive `tabindex`, DOM order that differs from visual order, and focusable elements that are hidden off-screen.
- Focus visible (2.4.7) and not obscured (2.4.11): removed outlines, focus hidden behind sticky headers.
- Focus management: where focus goes when content opens, closes, is deleted or loads.
- Composite widgets: the expected keys from the WAI-ARIA Authoring Practices for this widget type, with one Tab stop for the group using roving `tabindex` or `aria-activedescendant`.
- Single-character shortcuts (2.1.4) and context changes on focus (3.2.1).
3. Fix each barrier, preferring native elements: `button` and `a href` instead of handlers on `div`, `dialog` with `showModal()` for modals, and `inert` for background content. Use `:focus-visible` for focus styles with at least a 2 px outline that contrasts 3:1 with its surroundings.
4. Read keys with `event.key`, not the deprecated `keyCode`. Do not swallow Tab, and do not prevent default on keys you do not handle.
5. Keep the visual design and public API the same unless a fix requires a change. Note any change you had to make.
</task>
<constraints>
- Fix only keyboard and focus issues. List other accessibility problems you notice in one line each at the end.
- Never add `tabindex` greater than 0. Add `tabindex="0"` only to elements that need focus and have a role.
- Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
- If the information you need is not available, say what is missing and how to get it instead of inventing it.
</constraints>
<output_format>
## Barriers
| # | Problem | WCAG SC | Location | Fix |
## Fixed code
A unified diff against the given code, or the full component if the changes are extensive.
## Keyboard test checklist
| Step | Key | Expected result |
Covering entering, operating, leaving, and opening and closing every popup or dialog, ready for QA.
</output_format>
````
---
<a id="fix-spa-route-announcements"></a>
## Fix route changes in single-page apps
`fix-spa-route-announcements` · prompt · Accessibility · https://hermes-ide.com/prompts/fix-spa-route-announcements
Fixes silent navigation in client-side routed apps by managing focus, page titles, live announcements and scroll on route change, plus toasts and loading states.
````markdown
<context>
In a server-rendered site, following a link loads a new page: the browser resets focus, the screen reader announces the new title, and the user starts at the top. A client-side router swaps content without any of that. A screen-reader user activates a link and hears nothing; focus stays on a link that may no longer exist, or falls back to `body`; the tab title still names the old page; and a keyboard user has to tab through the whole header again. Toasts appear and vanish unheard, and spinners say nothing. The fix is small but must be consistent: one route-change handler in the app shell, not ad hoc code per page.
</context>
<task>
Fix route-change accessibility in this react app:
<router_code>
[ROUTER_CODE]
</router_code>
1. Describe what a screen-reader and keyboard user experiences today on a route change, based on the code.
2. Implement one route-change handler in the app shell, using the router's after-navigation hook (for example a location effect, `afterEach`, `NavigationEnd`, `afterNavigate`):
- Title: set `document.title` to "Page name - Site name" for every route, from route metadata, after data needed for the name has loaded.
- Focus: move focus to the new page's `h1` (with `tabindex="-1"` and no visible outline change on programmatic focus, or a subtle one), or to the `main` landmark if there is no heading. Do not move focus on the first page load, on query-string-only changes such as filters and sorting, or when a hash targets an in-page anchor.
- Announcement: if focus moves to the heading, the heading is read and no extra announcement is needed. If the design cannot move focus, announce "Navigated to Page name" in one persistent, visually hidden `aria-live="polite"` region that exists from the first render.
- Scroll: restore scroll on back and forward, go to top on new navigation, and let the focus move do the rest.
- Skip link: keep a "Skip to main content" link as the first focusable element and make sure it still works after route changes.
3. Async states: loading indicators announce "Loading results" politely only if loading takes longer than about one second, and the result is announced ("24 results"); errors use `role="alert"` sparingly. Toasts use a single polite live region, stay at least 5 seconds or until dismissed, never hold the only copy of important information, and pause on hover and focus; toasts with actions must be reachable or duplicated elsewhere.
4. Focus after in-page changes the router does not see: deleting an item, closing a modal, or submitting a form that replaces itself. Name where focus goes in each case.
5. Note framework built-ins that already do part of this (for example a framework route announcer) and do not duplicate them; if two announce, remove one.
</task>
<constraints>
- One live region per politeness level, created at startup. Never create a live region and fill it in the same tick.
- Do not use `role="alert"` or `aria-live="assertive"` for navigation.
- Do not invent router APIs; if the version is unclear from the code, ask or mark the hook as [check version].
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
</constraints>
<output_format>
## What users experience now
Three to five bullets.
## Fix
The route-change handler, the live region component and changes to the shell, in react, with comments.
## Async states
Code or rules for loading, results, errors and toasts, and focus after in-page changes as a table: Event | Focus goes to | Announcement.
## Test checklist
Numbered steps with NVDA or VoiceOver and keyboard only: follow a link, use back, change a filter, delete an item, trigger a toast; the expected announcement and focus for each.
</output_format>
````
---
<a id="frontend-accessibility-rules"></a>
## Frontend accessibility rules
`frontend-accessibility-rules` · rule · Accessibility · https://hermes-ide.com/prompts/frontend-accessibility-rules
Standing rules that make an assistant write accessible frontend code, with semantic HTML first, labels, keyboard and focus handling, contrast, motion and ARIA only where native elements fall short.
````markdown
Follow these rules for the rest of this conversation.
Apply these rules to files matching: `**/*.html`, `**/*.jsx`, `**/*.tsx`, `**/*.vue`, `**/*.svelte`, `**/*.astro`, `**/*.css`, `**/*.scss`.
When you write or change user interface code, follow these rules. They target WCAG 2.2 level AA. If a request conflicts with them (for example "remove the focus outline"), say what it breaks and offer an accessible alternative.
Structure and semantics
- Use the native element for the job: `button` for actions, `a href` for navigation, `input`, `select` and `textarea` for form controls, `table` for tabular data, lists for lists. Never put click handlers on `div` or `span` instead.
- Give each page one `h1` and headings that follow the content outline without skipping levels for styling. Use landmarks (`header`, `nav`, `main`, `footer`) once each where they apply.
- Set the `lang` attribute on the document and a unique, descriptive page title on each view, updated on client-side route changes.
Names, labels and text alternatives
- Every form control has a visible label tied to it (`label for`, or wrapping). Placeholders are not labels.
- Every interactive element has an accessible name; icon-only buttons get a text label or `aria-label`.
- Images get `alt` text that conveys their purpose; decorative images get `alt=""`. Do not start alt text with "image of".
- Form errors are shown in text next to the field, linked with `aria-describedby`, and the field is marked `aria-invalid`. Do not rely on colour alone to signal errors or state.
Keyboard and focus
- Everything that works with a mouse works with a keyboard, in a logical tab order. Do not use positive `tabindex`.
- Never remove focus indicators without a visible replacement; prefer `:focus-visible` styling with enough contrast.
- Dialogs move focus inside when opened, keep it there while open, close on Escape, and return focus to the trigger. On route changes, move focus to the new content or its heading.
- Interactive targets are at least 24 by 24 CSS pixels, or have enough spacing.
ARIA
- Use ARIA only when no native element or attribute does the job. Wrong ARIA is worse than none.
- When you build a custom widget (tabs, combobox, menu), follow the matching WAI-ARIA Authoring Practices pattern for roles, states and keys, and keep states such as `aria-expanded` and `aria-selected` in sync.
- Announce asynchronous results (saved, search results updated, errors) with a polite live region; do not announce every keystroke.
Visual design
- Text contrast is at least 4.5:1 (3:1 for large text), and UI components and focus indicators at least 3:1 against adjacent colours.
- Layouts reflow at 320 CSS pixels wide and at 200% zoom without horizontal scrolling or lost content. Never disable zoom in the viewport meta tag.
- Respect `prefers-reduced-motion`: no essential information conveyed only through animation, and no auto-playing motion longer than five seconds without a pause control.
Reporting
- Automated checkers catch only part of the problems. When your change adds or alters interactive behaviour, say which checks need a manual keyboard and screen reader pass.
````
---
<a id="make-generated-pdfs-accessible"></a>
## Make generated PDFs accessible
`make-generated-pdfs-accessible` · prompt · Accessibility · https://hermes-ide.com/prompts/make-generated-pdfs-accessible
Changes the code that generates invoices, statements or certificates so the PDFs come out tagged and PDF/UA-ready, with reading order, alt text, language and table headers checked in CI.
````markdown
<context>
Generated PDFs reach many people: every customer gets the statement, every student the certificate. Public-sector, banking and education buyers increasingly require them to be accessible (PDF/UA, ISO 14289, and WCAG 2.x applied to documents). Fixing one file by hand in an editor does not scale; the fix belongs in the generator. Experts know three things a naive answer misses: the library decides what is possible (some emit no tags at all, so the answer is to switch the rendering path, not to tweak markup); tags come from the source structure, so semantic HTML or the library's structure API matters more than visual layout; and an untagged PDF with perfect visual design is still an image of text to a screen reader.
</context>
<task>
Make this generator produce accessible PDFs.
<generator_code>
[GENERATOR_CODE]
</generator_code>
Library: [PDF_LIBRARY]. Document: [DOCUMENT_TYPE]. If either is empty, infer it from the code and say what you inferred.
1. Current state: identify what the output likely lacks: tag tree, document language, title shown in the window (`DisplayDocTitle`), logical reading order, headings, table headers, alt text, artifact marking for headers, footers and decoration, embedded fonts with Unicode mappings (so text extracts correctly), and form field labels if any.
2. Library capability: say plainly whether the library can emit tagged PDF and how. Typical paths: Chromium printing with tagged output enabled (`tagged: true` in Puppeteer or Playwright), WeasyPrint with its PDF/UA variant, iText or PDFBox with structure elements, PrinceXML or a typesetting engine with PDF/UA support. If the current library cannot tag, propose the smallest migration and its cost. Do not claim a flag or API exists unless you are sure; otherwise mark it [check docs].
3. Structure at the source: one `h1` (document title), headings in order, real `table` with `th` and `scope` for line items, `caption` or heading for each table, lists as lists, `lang` on the root and on any foreign-language passages, reading order equal to DOM order (no absolute positioning that reorders content), meaningful link text.
4. Images and visual content: logos and signatures get short alt text or are marked as artifacts if purely decorative; charts get alt text with the key figure plus a data table; QR codes get alt text that states the destination and a printed URL.
5. Repeating and decorative content: page headers, footers, page numbers, watermarks and rules are artifacts, not body content.
6. Metadata: title, language, PDF/UA identifier where the library supports it.
7. Add an automated check to CI: run veraPDF with the PDF/UA-1 profile (or the library's own validator) on sample outputs for each template, failing the build on errors. Use sample data that exercises page breaks, long names and empty sections.
8. Give the manual check: the PAC (PDF Accessibility Checker) report, reading order in a screen reader, and copying text to confirm characters extract correctly.
</task>
<constraints>
- Only change structure and metadata. Keep the visual layout unless it forces a wrong reading order; note any visual change.
- Never claim PDF/UA or WCAG conformance; automated validators catch only machine-checkable failures.
- Do not write alt text for images whose content you cannot see; add a field for it and say who supplies it.
- Ask for the template or a sample output if the code does not show the document structure.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
- Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
- If the information you need is not available, say what is missing and how to get it instead of inventing it.
</constraints>
<output_format>
## Current state
Table: Requirement | Likely status (missing, partial, present) | Evidence in the code.
## Library capability
Two to four sentences: can it tag, how, and any migration needed.
## Code changes
The changed template and generator code, with short comments.
## Automated check
The CI step and command, and which sample documents it runs on.
## Manual check
Numbered, five to eight steps, with what "pass" looks like.
</output_format>
````
---
<a id="make-data-visualization-accessible"></a>
## Make in-app charts accessible
`make-data-visualization-accessible` · prompt · Accessibility · https://hermes-ide.com/prompts/make-data-visualization-accessible
Fixes app charts (SVG, canvas or a chart library) with a text summary, data table fallback, keyboard exploration, non-colour encodings and contrast. Code fixes, not design critique.
````markdown
<context>
A chart in a dashboard is often the only place a number appears. For a screen-reader user, a canvas chart is a blank, and an SVG chart is either silent or a flood of hundreds of unlabelled paths and tick labels read in source order. For colour-blind users, five series in red, green and orange blend together, and the legend is the only key. For keyboard users, tooltips appear only on hover. The fix has layers: a short text summary of the insight (what a sighted reader takes away in five seconds), the full data in an accessible table, non-colour encodings, and, for exploratory charts, keyboard access to points. Some chart libraries have accessibility modules or options; use them when present, and do not rebuild what the library already does well.
</context>
<task>
Make this chart accessible. Library: [CHART_LIBRARY] (infer it from the code if empty).
<chart_code>
[CHART_CODE]
</chart_code>
1. Identify the chart's purpose: the one message (trend, comparison, distribution, part-to-whole) and whether users explore individual values or only read the overview.
2. Find the barriers: no text alternative; canvas with no fallback; SVG paths and ticks exposed as noise; colour as the only series distinction; series contrast below 3:1 against the background (1.4.11); text below 4.5:1; hover-only tooltips (1.4.13, 2.1.1); legend toggles that are not buttons; animation without reduced-motion handling; and live-updating charts that announce every tick.
3. Text alternative: wrap the chart in a `figure` with a `figcaption` containing a title and a one to three sentence summary of the key insight with the main figures, generated from the data so it stays true. The graphic itself gets `role="img"` with an `aria-label` that names the chart type and title, or is hidden from assistive technology when the summary and table carry everything.
4. Data table: provide the underlying data as a real `table` (visible, in a "Show data" disclosure, or linked), with header cells and units, and offer CSV download if the dashboard already has exports.
5. Non-colour encoding: direct labels on lines or bars where space allows, distinct marker shapes or dash patterns per series, and a palette that stays distinguishable for common colour-vision deficiencies. Keep 3:1 between adjacent series fills or separate them with borders.
6. Keyboard exploration (only when users need individual values): one Tab stop for the chart, arrow keys move between points or series, each point announces "Series, x label, value with unit", Escape leaves; tooltips appear on focus as well as hover and can be dismissed. Use the library's built-in keyboard module if it has one.
7. Interactions: legend toggles are buttons with `aria-pressed`; filters and zoom have keyboard equivalents; updates announce a summary change politely, not every data point.
8. Respect `prefers-reduced-motion` for entry animations.
</task>
<constraints>
- Do not redesign the chart type or message unless it blocks access; mention design issues in one line each.
- Generate summary text from the data at runtime; never hard-code numbers that will go stale.
- Do not invent library options; if unsure an option exists in this version, say [check docs] and show a library-independent fallback.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
</constraints>
<output_format>
## Barriers
Table: Barrier | Who is affected | WCAG SC | Fix.
## Fixed code
The updated component with the figure, summary, table fallback, encodings and keyboard support as needed, with comments.
## Text alternative
The example summary sentence this code would produce for the sample data, and the table headers.
## Checks
Numbered: screen reader pass over the figure and table, keyboard pass, a colour-vision simulator check, 200% zoom, and reduced-motion setting.
</output_format>
````
---
<a id="native-mobile-accessibility-rules"></a>
## Native mobile accessibility rules
`native-mobile-accessibility-rules` · rule · Accessibility · https://hermes-ide.com/prompts/native-mobile-accessibility-rules
Standing rules that make an assistant write accessible iOS, Android, React Native and Flutter UI code, with labels and traits, target sizes, text scaling, focus order and announcements.
````markdown
Follow these rules for the rest of this conversation.
When you write or change mobile UI code in SwiftUI, UIKit, Jetpack Compose, Android Views, React Native or Flutter, follow these rules. They target WCAG 2.2 AA as applied to mobile and the platform guidelines. If a request conflicts with them (for example "fix the font size so it never grows"), say what it breaks and offer an accessible alternative.
Names, roles and states
- Prefer standard platform controls (`Button`, `Toggle`, `Switch`, `TextField`, `Slider`) over tappable views; they bring roles, states and actions for free.
- Every interactive element has a concise name that matches its visible text: `accessibilityLabel` (SwiftUI, UIKit, React Native), `contentDescription` or `Modifier.semantics` (Android), `Semantics(label:)` or `tooltip` (Flutter). Do not include the role in the name ("Delete", not "Delete button").
- Expose the role and state when you build a custom control: `.accessibilityAddTraits(.isButton)` and `.isSelected`; `Role.Button` and `stateDescription`, `selected` and `toggleableState` in Compose; `accessibilityRole` and `accessibilityState` in React Native; `Semantics(button: true, selected:, checked:)` in Flutter.
- Hide purely decorative images and duplicate elements from assistive technology (`.accessibilityHidden(true)`, `contentDescription = null` with no click, `importantForAccessibility="no"` or `accessible={false}`, `ExcludeSemantics`).
- Group related pieces read as one item (a card with title, price and rating) so screen-reader users do not swipe five times per card: `.accessibilityElement(children: .combine)`, `Modifier.semantics(mergeDescendants = true)`, `accessible` on the container, `MergeSemantics`.
- Use hints only for non-obvious results, and keep them short.
Touch and input
- Touch targets are at least 44 by 44 pt on iOS and 48 by 48 dp on Android and Flutter, even when the icon is smaller; extend the hit area with padding, `minimumInteractiveComponentSize`, `hitSlop` or `contentShape`.
- Every swipe, long-press, multi-finger or drag action also exists as a visible control or a custom accessibility action (`accessibilityActions`, `customActions`, `CustomSemanticsAction`).
- Never rely on shake, tilt or timing alone; provide a button and let users turn motion triggers off.
Text and layout
- Use the platform text styles that scale with the user's font size (Dynamic Type text styles, `sp` units, React Native `allowFontScaling` left on, Flutter `TextScaler` respected). Never cap scaling to protect a layout.
- Layouts survive the largest accessibility text sizes: text wraps instead of truncating, stacks switch from horizontal to vertical, and scroll views wrap content that can grow.
- Text contrast is at least 4.5:1 (3:1 for large text), and icons and control borders at least 3:1, in light and dark mode.
- Never convey meaning by colour alone; pair it with text, an icon or a shape.
- Support both orientations unless the app's function needs one.
Focus, order and announcements
- Reading order follows the visual order; fix it with layout order first, then `accessibilitySortPriority`, `traversalIndex` or `OrdinalSortKey` only when needed.
- When a screen, sheet or dialog opens, move accessibility focus to its title or first meaningful element, and return it to the trigger when it closes (`AccessibilityFocusState`, `UIAccessibility.post(.screenChanged)`, `requestFocus` or `sendAccessibilityEvent`, `AccessibilityInfo.setAccessibilityFocus`).
- Announce asynchronous results that appear away from focus (saved, error, results loaded) with the platform announcement API or a polite live region (`accessibilityLiveRegion`, `liveRegion` in Compose), once, not repeatedly.
- Modals trap accessibility focus while open (`.accessibilityAddTraits(.isModal)`, `accessibilityViewIsModal`, `importantForAccessibility` on background, `BlockSemantics`).
- Support hardware keyboards and switch access: every control is focusable and operable without touch.
Motion and media
- Respect reduce motion (`accessibilityReduceMotion`, `ANIMATOR_DURATION_SCALE`, `AccessibilityInfo.isReduceMotionEnabled`, `MediaQuery.disableAnimations`).
- Video with speech has captions; autoplaying media is muted and can be paused.
Reporting
- When your change adds or alters interactive UI, say which screens need a manual VoiceOver and TalkBack pass and a check at the largest text size, because automated scanners and previews do not catch these reliably.
````
---
<a id="preview-screen-reader-announcements"></a>
## Preview screen reader announcements
`preview-screen-reader-announcements` · prompt · Accessibility · https://hermes-ide.com/prompts/preview-screen-reader-announcements
Predicts what a screen reader would announce as you tab and arrow through markup or a component, explains why, and flags confusing announcements. For learning, not a substitute for real testing.
````markdown
<context>
Developers who have never used a screen reader write markup by how it looks. They do not hear that an icon button reads "button" with no name, that `aria-label` on a `div` is often ignored, that a placeholder is a poor label, that `display: none` hides content from everyone while a `.sr-only` class hides it only from sight, or that "Read more, link" repeated ten times is useless when someone lists all links. Predicting the announcement teaches the model behind it: every element exposes a role, a name (computed by the accessible name algorithm: `aria-labelledby`, then `aria-label`, then native label or content, then `title`), states and a description. Screen readers then phrase and order these differently, and verbosity settings change the words, so a prediction is a teaching aid, not proof.
</context>
<task>
Preview what a generic screen reader user would hear for this markup:
<markup>
[MARKUP]
</markup>
1. Build the accessibility tree as a short indented outline: role, accessible name and where it came from, states (expanded, checked, selected, disabled, invalid, required, current), and description. Skip generic containers that are not exposed. Mark anything hidden (`hidden`, `display: none`, `aria-hidden="true"`, `inert`) and anything visually hidden but exposed.
2. Walk through it twice, as a user would:
- Tab order: each focusable element in order, with the announcement.
- Reading order (arrow keys or swipe): every exposed item, including headings, landmarks and plain text.
Write announcements in the typical form for generic (for example NVDA: "Search, edit, required"; VoiceOver: "Search, required, search text field"; TalkBack: "Search, edit box, required"). For generic, use "name, role, state".
3. Mention the quick-navigation lists a user would see: headings list, landmarks, links list, form fields.
4. Explain each announcement that would surprise a sighted developer, in one or two sentences: why it sounds that way and which rule or attribute causes it.
5. Flag problems in plain language: missing or duplicate names, names that do not match the visible label, roles that lie about behaviour, missing states, content read twice, important content hidden, and noise (decorative icons or emoji read aloud). Give the minimal fix for each.
</task>
<constraints>
- Do not claim exact output: wording, punctuation and order vary by reader version, browser and verbosity settings. Say so once, not on every line.
- Explain in plain words; define role, name and state the first time you use them.
- If behaviour depends on script you cannot see (for example a state that changes on click), describe the state before and after and say what you assumed.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
</constraints>
<output_format>
## Accessibility tree
An indented outline, at most 30 lines.
## Announcements
Table: Step | Key (Tab, Down arrow, swipe) | Announcement | Why.
## What sounds wrong
Numbered: problem, who it confuses, minimal fix as a code snippet.
## Try it for real
Three to five steps to check the prediction with the real generic screen reader (or NVDA on Windows and VoiceOver on macOS for generic): how to start it, the keys to use, and the browser's accessibility inspector.
</output_format>
````
---
<a id="prioritize-accessibility-findings"></a>
## Prioritise accessibility findings
`prioritize-accessibility-findings` · prompt · Accessibility · https://hermes-ide.com/prompts/prioritize-accessibility-findings
Turns a long external accessibility audit into a fix plan that deduplicates by shared component, ranks by impact on key journeys, and groups work into sprints with design-system fixes first.
````markdown
<context>
An external audit often arrives as a spreadsheet with hundreds of findings, ordered by page. Teams that fix them in that order burn months fixing the same button forty times, polish low-traffic pages while checkout stays blocked, and lose momentum. An experienced accessibility lead first collapses findings to root causes (one `IconButton` without a name may be 120 findings), then ranks by who is blocked on which journey, then puts fixes in the design system or shared layout ahead of page-level patches, and finally plans a retest so the fixes are confirmed rather than assumed.
</context>
<task>
Build a fix plan from these findings:
<audit_findings>
[AUDIT_FINDINGS]
</audit_findings>
If key journeys are not given, infer them from the page names (sign-in, search, checkout, forms usually) and list them under Needs a decision for confirmation. If capacity is not given, plan in three tiers (Now, Next, Later) instead of sprints and ask for team size, availability and any deadline.
1. Normalise: count findings, by WCAG criterion and by auditor severity. Note duplicates and anything unclear or likely a false positive (for example a contrast failure on disabled controls, which WCAG exempts); list those for the auditor rather than dropping them silently.
2. Find root causes: group findings that share a component, template, design token or content pattern. For each group, name the likely shared source and the number of findings it would clear. Distinguish code fixes from content fixes (alt text, captions, link text) that need authors.
3. Rank each root cause with a simple score, and show it:
- Impact: blocker (a user cannot complete a key journey), serious (completes with major difficulty), moderate, minor.
- Reach: key journey or high-traffic page versus rare page.
- Breadth: number of findings and pages cleared.
- Effort: S (under a day), M (a few days), L (a sprint or more), stated as an assumption.
Blockers on key journeys come first regardless of effort; then high breadth with low effort.
4. Plan sprints (or tiers) within the stated capacity: sprint 1 removes journey blockers and quick shared fixes; later sprints work down the ranking. Put design-system fixes before page fixes that depend on them. Include regression protection (a lint rule or component test) for each shared fix.
5. If the capacity cannot meet the deadline, say so with the numbers and offer the trade-off (which items move, or what extra capacity is needed). Do not shrink estimates to fit.
6. Plan the retest: which items to verify internally, which to send back to the auditor, and when.
</task>
<constraints>
- Do not re-audit or invent findings; work only from the list. If the list lacks pages or criteria, say what is missing and how it limits the plan.
- Do not assess legal risk or compliance status. Where the user mentions a legal or contractual deadline, plan to it and suggest they confirm scope with whoever owns compliance.
- Effort estimates are assumptions for the team to correct; label them so.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>
<output_format>
## Summary
Four to six sentences: total findings, number of root causes, the blockers, and whether the deadline is realistic.
## Root causes
Table: # | Root cause and likely source | Findings cleared | Journeys affected | Impact | Effort | Score. At most 15 rows, highest score first; group the remaining low-impact items into one final row with their count.
## Sprint plan
Per sprint or tier: goal, items (root cause numbers), owner type (frontend, content, design), and regression protection.
## Needs a decision
Bullets: questionable findings for the auditor, content work needing owners, third-party components to raise with vendors.
## Retest plan
Bullets: what is verified, by whom and when.
</output_format>
````
---
<a id="review-cognitive-accessibility"></a>
## Review cognitive accessibility
`review-cognitive-accessibility` · prompt · Accessibility · https://hermes-ide.com/prompts/review-cognitive-accessibility
Reviews a built flow against the WCAG 2.2 cognitive criteria and W3C COGA patterns, covering login, time limits, redundant entry, errors and plain language, with code and copy changes.
````markdown
<context>
People with learning disabilities, dementia, ADHD, brain injury, anxiety or low literacy, and anyone tired, stressed or using a second language, fail at the same places: a login that requires remembering or transcribing something, a session that expires mid-form, a form that asks again for what it already knows, an error message that blames without explaining, help that moves around, and dense jargon. WCAG 2.2 made several of these testable (3.3.7 Redundant Entry, 3.3.8 Accessible Authentication (Minimum), 3.2.6 Consistent Help), alongside older criteria such as 2.2.1 Timing Adjustable and 3.3.4 Error Prevention. The W3C COGA guidance ("Making Content Usable for People with Cognitive and Learning Disabilities") goes further with design patterns. A useful review cites both and returns concrete changes, not "simplify the language".
</context>
<task>
Review this flow for cognitive accessibility. Users: general public.
<flow_description>
[FLOW_DESCRIPTION]
</flow_description>
1. Walk the flow step by step as a user with limited working memory, slow reading and high anxiety would, noting where they must remember, calculate, transcribe, decode or hurry.
2. Check the testable criteria and record pass, fail or cannot tell:
- 3.3.8 Accessible Authentication: no cognitive function test (remembering a password, transcribing a code, solving a puzzle) unless an alternative or mechanism exists. Password fields allow paste and password managers (`autocomplete="current-password"`, `one-time-code`), passkeys or email links are offered, and image CAPTCHAs have an alternative.
- 3.3.7 Redundant Entry: information already given in this process is filled in or selectable.
- 2.2.1 Timing Adjustable: a warning at least 20 seconds before timeout with a simple way to extend, or no limit; 2.2.6 for data loss on timeout.
- 3.2.6 Consistent Help: contact or help in the same relative place on every page.
- 3.3.1, 3.3.3 and 3.3.4: errors identified in text, with a suggestion, and review, confirm or undo for legal, financial or data-changing actions.
- 3.2.3 and 3.2.4: consistent navigation and naming.
3. Check COGA patterns that are not WCAG requirements but matter: one main task per page, clear step indicator, plain language (short sentences, common words, active voice, no idioms), numbers and dates in familiar formats, critical information not only in icons, no distracting motion or pop-ups, saved progress, clear purpose of each page in its heading.
4. For each problem, write the change: replacement copy for headings, labels, instructions and errors; code changes for authentication, autocomplete, timeouts and pre-filled fields; and flow changes such as splitting a step.
5. Rank by the chance a user gives up or makes a costly mistake.
</task>
<constraints>
- Rewrite copy in the product's voice and keep legal or regulatory wording intact; where wording is mandated, add a plain-language explanation next to it instead.
- Do not remove security controls; propose accessible alternatives that keep the same assurance (passkeys, magic links, copy-pastable codes, non-puzzle bot checks).
- Do not invent details of the flow; mark anything you could not assess as "cannot tell" and say what is needed.
- Do not speculate about individual users' diagnoses.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
</constraints>
<output_format>
## Summary
The two or three places users are most likely to give up, in plain words.
## Findings
Table: # | Step | Problem | Criterion (WCAG SC or COGA pattern) | Pass, fail or cannot tell | Impact.
## Changes
Numbered, matching findings: before and after copy, or the code change, ready to paste.
## Test with people
Who to recruit, three tasks to give them, and what to observe.
</output_format>
````
---
<a id="review-color-contrast"></a>
## Review colour contrast and fix the palette
`review-color-contrast` · prompt · Accessibility · https://hermes-ide.com/prompts/review-color-contrast
Checks colour pairs or design tokens against contrast requirements and proposes the nearest passing alternatives that keep the brand hue. Use when defining or auditing a palette or theme.
````markdown
<context>
Contrast reviews go wrong in three ways: the ratio is estimated by eye instead of computed, a 4.47:1 result is rounded up to "4.5, passes", and the suggested fix swaps the brand colour for a generic grey or breaks three other pairs that share the token. The useful answer is exact numbers, the smallest change that passes, and a check that the change holds everywhere the token is used.
</context>
<task>
Check this palette against wcag2-aa:
[PALETTE]
Usage: [USAGE] (if empty, test every plausible foreground against every background, and say that you assumed the usage).
1. Normalise every colour to sRGB hex. Composite any translucent colour over the background it actually sits on before measuring, and show the composited hex. If that background is unknown, composite it over every background in the palette it could sit on, report the worst result, and say so.
2. Compute, do not estimate. If you can run code, do. Otherwise show the working for at least the failing pairs.
- **WCAG 2:** relative luminance from linearised sRGB channels (threshold 0.04045, then `((c + 0.055) / 1.055) ^ 2.4`, weighted 0.2126 R + 0.7152 G + 0.0722 B), then ratio = (L1 + 0.05) / (L2 + 0.05). Truncate to two decimals; never round up to a pass.
- **Thresholds:** wcag2-aa needs 4.5:1 for normal text and 3:1 for large text (at least 24 px, or 18.66 px bold) and for UI components and meaningful graphics (SC 1.4.11). wcag2-aaa needs 7:1 and 4.5:1 for text; non-text stays 3:1.
- **APCA:** report the signed Lc value (polarity matters) and judge it against the usage's font size and weight. Lc 75 is the usual minimum for body text, 90 preferred; lower values apply only to larger or bolder text. APCA cannot be done reliably by hand: if you cannot run the APCA-W3 algorithm in code, give an approximate Lc marked "≈", say so in Notes, and also report the WCAG 2 ratio. Say clearly that APCA is not a WCAG 2 conformance test.
3. For every failing pair, propose fixes that keep the hue: adjust lightness in OKLCH, holding hue fixed and reducing chroma only if the colour leaves the sRGB gamut, until the pair just passes. Offer both directions (darken the foreground, or lighten or darken the background) when both are viable, and name the one that changes the brand less.
4. Re-check each proposed colour against every other pair that uses the same token, and report any new failure. A token that is both a background for light text and a foreground on a dark surface can be pulled in opposite directions; when no single value passes both, say so and propose splitting the token.
5. If the palette has no text colours or no background colours, or the usage is too vague to tell text from UI, ask instead of guessing.
</task>
<constraints>
- Never mark a pair as passing on a rounded value.
- Do not judge aesthetics. Do not change colours that already pass unless a shared token forces it.
- Disabled controls and pure decoration are exempt from WCAG 2 contrast. Mark them exempt, not failing, and only when the usage says so.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>
<output_format>
## Results
| Foreground | Background | Usage | Ratio or Lc | Required | Result (pass / fail / exempt) |
## Fixes
| Token | Original | Proposed | New ratio or Lc | Direction | Other pairs affected |
## Notes
Assumptions, any translucent colours, and the method used (computed by code or by hand).
</output_format>
<examples>
<example>
`#777777` text on `#FFFFFF`, 16 px regular, wcag2-aa: ratio 4.47:1 (4.478 truncated), fails (needs 4.5:1). Nearest fix keeping the neutral hue: `#767676` gives 4.54:1, passes.
</example>
</examples>
````
---
<a id="set-up-automated-accessibility-checks"></a>
## Set up automated accessibility checks
`set-up-automated-accessibility-checks` · prompt · Accessibility · https://hermes-ide.com/prompts/set-up-automated-accessibility-checks
Adds layered automated accessibility checks to a web or mobile project (editor lint, component tests, CI page scans with a baseline) and states what automation cannot catch.
````markdown
<context>
Automated checks catch a meaningful share of accessibility issues (missing names, invalid ARIA, contrast, missing labels and alt attributes) cheaply and early, and stop regressions. They also fail in predictable ways when set up badly: a CI scan added to an app with 400 existing violations blocks every merge on day one, so someone disables it; scans that only load the page miss everything behind a click; snapshot-style assertions break on every copy change; and a green check is taken as proof of accessibility. Experienced teams layer the checks (editor, component, page), scan interactive states, use a baseline so only new violations fail, and write down what still needs manual testing.
</context>
<task>
Set up automated accessibility checks for: [TECH_STACK]. CI: [CI_SYSTEM] (generic job if empty).
1. Choose layers that fit the stack and say what each catches:
- Editor and lint: for example `eslint-plugin-jsx-a11y` (React), `eslint-plugin-vuejs-accessibility`, `@angular-eslint` template accessibility rules, Svelte's built-in a11y warnings; Android Lint accessibility checks; SwiftLint has little here, so lean on tests for iOS.
- Component tests: an accessibility engine on rendered components (for example axe-core via `jest-axe` or `vitest-axe`, or Storybook's accessibility addon in test runs); for mobile, the Accessibility Test Framework (Espresso `AccessibilityChecks.enable()`) or `XCUIApplication().performAccessibilityAudit()` on recent Xcode.
- Page or flow scans: axe-core in Playwright or Cypress end-to-end tests, run on key routes and in key states (menu open, dialog open, form errors shown, dark mode, narrow viewport), or a crawler such as pa11y-ci for many static pages.
2. Write the configuration and one example test per layer, following the existing test style. Pin the WCAG tags to scan (for example `wcag2a`, `wcag2aa`, `wcag21aa`, `wcag22aa`) and say how to add best-practice rules separately.
3. Baseline: record current violations by rule and target, fail CI only on new ones, and print the remaining count so it trends down. Never hide violations with blanket rule disables; any disable needs a comment with the reason and an issue link.
4. Rollout: start the page scan as non-blocking for one or two weeks, fix the top shared-component violations, then make it blocking. Keep runtime reasonable (parallelise or limit to key routes).
5. Reporting: make failures readable in CI (rule, element, help link) and attach artifacts.
</task>
<constraints>
- Use only tools and APIs you are confident exist for this stack; mark anything uncertain [check version].
- Do not claim that passing these checks means conformance. Be explicit about the gap.
- Fit the existing test setup; do not introduce a second test runner unless there is none.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
- Before saying the work is done, run the check that proves it (tests, build, type check or the command the user gave) and report the real result.
- If you could not run a check, say so plainly and say which one.
</constraints>
<output_format>
## Layers
Table: Layer | Tool | Runs when | Catches | Misses.
## Configuration
Install commands, config files and one example test per layer, plus the CI job.
## Baseline and rollout
The baseline mechanism with code, and a dated rollout plan in weeks.
## What automation misses
Bullets of what still needs manual or assistive-technology testing (meaningful alt text and names, focus order and management, screen reader announcements, reflow and zoom, cognitive load, captions quality), and how often to do it.
</output_format>
````
---
<a id="write-screen-reader-test-plan"></a>
## Write a screen-reader test plan
`write-screen-reader-test-plan` · prompt · Accessibility · https://hermes-ide.com/prompts/write-screen-reader-test-plan
Writes a manual screen-reader test script for a user flow on NVDA, JAWS, VoiceOver or TalkBack, with keystrokes and expected announcements per step. Use before releasing a key flow.
````markdown
<context>
Testers new to screen readers tend to Tab through a page and call it done. Real users navigate by headings, landmarks, form fields and lists. They switch between browse and focus modes, swipe through items on mobile, and depend on announcements for anything that changes without focus moving. Exact speech also varies by screen reader, version, browser and verbosity setting. A useful script therefore names the gesture or keystroke for each step and states the expected announcement as its required parts (name, role, state, value) rather than one exact string.
</context>
<task>
Write a manual screen-reader test script for this web flow:
[FLOW]
Screen readers requested: NVDA, VoiceOver, TalkBack.
1. Build the test matrix. Pair each screen reader with the browser or platform it is mainly used with: NVDA with Firefox or Chrome on Windows, JAWS with Chrome or Edge, VoiceOver with Safari on macOS, VoiceOver on iOS with Safari or the app, TalkBack with Chrome or the app on Android. Drop any that do not run on web and say so.
2. Write the setup: the versions to record, default verbosity, the speech viewer or log to turn on (NVDA Speech Viewer, VoiceOver caption panel, TalkBack's developer setting for speech output), and resetting state between runs.
3. Start with orientation checks before the flow: the page or screen title is announced, the headings outline makes sense (H key or the rotor), landmarks are present and labelled, and the language is announced correctly.
4. For each step of the flow, write:
- the action in each screen reader's own terms: NVDA and JAWS keys (H, D or R for landmarks, F for form fields, Tab, Enter, Space, Insert+F7 or Insert+F6 lists), VoiceOver keys (VO+Right Arrow, VO+Space, the rotor) or gestures (swipe right, double-tap, the rotor), and TalkBack gestures (swipe right, double-tap, reading controls);
- the expected announcement as name, role, state and value, for example "Email, edit text, required, invalid entry";
- the dynamic behaviour to confirm, such as where focus lands after a dialog opens or closes, a live-region announcement for async results, errors announced and linked to their field, and a loading state that is announced and then cleared;
- the pass criterion and the WCAG success criterion it maps to.
5. Add negative checks: every control is reachable with the screen reader's standard navigation, not only by mouse or by touch exploration, decorative images are silent, and hidden content is not read out.
6. If the flow description leaves out what happens at a step (validation, a success message, a redirect), list it under Coverage gaps instead of inventing behaviour.
</task>
<constraints>
- Do not claim an exact announcement string unless the flow specifies the label text. Expected speech is the components, in any order the screen reader uses.
- Keystrokes must be real for the named screen reader. If unsure of one, say so rather than guess.
- Keep each step to one action, so a failure points to one place.
</constraints>
<output_format>
## Setup
| Screen reader | Browser or app | Platform | Settings to record |
Then the setup and reset steps.
## Test script
For each step:
| Step | Action (per screen reader) | Expected announcement | Also check | Pass criterion | WCAG SC |
Orientation checks come first.
## Defect template
Fields to fill for a failure: step, screen reader and version, browser, actual speech (copied from the log), expected, and severity.
## Coverage gaps
Unspecified behaviours and parts of the flow not covered.
</output_format>
````
---
<a id="write-accessibility-acceptance-criteria"></a>
## Write accessibility acceptance criteria
`write-accessibility-acceptance-criteria` · prompt · Accessibility · https://hermes-ide.com/prompts/write-accessibility-acceptance-criteria
Turns a user story or design into testable accessibility acceptance criteria per component, mapped to WCAG success criteria, so QA and developers can check them before merge.
````markdown
<context>
Most accessibility bugs are designed in or built in, then found in an audit months later, when they cost ten times more to fix. Teams that write accessibility acceptance criteria on the ticket catch them before merge. Bad criteria fail in two ways: "Must be accessible" or "Meets WCAG 2.2 AA" (untestable; nobody knows what to check), and a pasted list of all 55 success criteria on every ticket (noise; ignored by the second sprint). Good criteria are specific to the components in this story, written as observable behaviour a tester can pass or fail with a keyboard, a screen reader and browser zoom, and each traces to a success criterion.
</context>
<task>
Write accessibility acceptance criteria for this story at WCAG 2.2 level AA:
<story>
[STORY]
</story>
1. List the components and states in the story: each control, form field, dynamic region, dialog, image, media and message, and the states it passes through (empty, loading, error, success, disabled).
2. For each component, write only the criteria that apply, as Given/When/Then or short "Then" statements a tester can verify. Cover the relevant areas:
- Keyboard: reachable, operable with the expected keys, logical order, no trap, visible focus, where focus goes after the action.
- Name, role, state: what a screen reader announces, written as the expected announcement ("Announced as 'Delivery date, edit text, required'").
- Announcements: what is announced on async changes, errors and success, and with what politeness.
- Visual: text contrast 4.5:1, non-text contrast 3:1, no meaning by colour alone, target size at least 24 by 24 CSS px, reflow at 320 px and 400% zoom, text spacing.
- Motion and time: reduced-motion behaviour, no time limits or adjustable ones.
- Forms: visible labels, instructions, error identification and suggestion, no redundant entry, accessible authentication if a login or code is involved.
- Content: alt text required for which images, captions or transcript for which media, headings and page title.
- If the level is AAA, add the AAA criteria that apply (for example 7:1 contrast, 44 by 44 px targets, no timing, re-authentication without data loss).
3. Give every criterion an id (AC-1, AC-2), the WCAG success criterion number, and how to test it (keyboard, screen reader, zoom, contrast tool, automated).
4. Mark which criteria an automated test can enforce and which need a manual check.
5. List what the story does not specify but must decide (for example the error message wording or where focus lands after saving) as questions, not assumptions.
</task>
<constraints>
- Write criteria only for components in the story. No generic WCAG checklist.
- Each criterion is pass or fail by observation; no "should be easy to use".
- Do not invent product behaviour the story does not describe; ask in Questions.
- At most 25 criteria; if the story needs more, say it should be split.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
</constraints>
<output_format>
## Components found
Bullets: component and its states.
## Acceptance criteria
Grouped by component. Table per component: ID | Criterion | WCAG SC | How to test | Automatable (yes or no).
## Out of scope
One line each: related checks that belong to other tickets (for example site-wide header).
## Questions
Numbered decisions the product owner or designer must make.
</output_format>
````
---
<a id="write-alt-text"></a>
## Write alt text for images
`write-alt-text` · prompt · Accessibility · https://hermes-ide.com/prompts/write-alt-text
Writes context-aware alt text for images on a page or in a document, or marks them decorative, following the W3C alt decision tree. Use when publishing images on the web.
````markdown
<context>
Alt text is not a description of the picture. It is the text that replaces the picture for someone who cannot see it, so it depends on why the image is there. The same photo of a laptop needs different alt text on a product page, in a news story about a data breach, and as a decorative header. Common failures: "image of...", file names, repeating the caption, describing a linked logo instead of where the link goes, and long descriptions of decoration that make screen-reader users wade through noise.
</context>
<task>
Write alt text for these images:
[IMAGES]
Page context:
[PAGE_CONTEXT]
For each image, walk the W3C alt decision tree in this order, stop at the first branch that applies, and record it:
1. **Inside a link or button, or the only content of one?** The alt describes the destination or action ("Acme home", "Search"), not the picture, and includes any text the image shows (label in name, WCAG 2.5.3). If the link or button already has visible text that says the same, the image is redundant: use `alt=""`.
2. **Contains text?** If the same text is already next to the image, use `alt=""`. If the text is only a visual effect, use `alt=""`. Otherwise the alt is that text.
3. **Adds meaning to the content?** Write a short alt that conveys what the image contributes here, in this context.
4. **Complex (chart, diagram, map, infographic)?** Write a short alt with the key takeaway, then a long description or data table to place on the page or link to.
5. **Decorative or redundant with nearby text?** Use `alt=""`. Do not omit the attribute.
Writing rules:
- Stay within about 125 characters. If you need more, the image is complex: use branch 4.
- Do not start with "image of" or "picture of". Name the medium only when it matters ("Oil painting of...", "Screenshot of the settings page...").
- Put the most important information first, end with a full stop, and match the page's language.
- Describe people only by attributes that matter to the content. Do not guess identity, gender, ethnicity, age or disability unless the context establishes it and it matters.
- No keyword stuffing, and no repeating the caption or the surrounding sentence.
- If you cannot see an image and its description is too thin to know what it shows or why it is there, ask instead of inventing details.
</task>
<constraints>
- Never invent text, numbers or details that are not visible in the image or stated in its description.
- For charts, give the trend or comparison that matters, not every data point; put the data in the long description.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>
<output_format>
## Alt text
| # | Image | Branch (functional / text / informative / complex / decorative) | alt | Long description needed? |
Write each alt value exactly as it should appear in quotes, including `""` for decorative images.
## Markup
An HTML snippet per image with the alt in place, plus `figure` and `figcaption` or a linked long description where branch 4 applied.
## Questions
What you need to finish any image you could not do, or "None".
</output_format>
<examples>
<example>
Image: company logo reading "Northwind", wrapped in a link to the home page. Context: site header.
Branch: functional. alt: "Northwind home"
Image: line chart of monthly sign-ups rising from 1,200 in January to 4,800 in June. Context: quarterly report, paragraph says "growth accelerated".
Branch: complex. alt: "Monthly sign-ups quadrupled from 1,200 in January to 4,800 in June." Long description: a table of the six monthly values.
Image: abstract gradient behind the page title.
Branch: decorative. alt: ""
</example>
</examples>
````
---
<a id="write-accessibility-conformance-report"></a>
## Write an accessibility conformance report
`write-accessibility-conformance-report` · prompt · Accessibility · https://hermes-ide.com/prompts/write-accessibility-conformance-report
Writes an accessibility conformance report (ACR) in the VPAT format from audit results, with a conformance level and specific remarks per criterion. Use when customers or procurement ask for a VPAT.
````markdown
<context>
An Accessibility Conformance Report is a vendor's statement of how a product meets an accessibility standard, usually written on the VPAT template. Buyers read the remarks, not just the levels. Reports lose credibility (and can create legal exposure) when they claim "Supports" for criteria that were never tested, use vague remarks like "mostly accessible", omit the evaluation methods, or quietly drop known failures. The VPAT conformance terms are fixed: Supports, Partially Supports, Does Not Support, Not Applicable, and Not Evaluated (allowed only for Level AAA criteria in the WCAG tables).
</context>
<task>
Write an accessibility conformance report for [PRODUCT] on the current VPAT template, edition: wcag (wcag, section-508, en-301-549 or international). Use these results:
<audit_results>
[AUDIT_RESULTS]
</audit_results>
1. If the audit does not say which WCAG version and level were tested, or what was in scope, ask and stop. Default to WCAG 2.2 Level A and AA if the user confirms no preference.
2. Fill the report header: product name and version, report date, description, contact placeholder, evaluation methods (tools, manual testing, assistive technologies with versions, and who tested), and the applicable standards for the edition.
3. For every success criterion at the levels in scope, in WCAG order, assign one conformance term:
- **Supports**: tested, and no failures found.
- **Partially Supports**: some functionality fails; name where.
- **Does Not Support**: most or all functionality fails.
- **Not Applicable**: the product has no content the criterion covers (for example no audio, no video); say why.
Criteria the audit did not cover are not marked Supports: put `[NOT YET EVALUATED]` in the conformance cell and list them under Gaps before publishing, so the report cannot be published as finished. For WCAG 2.2, 4.1.1 Parsing is obsolete; follow the template's note for it instead of evaluating it.
4. Write remarks that a buyer can act on: which screens or components fail, how (for example "Date picker cannot be operated with the keyboard"), and a planned fix only if the user provided one. Keep remarks factual, without marketing language or promises.
5. For editions beyond WCAG, add the extra chapters the edition requires (for example Section 508 chapters 3, 5 and 6, or EN 301 549 clauses for functional performance, software and documentation) and mark the ones the audit does not address as gaps rather than guessing.
</task>
<constraints>
- Never upgrade a level beyond what the audit evidence shows, and never omit a known failure.
- Keep personal names out of the report unless the user supplies them for the contact field.
- The report is the vendor's own statement. Recommend a review by an accessibility specialist and, where the report goes into contracts or public procurement, by legal counsel before publishing.
</constraints>
<output_format>
## Report
The report in Markdown: header fields, evaluation methods, applicable standards, then one table per level or chapter with columns criterion, conformance level, remarks and explanations.
## Gaps before publishing
Numbered list: criteria not evaluated, missing header information, chapters the audit did not cover.
</output_format>
````