a11y

Standardize ARIA patterns, focus management, and WCAG contrast in Släktforskning UI components.

2|Updated Apr 2, 2026
One-click install
npx skills add https://github.com/jonaseck2/slaktforskning --skill a11y-jonaseck2
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: a11y
Source: https://github.com/jonaseck2/slaktforskning/tree/main/.claude/skills/a11y
Command: npx skills add https://github.com/jonaseck2/slaktforskning --skill a11y-jonaseck2

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents keyboard and screen-reader accessibility regressions by codifying ARIA patterns, focus management, contrast targets, and testing workflows for the Släktforskning UI.

Core Features & Use Cases

  • ARIA-first UI patterns: Standardized modal dialog semantics, combobox picker behavior, clickable row accessibility, and section labeling to ensure operability with assistive tech.
  • WCAG contrast enforcement: Clear, test-driven rules for maintaining AA/AAA thresholds across themes and appearance modes, including guidance to avoid hardcoded colors.
  • TTS and screen-reader integration: Wiring expectations for narration via v-narrate, global screen reader focus tracking, and verifying spoken output and accessible names.
  • Verification with live accessibility tools: Mandates running ui_aria_audit() via the slaktforskning-dev MCP to catch real accessible-name and interaction gaps that static DOM checks can miss.

Quick Start

Use the a11y skill to audit a newly changed interactive component by running ui_aria_audit() for the affected view in the slaktforskning-dev MCP and then apply the matching ARIA/focus pattern from this guide until all reported gaps are resolved.

Frequently Asked Questions about a11y

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

FAQPage Schema
How do I ensure my UI components meet WCAG accessibility standards?

To ensure UI components meet WCAG accessibility standards, apply standardized ARIA patterns, enforce token-only color usage with automated contrast tests, and verify operability using live accessibility auditing tools.

What is the best way to manage keyboard focus and screen reader narration in interactive modals?

The best way to manage keyboard focus and screen reader narration in modals is to implement standardized ARIA dialog semantics, wire global focus tracking, and verify spoken output through live accessibility audits.

How do I test ARIA patterns and accessible names for comboboxes and clickable rows?

You test ARIA patterns and accessible names for comboboxes and clickable rows by running live ui_aria_audit checks via the development MCP to catch real interaction gaps that static DOM checks often miss.

Why do my interactive UI components fail screen reader operability checks?

Interactive UI components fail screen reader operability checks when they lack proper section labeling, standardized ARIA patterns, or valid accessible names, which must be verified and resolved through live accessibility auditing.

How can I prevent color contrast regressions across different UI themes?

To prevent color contrast regressions across different UI themes, avoid hardcoded colors, use token-only color systems, and maintain AA or AAA thresholds by running automated WCAG contrast tests.

Does this accessibility approach work for charts and toast notifications?

Yes, this accessibility approach works for charts and toast notifications by codifying specific ARIA patterns, focus management rules, and TTS narration wiring to prevent regressions in any interactive component.