forge-accessibility

Enforce semantic HTML, keyboard navigation, and WCAG contrast in frontend UI.

Updated Aug 23, 2026
One-click install
npx skills add https://github.com/f4rkh4d/forge-skill --skill forge-accessibility
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: forge-accessibility
Source: https://github.com/f4rkh4d/forge-skill/tree/main/skills/design/forge-accessibility
Command: npx skills add https://github.com/f4rkh4d/forge-skill --skill forge-accessibility

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes assets (resource) components.

What problem does it solve?

This Skill prevents AI-generated UI from failing accessibility basics like keyboard navigation, missing labels, weak focus states, poor color contrast, and non-semantic “div soup” interactions that break screen-reader and low-vision usability.

Core Features & Use Cases

  • Semantic HTML over ARIA: choose correct elements first (buttons, links, headings, landmarks, tables, dialog/disclosures) and use ARIA only when semantics can’t express the intent.
  • Keyboard & focus correctness: enforce visible :focus-visible rings, focus order that matches reading order, and safe modal behavior (focus trap, Escape to close, restore focus).
  • Accessible form & media discipline: require real labels (not placeholder-only), associate errors with inputs, provide alt for images (including decorative alt=""), and ensure icon-only buttons have an aria-label.

Quick Start

Use forge-accessibility whenever you generate or refactor a UI component so it remains usable with keyboard and screen readers, including dialogs, forms, and interactive controls.

Frequently Asked Questions about forge-accessibility

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I make AI-generated UI accessible for screen reader and keyboard navigation?▼

Make AI-generated UI accessible by enforcing semantic HTML first, correct labeling, visible focus-visible styling, WCAG contrast thresholds, and ARIA only when semantic markup cannot represent the intent.

What is the best way to handle keyboard focus and modal dialog accessibility?▼

Modal dialog accessibility requires safe modal behavior: enforce a focus trap, allow Escape to close, restore focus to the triggering element, and ensure focus order matches the reading order for keyboard users.

How do I build accessible forms that pass WCAG contrast and labeling rules?▼

Accessible forms require real labels associated with inputs, not placeholder-only text, link error messages to inputs via ARIA, and ensure text meets WCAG contrast thresholds for low-vision usability.

When should I use ARIA attributes instead of semantic HTML for interactive controls?▼

Use ARIA attributes only when semantic HTML elements like buttons, links, or headings cannot express the interaction intent, preventing non-semantic div soup that breaks screen-reader usability.

How do I provide accessible alt text for images and icon-only buttons?▼

Provide alt text for images using descriptive alt attributes, or alt="" for decorative images, and ensure icon-only buttons include an aria-label so screen readers can announce their purpose.

Why does my frontend component fail keyboard navigation and screen reader usability?▼

Frontend components fail keyboard navigation and screen reader usability when they lack visible focus rings, proper landmarks, semantic elements, and correct label associations, creating inaccessible interactions for assistive technology users.