playbooks

home / skills / tlabs-xyz / tbtc-v2-performance / frontend-accessibility

frontend-accessibility skill

/.claude/skills/frontend-accessibility

This skill helps you build accessible user interfaces by applying WCAG guidelines, semantic HTML, keyboard navigation, and ARIA practices across components.

npx playbooks add skill tlabs-xyz/tbtc-v2-performance --skill frontend-accessibility

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

Files (1)
SKILL.md
2.0 KB
---
name: Frontend Accessibility
description: Build accessible user interfaces following WCAG guidelines with semantic HTML, keyboard navigation, proper ARIA attributes, and screen reader support. Use this skill when creating or modifying UI components, implementing interactive elements (buttons, forms, modals, menus), adding keyboard navigation support, implementing focus management, adding ARIA attributes or roles, ensuring color contrast compliance, writing alt text for images, creating form labels and error messages, implementing heading structures, building custom interactive widgets, testing for screen reader compatibility, or working with any HTML, JSX, or template files that render user-facing content. Use when working with React components, Vue templates, Angular templates, HTML files, or any frontend framework components.
---

## When to use this skill

- When creating or modifying UI components
- When implementing interactive elements (buttons, forms, modals, dropdowns, menus)
- When adding keyboard navigation support
- When implementing focus management for dynamic content
- When adding ARIA attributes, roles, or properties
- When ensuring color contrast compliance
- When writing alt text for images or icons
- When creating form labels, placeholders, and error messages
- When implementing heading structures (h1-h6)
- When building custom interactive widgets or controls
- When testing for screen reader compatibility
- When implementing skip links or landmark regions
- When working with HTML, JSX, Vue templates, Angular templates, or any UI component files
- When working with React, Vue, Angular, Svelte, or any frontend framework

# Frontend Accessibility

This Skill provides Claude Code with specific guidance on how to adhere to coding standards as they relate to how it should handle frontend accessibility.

## Instructions

For details, refer to the information provided in this file:
[frontend accessibility](../../../agent-os/standards/frontend/accessibility.md)

Overview

This skill helps you build accessible user interfaces that follow WCAG principles using semantic HTML, ARIA, keyboard support, and screen reader compatibility. It focuses on practical guidance for components, interactive patterns, and content structure to ensure inclusive experiences. Use it to validate and apply accessibility patterns across frameworks like React, Vue, Angular, and plain HTML.

How this skill works

The skill inspects UI markup and interaction patterns to recommend or enforce semantic elements, proper ARIA roles, keyboard navigation, focus management, and color contrast. It guides writing descriptive alt text, accessible form labels and error messages, heading hierarchies, and accessible implementations of modals, menus, and custom widgets. It also suggests testing strategies for screen readers and keyboard-only interaction.

When to use it

  • Creating or modifying UI components (buttons, forms, lists, widgets)
  • Implementing interactive elements like modals, menus, dropdowns, and dialogs
  • Adding keyboard navigation and focus management for dynamic content
  • Adding ARIA attributes, roles, states, or properties
  • Ensuring color contrast, alt text, and semantic heading structures
  • Testing for screen reader compatibility and keyboard-only workflows

Best practices

  • Prefer semantic HTML elements (button, input, nav, main, header, footer) over custom roles when possible
  • Ensure all interactive elements are reachable and operable via keyboard (Tab, Enter, Space, Arrow keys)
  • Manage focus explicitly on open/close of dialogs and dynamic content; return focus to a logical element
  • Use ARIA only to enhance semantics that cannot be expressed in HTML; keep roles and states up-to-date
  • Provide descriptive labels, instructions, and error messages; include visible and programmatic relationships
  • Verify color contrast meets WCAG thresholds and do not rely on color alone to convey information

Example use cases

  • Convert a visual-only dropdown into an accessible listbox with keyboard support and ARIA attributes
  • Implement an accessible modal that traps focus, restores focus on close, and uses aria-modal
  • Add accessible form validation with aria-invalid, aria-describedby, and inline error messages
  • Improve image and icon accessibility by adding meaningful alt text or aria-hidden where decorative
  • Refactor a custom widget to expose proper roles, keyboard handlers, and announceable state changes

FAQ

When should I use ARIA versus semantic HTML?

Always choose semantic HTML first. Use ARIA only to fill gaps that HTML cannot express, and ensure ARIA roles and states are accurate.

How do I test for screen reader compatibility?

Test with popular screen readers (NVDA, JAWS, VoiceOver) on relevant platforms, and verify keyboard-only workflows, announcements, and focus order.