
Ui Ux Expert
Implement and verify WCAG 2.2 accessible UI patterns—contrast, keyboard flows, ARIA, forms, and assistive-tech testing—for interfaces you are shipping.
Overview
UI UX Expert is an agent skill most often used in Build (also Ship review) that guides WCAG 2.2 accessibility implementation, ARIA, keyboard navigation, and assistive-tech testing for web UI.
Install
npx skills add https://github.com/martinholovsky/claude-skills-generator --skill ui-ux-expertWhat is this skill?
- WCAG 2.2 reference organized around POUR principles with full success-criteria coverage
- Color and contrast guidelines with operable keyboard navigation patterns
- Screen reader implementation notes and ARIA patterns with anti-patterns
- Dedicated form accessibility and assistive-technology testing procedures
- Accessibility checklist plus catalog of common violations to fix before ship
- Reference is structured as a 10-section accessibility guide culminating in a dedicated accessibility checklist.
Adoption & trust: 707 installs on skills.sh; 38 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your interface looks fine visually but fails keyboard, screen reader, or contrast requirements—and you lack a systematic WCAG checklist while shipping solo.
Who is it for?
Implementing or auditing component libraries, marketing pages, and app shells where you must meet accessibility expectations without a dedicated a11y team.
Skip if: Pure brand mood boards, marketing copy strategy, or backend-only APIs with no user interface surface.
When should I use this skill?
User needs WCAG 2.2 implementation, keyboard navigation, screen reader compatibility, ARIA patterns, form accessibility, or assistive-technology testing for UI work.
What do I get? / Deliverables
You apply documented WCAG 2.2 patterns, ARIA fixes, and test procedures so components are operable and understandable before users or auditors find blocking issues.
- WCAG-oriented fix list mapped to success criteria
- ARIA and keyboard navigation pattern recommendations
- Pre-ship accessibility checklist completion notes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Accessibility is applied while crafting frontend UI; the skill’s canonical shelf is Build frontend even though it also supports pre-release QA. Frontend subphase is where components, ARIA, focus order, and form labels are implemented before users hit production.
Where it fits
Add keyboard-operable date picker and announce errors to screen readers in checkout.
Verify modals, skip links, and heading hierarchy against WCAG before public launch.
Remediate contrast and focus issues on a dashboard widget after support tickets.
How it compares
Deep WCAG 2.2 implementation reference for builders—not a lightweight “make it pretty” visual design-only prompt pack.
Common Questions / FAQ
Who is ui-ux-expert for?
Solo developers and indie product designers shipping web or hybrid apps who need actionable WCAG 2.2, ARIA, and keyboard guidance without hiring a full-time accessibility specialist.
When should I use ui-ux-expert?
Use it in Build frontend while coding components and forms; in Ship review before launch to run the accessibility checklist; and in Operate iterate when user reports focus or screen reader failures.
Is ui-ux-expert safe to install?
It is documentation-style guidance for your repo and UI—no special runtime privileges required. Review the Security Audits panel on this Prism page before installing any third-party skill package.
SKILL.md
READMESKILL.md - Ui Ux Expert
# Accessibility Implementation Guide > **Reference Document**: Comprehensive WCAG 2.2 implementation guide, screen reader testing procedures, and keyboard navigation patterns for the UI/UX Expert skill. --- ## Table of Contents 1. [WCAG 2.2 Overview](#wcag-22-overview) 2. [Complete WCAG 2.2 Success Criteria](#complete-wcag-22-success-criteria) 3. [Color & Contrast Guidelines](#color--contrast-guidelines) 4. [Keyboard Navigation Patterns](#keyboard-navigation-patterns) 5. [Screen Reader Implementation](#screen-reader-implementation) 6. [ARIA Patterns & Best Practices](#aria-patterns--best-practices) 7. [Form Accessibility](#form-accessibility) 8. [Testing with Assistive Technologies](#testing-with-assistive-technologies) 9. [Common Accessibility Violations](#common-accessibility-violations) 10. [Accessibility Checklist](#accessibility-checklist) --- ## 1. WCAG 2.2 Overview ### The Four Principles (POUR) **Perceivable**: Information and user interface components must be presentable to users in ways they can perceive. - If they can't perceive it, they can't use it - Provide text alternatives, captions, adaptable content, distinguishable elements **Operable**: User interface components and navigation must be operable. - Users must be able to operate the interface - Keyboard accessible, enough time, no seizures, navigable, input modalities **Understandable**: Information and the operation of user interface must be understandable. - Users must understand the information and interface operation - Readable, predictable, input assistance **Robust**: Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. - Must work with current and future tools - Compatible with assistive technologies --- ### Conformance Levels **Level A** (Minimum): - Essential accessibility features - Basic support for assistive technologies - Legal minimum in many jurisdictions **Level AA** (Recommended): - Addresses the biggest and most common barriers - Industry standard for most organizations - Required by most accessibility laws (ADA, Section 508) **Level AAA** (Enhanced): - Highest level of accessibility - Not required for entire sites - May not be achievable for all content **Recommendation**: Aim for Level AA compliance across all content, with AAA where feasible. --- ## 2. Complete WCAG 2.2 Success Criteria ### Principle 1: Perceivable #### 1.1 Text Alternatives **1.1.1 Non-text Content (Level A)**: - All non-text content has a text alternative - Images: Use alt text describing the image - Decorative images: Use empty alt (`alt=""`) - Complex images: Provide long descriptions ```html <!-- Informative image --> <img src="chart.png" alt="Sales increased 25% in Q3 2025"> <!-- Decorative image --> <img src="divider.png" alt="" role="presentation"> <!-- Complex image with long description --> <img src="complex-diagram.png" alt="System architecture diagram" aria-describedby="diagram-desc"> <div id="diagram-desc"> The diagram shows three tiers: presentation layer with React components, business logic layer with Node.js services, and data layer with PostgreSQL. </div> <!-- Icons with labels --> <button> <svg aria-hidden="true">...</svg> <span>Save</span> </button> ``` --- #### 1.2 Time-based Media **1.2.1 Audio-only and Video-only (Level A)**: - Provide transcripts for audio-only content - Provide audio descriptions or transcripts for video-only **1.2.2 Captions (Level A)**: - Provide captions for all prerecorded video with audio - Include speech and important sounds **1.2.3 Audio Description or Media Alternative (Level A)**: - Provide audio description or full text alternative for video **1.2.4 Captions (Live) (Level AA)**: - Provide live captions for live audio content **1.2.5 Audio Description (Level AA)**: - Provide audio description for all prerecorded video ```html <video controls> <source src="tutorial.mp4" type="video/mp4"> <track