Skip to content
cccskills
FreePublished on GitHub

docs-a11y

Audit and improve the accessibility of the timepicker-ui documentation site (docs-app/) - landmarks, heading order, skip links, keyboard nav, focus management in the command menu / sidebar / dialogs, color contrast, alt text, ARIA on custom components (tabs, native dialogs), reduced motion - against WCAG 2.2 AA. Use when the user wants an a11y audit/fix of the docs site. Drives the docs-accessibility subagent in an audit → approve → apply flow. Does NOT cover the library (use /a11y for that).

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md3.6 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Docs Accessibility (a11y)

Make the timepicker-ui documentation site (docs-app/, Next.js 16) usable by keyboard and assistive technology. This skill is a thin orchestrator: the real work is done by the docs-accessibility subagent. The skill exists to hold the approval gate the subagent can't run itself.

Standard: WCAG 2.2 AA. Scope is docs-app/ only - the library is /a11y.

Arguments (optional)

  • A focus area narrows the run, e.g. /docs-a11y nav, /docs-a11y command-menu, /docs-a11y contrast, /docs-a11y headings, /docs-a11y keyboard. No argument = full audit.
  • --apply-all skips the per-area approval prompt and applies the whole audited plan (still reports
    • verifies). Use only for an explicitly unattended run.

Workflow

Phase 1 — Audit (read-only)

Dispatch the docs-accessibility subagent (Task tool, subagent_type: docs-accessibility) in audit mode, with the focus area if given. Ask for a prioritized, file-level plan grouped into:

  1. Structure & landmarks (one <main>, nav/header/footer, skip link, heading order)
  2. Keyboard & focus (command menu, mobile sidebar, dialogs: trap/Escape/focus-return, visible focus, aria-expanded/aria-current)
  3. Names, roles, contrast (icon-button labels, decorative aria-hidden, ≥4.5:1 text contrast in light AND dark)
  4. Content & media (lang, descriptive links, labelled copy buttons, alt text)
  5. Motion & responsiveness (prefers-reduced-motion, reflow at 320px / 400% zoom) Each finding cites its WCAG reference and the exact file + change. No edits.

Phase 2 — Present & approve (gate)

Relay the plan concisely (grouped, with references). Use AskUserQuestion to approve all, pick which groups/items to apply, or skip. Capture the approved set. Do not skip this gate unless --apply-all was passed.

Phase 3 — Apply

Dispatch docs-accessibility again in apply mode with the exact approved list. It implements fixes (landmarks, headings, aria-*, focus management, labels, contrast/markup) in docs-app's own TS/App-Router style and line endings, using native elements and the WAI-ARIA patterns correctly and adding no heavy deps.

Phase 4 — Verify & report

  • Run npm run build / npm run lint inside docs-app/ (and an axe/Lighthouse a11y pass if the tooling is available), then /verify per HARD RULES §5. Report real output; never assume green.
  • Summarize what changed, grouped by the five areas, with the file list.
  • Give the manual checklist: keyboard-only walkthrough (header → command menu → sidebar → a docs page), Escape/focus-return on the menus, a screen-reader pass on one page, and a contrast check in both light and dark themes.
  • Flag anything that's actually a library a11y bug (seen via a live demo) for /a11y, and any visual/content redesign for docs-site.

Guardrails

  • docs-app/ only; never edit the library in app/ or dist/.
  • Match docs-app conventions; docs-app files are CRLF like the library.
  • Accessibility, not redesign; no new heavy a11y dependencies without flagging.
  • This skill audits/fixes; git and deploy stay with the user.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

a11y

Free

Audit and improve the accessibility of the timepicker-ui LIBRARY (app/src) - ARIA, keyboard operability, focus trap/management, screen-reader announcements, labels - against WCAG 2.2 AA and the WAI-ARIA Authoring Practices. Use when the user wants an a11y audit/fix of the picker itself (clock, wheel, plugins, modal, inputs). Drives the accessibility subagent in an audit → approve → apply flow. Does NOT cover docs-app (use /docs-a11y for that).

The English summary is being prepared. Showing the original description.

pglejzer/timepicker-ui100Updated Oct 17, 2026

Audit and improve the discoverability of the timepicker-ui documentation site (docs-app/) across the full modern discoverability stack — SEO (ranking), AEO (answer engines / featured snippets), GEO (citations inside ChatGPT/Gemini/Perplexity/Claude), and AIO (Google AI Overviews). Use when the user wants to optimize docs SEO, improve Google ranking/positioning, win featured snippets or AI-answer boxes, get the docs cited by AI engines, add or fix sitemap/robots/manifest, fill in page metadata, add Open Graph/Twitter cards, answer-first copy, or JSON-LD (FAQPage/SoftwareApplication/TechArticle/BreadcrumbList). Drives the seo-optimizer subagent with an audit → approve → apply flow.

The English summary is being prepared. Showing the original description.

pglejzer/timepicker-ui100Updated Oct 17, 2026

Cut a new timepicker-ui release. Use when the user wants to bump the version, prepare a release, write/update the changelog, or sync version + changelog across README, CHANGELOG.md and the docs-app (changelog/what's-new/version strings). Drives the build-release subagent in an audit → approve → apply flow, then runs a sanity build. Does NOT git-commit/tag or npm-publish — proposes those for the user to run.

The English summary is being prepared. Showing the original description.

pglejzer/timepicker-ui100Updated Oct 17, 2026

Full repository maintenance pipeline that orchestrates all project agents in sequence - code review, accessibility, bundle size, security, API stability, test coverage, ecosystem, and release preparation. Acts as a quality gate before publishing or merging major changes. Use when: maintenance, health check, pre-release audit, quality gate, full pipeline, repo health, pre-merge check, release readiness, audit all.

The English summary is being prepared. Showing the original description.

pglejzer/timepicker-ui100Updated Oct 17, 2026

verify

Free

Browser-check what a change could have broken in timepicker-ui (library demo and docs-app, before/after). Use at the end of a task that changed library behavior or styles (app/src) or docs-app pages, or when the user asks to check that nothing broke. Not for demo examples in app/docs, copy/typo/comment edits or one-line fixes (HARD RULES §5 in CLAUDE.md). Main agent only, never delegated to a subagent.

The English summary is being prepared. Showing the original description.

pglejzer/timepicker-ui100Updated Oct 17, 2026

See all skills by pglejzer

Report a problem with this skill