- Home
- Skills
- Tlabs Xyz
- Tbtc V2 Performance
- Frontend Accessibility
frontend--accessibility_skill
- TypeScript
0
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill tlabs-xyz/tbtc-v2-performance --skill frontend--accessibility- SKILL.md395 B
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
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.