playbooks

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

frontend--accessibility skill

/.codex/skills/frontend--accessibility

This skill enforces frontend accessibility standards by applying agent-os guidelines to components, pages, and interactions for inclusive user interfaces.

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
395 B
---
name: frontend--accessibility
description: Apply the Agent OS standard for frontend accessibility.
tags: [agent-os, standard, frontend]
---

# Frontend Accessibility

Use this skill when working on frontend accessibility in this repo.

## Instructions

- Follow the standard in `agent-os/standards/frontend/accessibility.md`.

## References

- `agent-os/standards/frontend/accessibility.md`

Overview

This skill applies the Agent OS frontend accessibility standard to UI code and deliverables. It helps teams evaluate, fix, and verify accessibility issues to meet the standard. The focus is on practical, testable changes that improve keyboard navigation, screen reader compatibility, and semantic markup.

How this skill works

The skill inspects frontend code, components, and markup for accessibility gaps against the Agent OS frontend accessibility standard. It identifies violations like missing aria attributes, incorrect heading structure, color-contrast failures, and non-semantic interactive elements. It produces actionable recommendations and test steps to validate fixes using automated tools and manual checks.

When to use it

  • During code review of new UI components or pages
  • When preparing a release that requires accessibility compliance
  • While refactoring legacy UI to improve semantics and navigation
  • Before user testing with screen readers or keyboard-only users
  • When running accessibility audits or fixing reported issues

Best practices

  • Prioritize keyboard focus order and visible focus indicators for interactive elements
  • Use semantic HTML and ARIA only when native semantics are insufficient
  • Ensure text and UI contrast meet minimum ratios for normal and large text
  • Provide accessible names and roles for controls and meaningful alt text for images
  • Combine automated testing with manual screen reader and keyboard checks

Example use cases

  • Reviewing a form component for label associations, error handling, and focus management
  • Auditing a navigation bar to ensure keyboard access and landmark roles are present
  • Fixing color contrast and text resizing issues on a landing page
  • Converting non-semantic button-like elements to proper button elements with ARIA fallbacks
  • Creating test cases for CI that catch regressions in accessibility attributes

FAQ

Does this skill replace manual accessibility testing?

No. It augments automated checks with concrete guidance, but manual testing with screen readers and keyboard navigation remains essential.

When should I use ARIA versus native HTML?

Prefer native semantic HTML first; use ARIA only when native elements cannot provide the required semantics or behavior.