pf-a11y_skill

This skill analyzes component and page accessibility checks for semantic HTML, keyboard access, ARIA, focus, and contrast to improve user experience.
  • 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 pluxity/pf-frontend --skill pf-a11y

  • SKILL.md5.4 KB

Overview

This skill performs an accessibility (a11y) inspection of a TypeScript React component or page. It checks semantic HTML, keyboard behavior, ARIA usage, focus styles, color contrast, form labels, modals, dynamic announcements, and image alt text to surface concrete fixes and recommendations. Use it to quickly validate PF DEV UI patterns and custom components against common accessibility pitfalls.

How this skill works

Provide a reference to the component or page to inspect and the skill scans for common accessibility issues using checklist rules derived from best practices (semantic elements, keyboard support, ARIA correctness, focus management, contrast, forms, modals, and live regions). It flags missing or incorrect patterns, suggests minimal code changes (e.g., use <button>, add aria attributes, implement focus-visible), and recommends automated checks like axe-core plus manual testing steps. The output is actionable, prioritizing keyboard and screen reader compatibility.

When to use it

  • During code review of new components or pages before merge.
  • When converting non-semantic markup (divs/spans) to interactive elements.
  • Before launching features that include modals, dynamic content, or complex forms.
  • When integrating or customizing @pf-dev/ui components.
  • To validate fixes after accessibility bug reports or audits.

Best practices

  • Prefer semantic elements (button, a, header, nav, main) over role-based divs.
  • Ensure all interactive elements are keyboard reachable and activate with Enter/Space.
  • Keep visible focus using focus-visible styles; never remove outlines globally.
  • Use ARIA only to complement native semantics; connect labels, descriptions, and error messages.
  • Verify color contrast meets WCAG thresholds and provide non-color cues for state.
  • Test with automated tools (axe-core) and manual scenarios: Tab navigation, screen readers, 200% zoom.

Example use cases

  • Convert a clickable <div> card into an accessible button with proper keyboard handlers or a native <button>.
  • Audit a modal implementation to ensure focus trap, aria-modal, labeled title, and Escape handling.
  • Review a form to add explicit labels, aria-describedby for errors, and aria-invalid on invalid fields.
  • Validate that decorative images use empty alt and role=presentation while meaningful images have descriptive alt text.
  • Check a custom dropdown for arrow-key navigation, aria-expanded/state attributes, and logical focus order.

FAQ

It provides rule-based inspections and actionable remediation steps; it recommends running automated tools like axe-core for broader coverage and includes manual test steps.

When should I use ARIA attributes vs native elements?

Prefer native elements first (button, input, a). Use ARIA to augment when semantics cannot be expressed natively, and ensure ARIA attributes correctly reference IDs and states.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational