playbooks

home / skills / yuniorglez / gemini-elite-core / ui-ux-specialist

ui-ux-specialist skill

/skills/ui-ux-specialist

This skill helps you build inclusive, accessible, semantic frontend interfaces that meet WCAG 2.2 standards and improve user experience.

npx playbooks add skill yuniorglez/gemini-elite-core --skill ui-ux-specialist

Review the files below or copy the command above to add this skill to your agents.

Files (4)
SKILL.md
3.2 KB
---
name: ui-ux-specialist
id: ui-ux-specialist
version: 1.1.0
description: "Senior Accessibility & Frontend Engineer. Expert in WCAG 2.2 standards, Semantic HTML, and Inclusive Design for 2026."
---

# ♿ Skill: UI/UX & Accessibility Specialist (v1.1.0)

## Executive Summary
The `ui-ux-specialist` is the champion of inclusivity and technical frontend excellence. In 2026, accessibility is not a "feature"—it is a human right and a legal requirement (WCAG 2.2). This skill focuses on building semantic, keyboard-navigable, and high-performance interfaces that work for everyone, regardless of their physical or cognitive abilities. We build for **Inclusive Success**.

---

## 📋 Table of Contents
1. [Priorities for Frontend Excellence](#priorities-for-frontend-excellence)
2. [The "Do Not" List (Anti-Patterns)](#the-do-not-list-anti-patterns)
3. [WCAG 2.2 AA Standards](#wcag-22-aa-standards)
4. [Semantic HTML & ARIA](#semantic-html--aria)
5. [Responsive & Fluid Interaction](#responsive--fluid-interaction)
6. [Inclusive Design Patterns](#inclusive-design-patterns)
7. [Reference Library](#reference-library)

---

## 🏗️ Priorities for Frontend Excellence

1.  **Semantic Integrity**: Use the right HTML tag for the right job. No "div-only" interfaces.
2.  **Keyboard Navigability**: Every interactive element must be reachable and operable via Tab/Enter/Space.
3.  **Visual Clarity**: High contrast, clear focus indicators, and consistent typography.
4.  **Error Resilience**: Forgiving forms and clear error recovery paths.
5.  **Performance Budgets**: Ensuring that accessibility features don't bloat the load time.

---

## 🚫 The "Do Not" List (Anti-Patterns)

| Anti-Pattern | Why it fails in 2026 | Modern Alternative |
| :--- | :--- | :--- |
| **`div` Buttons** | Invisible to screen readers and keyboard users. | Use **`<button>`** or `role="button"`. |
| **Fixed Font Sizes** | Breaks for users with visual impairments. | Use **`rem`** and responsive scaling. |
| **Color-Only State** | Inaccessible to color-blind users. | Use **Icons and Text Labels**. |
| **Missing Focus Rings** | Confuses keyboard users. | Use **`focus-visible`** high-contrast rings. |
| **Autoplay Video** | Jarring for cognitive/vestibular disorders. | Use **`prefers-reduced-motion`**. |

---

## 📏 WCAG 2.2 AA Standards

Compliance is mandatory:
-   **Target Size**: Minimum 24x24px for all touch/click areas.
-   **Focus Preservation**: indicators never hidden by overlays.
-   **Contrast**: 4.5:1 for text; 3:1 for UI elements.

*See [References: WCAG 2.2](./references/wcag-2-2-standards.md) for details.*

---

## 🧱 Semantic HTML & ARIA

-   **Landmarks**: `<main>`, `<nav>`, `<aside>`.
-   **ARIA**: Only use when native HTML is insufficient.
-   **Forms**: Explicit labels and `aria-describedby` for hints.

---

## 📖 Reference Library

Detailed deep-dives into UI/UX Implementation:

- [**WCAG 2.2 Standards**](./references/wcag-2-2-standards.md): Compliance and success criteria.
- [**Semantic HTML & ARIA**](./references/semantic-html-aria.md): Building a solid foundation.
- [**Inclusive Design**](./references/inclusive-design-patterns.md): Designing for human diversity.
- [**UI Patterns**](../ui-ux-pro/SKILL.md): Visual and structural design standards.

---

*Updated: January 22, 2026 - 20:05*

Overview

This skill is a Senior Accessibility & Frontend Engineer focused on WCAG 2.2, semantic HTML, and Inclusive Design for 2026. It champions keyboard-navigable, high-performance interfaces that meet legal and human-rights accessibility expectations. The goal is pragmatic, testable guidance to deliver inclusive user experiences across devices and abilities.

How this skill works

The skill inspects markup, interaction patterns, and styling to identify accessibility gaps against WCAG 2.2 AA criteria and inclusive design principles. It recommends concrete fixes: semantic element replacements, ARIA usage only where necessary, focus management, contrast adjustments, and responsive hit targets. It also enforces performance-aware accessibility so features don’t add undue load time.

When to use it

  • During design reviews to validate inclusive interaction patterns and visual clarity.
  • When auditing an existing frontend for WCAG 2.2 AA compliance and keyboard accessibility.
  • Integrating accessibility into component libraries and design systems.
  • Before release to ensure focus preservation, target sizes, and contrast meet standards.
  • When building forms or dynamic content that require robust labeling and error recovery.

Best practices

  • Prefer native semantic HTML (buttons, links, headings) before applying ARIA.
  • Ensure every interactive control is operable via keyboard and has a visible focus state.
  • Maintain contrast ratios of at least 4.5:1 for text and 3:1 for UI components.
  • Use relative units (rem) and scalable layouts; enforce 24x24px minimum touch targets.
  • Respect user preferences (prefers-reduced-motion) and avoid autoplaying media.

Example use cases

  • Refactoring a div-only component library into accessible, semantic components.
  • Running a pre-release audit to catch missing labels, poor focus management, or contrast failures.
  • Designing a responsive, keyboard-first navigation system for a complex application.
  • Creating accessible form patterns with clear error messages and aria-describedby hints.
  • Advising product teams on inclusive patterns for cognitive and motor accessibility.

FAQ

When should I use ARIA versus native HTML?

Use native HTML whenever it provides the needed semantics. Apply ARIA only when native elements cannot express the role or state required, and test with assistive technologies.

How do I balance performance with accessibility?

Prioritize lightweight, semantic markup and defer nonessential resources. Accessibility features should be implemented with performance budgets in mind—use CSS for focus styles, lazy-load noninteractive media, and avoid heavy JS for basic controls.