accessibility-ux

Stars8

Forks0

UpdatedJuly 16, 2026 at 05:54

Use when UI accessibility or usability must shape specification planning, implementation planning, implementation, code/design review, or behavior-preserving refactoring. Trigger on work involving WCAG, semantic HTML, ARIA, keyboard operation, focus management, screen-reader support, forms, errors, contrast, reflow, status messages, or UX heuristics. Do not use for purely visual taste changes, legal compliance advice, framework-specific accessibility manuals, generic skill-authoring, or non-UI work unless accessibility/UX behavior is part of the task contract.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

glassesneo

glassesneo/dotfiles

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Web and Digital Interface DesignersComputer and Mathematical Occupations·SOC 15-1255

File Explorer

3 files

SKILL.md

readonly

name

accessibility-ux

description

Accessibility UX Skill

Purpose

Build accessibility and usability into UI work before it becomes a review-only checklist.

Use WCAG 2.2 AA as the default baseline. Prefer semantic HTML first, then ARIA only when needed, and verify with both automated checks and manual task flows.

The goal is to prevent users from being unable to perceive, operate, understand, recover from, or use UI with assistive technologies.

When to Use / Not Use

Use this skill for UI work that touches specifications, implementation, review, or refactoring when the task involves semantics, keyboard behavior, focus, screen-reader output, forms, error recovery, responsive behavior, or UX heuristics.

Do not use it for legal compliance advice, purely aesthetic review, framework APG catalogs, product-specific design-system rules, generic skill creation, or non-UI code that does not affect user-facing interaction.

Core Practices

Prefer native HTML controls and landmarks before ARIA.
Keep names, roles, states, values, focus, and keyboard behavior synchronized.
Preserve visible focus and avoid color-only state or error signaling.
Make status, loading, success, failure, and validation feedback textual.
Keep DOM order, reading order, visual order, and focus order aligned unless a documented exception is tested.
If a custom widget is unavoidable, define keyboard operation, focus handling, announcements, and recovery explicitly.

Planning and Review

For planning, identify the main user tasks, failure/recovery paths, keyboard paths, focus behavior, semantic structure, and verification method.

For review, check DOM semantics, operation, focus, visual responsiveness, screen-reader experience, and UX recovery. Report only issues with concrete user impact or clear implementation risk.

References

references/output-contracts.md: use for spec, implementation-note, and review-finding templates, plus severity guidance.
references/common-failures.md: use for the concrete failure checklist and verification prompts.

More from this repository

same repository

implementation-planning

glassesneo/dotfiles

Use when creating or revising an implementation-ready plan from a governing specification, artifact, or approved request. Covers approach selection, coverage, verification, and conditional task breakdown; do not use for specification authoring, source changes, or reports.

2026-07-188

liminal-lens

glassesneo/dotfiles

Use when a task has underspecified requirements, unresolved design directions, durable concept naming, vague option comparisons, workflow/prompt/skill design, or dissatisfaction without a settled desired change. Investigate the task normally, preserve settled decisions, state reversible assumptions visibly, and surface costly open decisions as bounded choices. Do not use for simple factual questions, fixed-format assignments, debugging with an obvious next step, or direct execution/final-artifact requests whose relevant decisions are already settled.

2026-07-188

specification-authoring

glassesneo/dotfiles

Use when creating or revising a decision-ready specification from a request. Covers requirements discovery, settlement, acceptance criteria, and readiness; do not use for implementation planning, source changes, or reports.

2026-07-188

agent-artifact

glassesneo/dotfiles

Use when creating durable agent artifacts: specifications, implementation plans, research notes, implementation reports, review reports, bug reports, or failure reports. Trigger when an agentic workflow needs a persisted contract, reusable evidence, or handoff record. Do not use for inline review comments, commit messages, transient scratch notes, or ordinary status updates that do not need a durable Markdown artifact.

2026-07-178

staged-agent-workflow

glassesneo/dotfiles

Use when a primary agent must coordinate an approval-gated specification, planning, or implementation workflow through delegated capabilities. Trigger for staged workflows that select spec-only, plan-only, spec-then-plan, plan-then-implement, or implement profiles. Do not use for direct specialist work that has no staged user dialogue or approval boundary.

2026-07-178

coherent-growth

glassesneo/dotfiles

Use when planning or implementing a large request with multiple responsibilities, building an entire software or configuration system from scratch, or rebuilding one step by step. Trigger when the user asks for a complete feature set or environment whose parts must be introduced and verified incrementally without losing the final scope. Do not use for a small local change that clearly follows existing structure, or by itself for ordinary architecture, refactoring, testing, prompt-design, or approval-workflow tasks.

2026-07-178

name

accessibility-ux

description

Accessibility UX Skill

Purpose

Build accessibility and usability into UI work before it becomes a review-only checklist.

Use WCAG 2.2 AA as the default baseline. Prefer semantic HTML first, then ARIA only when needed, and verify with both automated checks and manual task flows.

The goal is to prevent users from being unable to perceive, operate, understand, recover from, or use UI with assistive technologies.

When to Use / Not Use

Core Practices

Prefer native HTML controls and landmarks before ARIA.
Keep names, roles, states, values, focus, and keyboard behavior synchronized.
Preserve visible focus and avoid color-only state or error signaling.
Make status, loading, success, failure, and validation feedback textual.
Keep DOM order, reading order, visual order, and focus order aligned unless a documented exception is tested.
If a custom widget is unavoidable, define keyboard operation, focus handling, announcements, and recovery explicitly.

Planning and Review

For planning, identify the main user tasks, failure/recovery paths, keyboard paths, focus behavior, semantic structure, and verification method.

For review, check DOM semantics, operation, focus, visual responsiveness, screen-reader experience, and UX recovery. Report only issues with concrete user impact or clear implementation risk.

References

references/output-contracts.md: use for spec, implementation-note, and review-finding templates, plus severity guidance.
references/common-failures.md: use for the concrete failure checklist and verification prompts.