一键在 Manus 中运行任何 Skill

accessibility-ux

星标45

分支5

更新时间2026年4月4日 04:11

WCAG 2.2 AA compliance, accessibility patterns, UX design for Power Platform. Use when: building accessible components, reviewing WCAG compliance, designing loading/empty/error states, responsive design, form accessibility, keyboard navigation, screen reader support, color contrast, focus management.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

korchard333

korchard333/claude-power-platform-community

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Skill: Accessibility & UX/UI Design

When to Use

Trigger when designing UI layouts, building components, reviewing user experience, or ensuring WCAG compliance in Code Apps, Canvas Apps, or PCF controls.

⚠️ REQUIRED: Load Sub-Files Before Implementation

SKILL.md is a summary only — it is NOT sufficient for implementation.

The detailed content (complete payloads, XML templates, working examples, edge-case handling) lives in sub-files in the same directory as this SKILL.md. Before writing any code, you MUST use read_file on the sub-files relevant to your task:

WCAG 2.2 AA Requirements — perceivable, operable, understandable, robust criteria with implementation guidance; contrast ratios
React Accessibility Patterns — semantic HTML, focus management, skip links, live regions, form a11y, dialogs, data tables, reduced motion; shadcn/ui + Radix notes
UX Patterns — loading/empty/error states, form design, navigation, toasts; typography, spacing, and dark mode design tokens
Visual Design Patterns — page composition recipes (dashboard, list, detail, form), visual hierarchy, spacing rhythm, color usage (60-30-10 rule), surface elevation, typography rules, border/divider guidance, interactive states, common visual mistakes
Component Recipes — component-level styling specifications (KPI cards, data cards, form fields, table headers/rows, badges, dialogs, navigation items, page headers, empty states, skeletons, toasts, toolbars) with exact token values, states, and makeStyles examples
Responsive Design — breakpoints, enterprise app responsive patterns (mobile / tablet / desktop)
Accessibility Testing — automated testing (axe-core, eslint-plugin-jsx-a11y, Lighthouse), manual checklist, Playwright pattern, top 10 failures

For Fluent UI V9 component accessibility (built-in ARIA, focus management via Tabster, high-contrast theme support), see code-apps/fluent-ui.md.

Anti-Patterns

Using <div> or <span> as interactive elements (buttons, links) — not keyboard accessible, not announced by screen readers. Use semantic <button> and <a> elements instead.
Adding role="button" to a <div> instead of using <button> — you then need to manually handle Enter, Space, focus, and disabled states. Native elements get these for free.
Color as the only indicator of state (error = red, success = green) — invisible to colorblind users. Always pair color with icons, text, or patterns. All color-coded states must have a visible legend. Users will guess meanings based on common conventions (yellow = warning/draft, red = error). If your color means something domain-specific (e.g., yellow = non-billable), make it explicit with a legend or label — don't rely on color alone.
Missing skip-to-main-content link — keyboard users must tab through the entire navigation on every page. Add a visually-hidden skip link as the first focusable element.
Placeholder text as the only label — disappears on input, not reliably announced by screen readers. Always use a visible <label> element.
Auto-playing animations without respecting prefers-reduced-motion — causes motion sickness for vestibular disorder users. Wrap all animations in a media query check.
Generic link text ("Click here", "Read more") — meaningless out of context for screen reader users who navigate by links. Use descriptive text: "View project details".
Missing aria-live regions for dynamic content — screen readers miss toast notifications, status updates, and inline validation messages. Use aria-live="polite" for status, aria-live="assertive" for errors.

Related Skills

code-apps — Accessibility patterns in Code Apps (React components, shadcn/ui)
canvas-apps — Accessible Canvas App design
pcf — PCF control accessibility requirements
testing — Accessibility testing with axe-core and Playwright

同仓库更多 Skills

同仓库

model-driven-apps

korchard333/claude-power-platform-community

Model-Driven Apps Development. Use when: building Model-Driven Apps, forms, views, business rules, site map, command bar customization, custom pages, embedded Canvas Apps, subgrids, role-based form switching, generative pages.

2026-04-0445

code-apps

korchard333/claude-power-platform-community

Power Apps Code Apps Development (React + TypeScript + Vite). Use when: building Code Apps, three-layer architecture, PAC CLI workflow, Zustand state management, TanStack Query, shadcn/ui components, router basename, provider stack, form patterns, Dataverse integration from React.

2026-04-0445

dataverse-web-api

korchard333/claude-power-platform-community

Dataverse Web API reference. Use when: CRUD operations, OData queries, FetchXML, bulk operations, batch requests, metadata operations, Custom APIs, file/image columns, change tracking, solution management via API, schema creation, programmatic builds.

2026-04-0445

pcf

korchard333/claude-power-platform-community

PCF (Power Apps Component Framework) control development. Use when: building PCF controls, ReactControl, dataset controls, manifest patterns, Fluent UI v9 integration, Canvas App deployment, debugging PCF.

2026-04-0445

plugins

korchard333/claude-power-platform-community

Dataverse C# Plugin development. Use when: writing plugins, IPlugin interface, execution pipeline, entity images, shared variables, unit testing with FakeXrmEasy, plugin registration, ITracingService, sandbox limitations.

2026-04-0445

code-reviewer

korchard333/claude-power-platform-community

Power Platform Critic and Quality Reviewer (Razor). Use when: reviewing architecture, reviewing code, code review, accessibility audit, WCAG compliance check, UX review, ALM review, Dataverse schema review, Power Automate review, Canvas App review, security review. Provides severity-rated findings (S1-S4). Trigger when user says "review this", "check this code", "audit", "is this architecture solid", or after any significant implementation is complete.

2026-04-0245

name	accessibility-ux
description	WCAG 2.2 AA compliance, accessibility patterns, UX design for Power Platform. Use when: building accessible components, reviewing WCAG compliance, designing loading/empty/error states, responsive design, form accessibility, keyboard navigation, screen reader support, color contrast, focus management.

Skill: Accessibility & UX/UI Design

When to Use

Trigger when designing UI layouts, building components, reviewing user experience, or ensuring WCAG compliance in Code Apps, Canvas Apps, or PCF controls.

⚠️ REQUIRED: Load Sub-Files Before Implementation

SKILL.md is a summary only — it is NOT sufficient for implementation.

WCAG 2.2 AA Requirements — perceivable, operable, understandable, robust criteria with implementation guidance; contrast ratios
React Accessibility Patterns — semantic HTML, focus management, skip links, live regions, form a11y, dialogs, data tables, reduced motion; shadcn/ui + Radix notes
UX Patterns — loading/empty/error states, form design, navigation, toasts; typography, spacing, and dark mode design tokens
Visual Design Patterns — page composition recipes (dashboard, list, detail, form), visual hierarchy, spacing rhythm, color usage (60-30-10 rule), surface elevation, typography rules, border/divider guidance, interactive states, common visual mistakes
Component Recipes — component-level styling specifications (KPI cards, data cards, form fields, table headers/rows, badges, dialogs, navigation items, page headers, empty states, skeletons, toasts, toolbars) with exact token values, states, and makeStyles examples
Responsive Design — breakpoints, enterprise app responsive patterns (mobile / tablet / desktop)
Accessibility Testing — automated testing (axe-core, eslint-plugin-jsx-a11y, Lighthouse), manual checklist, Playwright pattern, top 10 failures

For Fluent UI V9 component accessibility (built-in ARIA, focus management via Tabster, high-contrast theme support), see code-apps/fluent-ui.md.

Anti-Patterns

Using <div> or <span> as interactive elements (buttons, links) — not keyboard accessible, not announced by screen readers. Use semantic <button> and <a> elements instead.
Adding role="button" to a <div> instead of using <button> — you then need to manually handle Enter, Space, focus, and disabled states. Native elements get these for free.
Color as the only indicator of state (error = red, success = green) — invisible to colorblind users. Always pair color with icons, text, or patterns. All color-coded states must have a visible legend. Users will guess meanings based on common conventions (yellow = warning/draft, red = error). If your color means something domain-specific (e.g., yellow = non-billable), make it explicit with a legend or label — don't rely on color alone.
Missing skip-to-main-content link — keyboard users must tab through the entire navigation on every page. Add a visually-hidden skip link as the first focusable element.
Placeholder text as the only label — disappears on input, not reliably announced by screen readers. Always use a visible <label> element.
Auto-playing animations without respecting prefers-reduced-motion — causes motion sickness for vestibular disorder users. Wrap all animations in a media query check.
Generic link text ("Click here", "Read more") — meaningless out of context for screen reader users who navigate by links. Use descriptive text: "View project details".
Missing aria-live regions for dynamic content — screen readers miss toast notifications, status updates, and inline validation messages. Use aria-live="polite" for status, aria-live="assertive" for errors.

Related Skills

code-apps — Accessibility patterns in Code Apps (React components, shadcn/ui)
canvas-apps — Accessible Canvas App design
pcf — PCF control accessibility requirements
testing — Accessibility testing with axe-core and Playwright