skills.rest
Deibler
DeiblerCOMMUNITY
Explore all skills by this author →
GitHub

accessibility

Applies WCAG perceivable, operable, understandable, and robust criteria to user-facing design surfaces.

8|3|Updated May 3, 2026
Search Tags:#inclusive design#accessibility#screen reader#keyboard navigation#wcag#contrast#aria
One-click install
npx skills add https://github.com/Deibler/universal-design-principles --skill accessibility-deibler
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: accessibility
Source: https://github.com/Deibler/universal-design-principles/tree/main/plugins/process-and-robustness-principles/skills/accessibility
Command: npx skills add https://github.com/Deibler/universal-design-principles --skill accessibility-deibler

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Designs often ship with accessibility failures — missing labels, keyboard traps, color-only signals, low contrast — because accessibility is treated as a late compliance step rather than a structural property of every screen. This Skill embeds WCAG-based accessibility review into every design task, catching the silent decisions that exclude users with permanent, temporary, or situational impairments. ## Core Features & Use Cases - Four WCAG sub-principle routing: Organizes decisions into Perceivable (alt text, contrast, captions), Operable (keyboard access, focus management, target size, reduced motion), Understandable (labels, error copy, predictable behavior), and Robust (semantic HTML, ARIA, live regions), with routing to dedicated sub-aspect skills. - Practical checklist and worked examples: Provides a per-screen audit checklist plus corrected code patterns for icon-only buttons, inline form errors, accessible dialogs, reduced-motion handling, and non-color status badges. - Testing heuristics and legal context: Covers keyboard-only walkthroughs, screen reader testing (VoiceOver, NVDA, TalkBack), contrast and zoom checks, automated tools (axe, WAVE, Lighthouse), and the WCAG 2.x / ADA / Section 508 / EAA regulatory landscape. - Use Case: While designing a checkout form, apply the checklist to ensure every input has a programmatically associated label, errors are announced via aria-describedby, focus is visible, and touch targets meet 44×44 sizing — before any code ships. ## Quick Start Review this checkout form design for WCAG accessibility issues and fix any keyboard, contrast, labeling, or ARIA problems you find.

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 design accessible for screen readers?▼

Use semantic HTML elements like button, nav, and label first, then add ARIA attributes only when native semantics are insufficient. Ensure every interactive element has an accessible name, use aria-live regions for dynamic announcements, and test critical flows with VoiceOver, NVDA, or TalkBack.

What are the four WCAG principles for accessibility?▼

WCAG organizes accessibility into Perceivable, Operable, Understandable, and Robust. Perceivable covers alt text and contrast, Operable covers keyboard access and focus, Understandable covers labels and predictable behavior, and Robust covers semantic markup and assistive technology compatibility.

What color contrast ratio does WCAG require for text?▼

WCAG Level AA requires at least 4.5:1 contrast for body text and 3:1 for large text and meaningful UI elements. Verify ratios with browser DevTools, the WebAIM Contrast Checker, or the Stark plugin, and never use color as the only signal for meaning.

Can automated tools like axe or Lighthouse catch all accessibility issues?▼

No. Automated audits catch roughly 30% of issues, such as missing alt text, contrast failures, and missing labels. They cannot judge alt text quality, keyboard behavior of custom components, focus management, or copy clarity, so manual keyboard and screen reader testing is required.

Why is removing the focus outline an accessibility problem?▼

The focus outline is the only visual indicator keyboard users have for their current position. Removing it with outline:none makes navigation invisible. If restyling is needed, replace it with a custom :focus-visible ring rather than deleting it.

When should accessibility be addressed in a design project?▼

At the start of the project and at every design review, not as a final phase. Retrofitting accessibility onto a finished product costs 2–10x more than building it in, and some structural failures cannot be fully fixed after the fact.

Related Skills

Explore More Design & Creative Skills→
qazuorqazuor

frontend-design

Guide UI teams through pre-coding design foundations for typography, color, and layout.

Community
Basic
Community-AccessCommunity-Access
387

Testing Coach

Guide accessibility testing for web applications with screen readers and automated tools.

Official
Intermediate
Objective-ArtsObjective-Arts

interaction

Define interaction design rules for touch, mouse, and keyboard inputs.

Official
Intermediate
vmitsarasvmitsaras

inclusive-user-testing-plan

Creates inclusive usability testing plans with disabled participants, accommodations, consent, and synthesis protocols.

Community
Advanced