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.