skills.rest
natelandau
natelandauCOMMUNITY
Explore all skills by this author →
WebsiteGitHub

accessibility

Audit and implement WCAG 2.2 accessibility in HTML, htmx, and daisyUI components.

Updated May 9, 2026
Search Tags:#accessibility#keyboard navigation#audit#wcag#semantic html#htmx#aria
One-click install
npx skills add https://github.com/natelandau/cc-plugin --skill accessibility-natelandau
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: accessibility
Source: https://github.com/natelandau/cc-plugin/tree/main/plugins/natelandau-toolkit/skills/accessibility
Command: npx skills add https://github.com/natelandau/cc-plugin --skill accessibility-natelandau

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Web interfaces often ship with accessibility barriers such as missing ARIA roles, poor keyboard navigation, low contrast, and broken focus management, which block users who rely on screen readers or keyboard-only navigation. ## Core Features & Use Cases - WCAG 2.2 Implementation Guidance: Apply the POUR principles with concrete checklists covering contrast ratios, target sizes, focus appearance, and error handling. - htmx and daisyUI Patterns: Handle dynamic content swaps with persistent aria-live regions, focus restoration after swaps, and native dialog-based modals. - Audit Checklist: Systematically review templates and components for common violations like icon-only buttons without accessible names or divs used as buttons. - Use Case: When reviewing a jinja template for a form, use this Skill to verify labels, error messages, focus indicators, and 24x24 pixel target sizes before shipping. ## Quick Start Review this HTML form for WCAG 2.2 accessibility issues and suggest fixes for keyboard navigation and screen reader support.

Frequently Asked Questions about accessibility

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I make a web form accessible for screen readers?▼

Associate every input with a label element, provide text-based error messages with correction suggestions, and announce validation results through an aria-live region. Use native form elements so roles and keyboard behavior come built in.

How to handle focus management with htmx content swaps?▼

When an htmx swap removes the focused element, move focus to a sensible target so keyboard users do not drop back to the top of the document. Place swap results inside a persistent aria-live region rather than replacing the live region itself.

What is the minimum target size in WCAG 2.2?▼

WCAG 2.2 Success Criterion 2.5.8 requires interactive targets to be at least 24x24 CSS pixels. This applies to buttons, links, and other pointer-activated controls.

Does daisyUI modal trap focus for keyboard users?▼

daisyUI's dialog-based modal uses the native dialog element, which traps focus and closes on Escape when opened with showModal(). Prefer it over div-based modals that let keyboard users tab into background content.

When should I use ARIA instead of native HTML elements?▼

Use native elements like button, a, nav, and label first, since they carry focus, keyboard, and role behavior built in. Add ARIA only to change what the accessibility tree exposes, such as aria-label on icon-only buttons or aria-live for status updates.

Related Skills

Explore More Software Engineering Skills→
eykdeykd

htmx-alpine-templates

Generate interactive HTML pages with HTMX and Alpine.js templates.

Community
Advanced
samjhechtsamjhecht
4

frontend-accessibility-verification

Verify frontend UI accessibility compliance with axe-core, keyboard, screen reader, and Lighthouse audits.

Community
Advanced
thompson0012thompson0012
28

frontend-qa

Audit frontend behavior in real browsers across functional, visual, accessibility, and performance dimensions.

Community
Advanced
gc-da11yngc-da11yn
41

web-scanning

Automate web accessibility scans and page inventories using axe-core CLI.

Official
Advanced