open-design/skills/dashboard/SKILL.md
Mohamed Abdallah b064637e3f
feat(craft): accessibility-baseline module + opt-ins on dashboard, hr-onboarding, mobile-onboarding (#587)
* feat(craft): add accessibility-baseline + opt-ins on dashboard, hr-onboarding, mobile-onboarding

Module 3 of 5 in the behavioral craft series proposed in #501. Modules 1 (state-coverage, #502) and 2 (animation-discipline, #515) merged earlier today.

The differentiator that survived the corpus review is native-mobile
parity. Existing OSS prior art (fecarrico/A11Y.md, awesome-copilot,
Community-Access) covers web ARIA well, none covers Flutter Semantics,
Compose semantics, iOS UIKit/SwiftUI, or RN labelling APIs.

Secondary differentiator: jurisdictional legal-floor calibration. EAA
references WCAG 2.1 (via EN 301 549 v3.2.1), not 2.2. ADA Title II
2026-04-24 deadline slipped to 2027-04-26 via 2026-04-20 IFR. Most
existing OSS a11y prior art doesn't track either accurately.

Three-loop adversarial review pass before push (codex unavailable, ran
via substitute agent). Loop 1 caught nine cuts plus four factual fixes
including a wrong Android Compose API name. Loop 2 verified and flagged
two more trims. Loop 3 said ship.

Anchored citations: WCAG 2.2 Understanding pages, ISO/IEC 40500:2025,
ADA Title II 2024 + 2026-04-20 IFR, EN 301 549 v3.2.1, WAI-ARIA 1.3 +
AccName 1.2 + Core AAM 1.2, WebAIM Million 2025, A11yn (arXiv 2510.13914),
APCA W3C silver branch.

Refs #501.

* fix(craft): accessibility-baseline review fixes (lefarcen + mrcfps)

Address all P1/P2/P3 findings:

- P1 (lefarcen): add "Keyboard operability and semantic structure" section covering tab reachability (2.1.1), activation keys, no keyboard trap (2.1.2), focus order (2.4.3), native-control-first, document language (3.1.1), heading hierarchy (1.3.1, 2.4.6), landmarks (1.3.1, 2.4.1), text alternatives (1.1.1)
- P2 (lefarcen): expand jurisdiction scope with US Section 508 (WCAG 2.0 AA), ADA Title III caveat, EU WAD reference
- P2 (lefarcen + mrcfps): rename contrast-table row to "Normal text below 18 pt regular / 14 pt bold" so the table matches the threshold rule
- P2 (mrcfps): correct "exclusive" → "inclusive" — exact 4.5:1 / 3:1 passes; the no-rounding rule is what makes 2.999:1 fail
- P2 (lefarcen): add "Prior art and scope" note differentiating from existing OSS a11y agent docs
- P3 (lefarcen): narrow APCA framing to "not part of WCAG/EN/ADA/Section 508" and clarify size/weight-dependent thresholds
- P3 (lefarcen): expand WCAG 2.5.8 exceptions list (Spacing, Equivalent, Inline, User Agent Control, Essential)
- Common-mistakes additions: Section 508/2.1 confusion, tabindex>0 anti-pattern, modal-focus-trap distinction from 2.1.2, heading-size vs level confusion

* fix(craft): accessibility-baseline mrcfps round-2 precision fixes

All three non-blocking precision items addressed:

- Update WebAIM Million benchmark from 2025 to 2026 (February 2026 crawl). Form labels: page-level 51% (was 48.2%), input-level 33.1% (was 34.2%) of 6.9M inputs (was 6.3M). ARIA: 59.1 errors on ARIA pages vs 42 on non-ARIA (was 57 vs 27); gap is ~17 in 2026, was 30 in 2025. ARIA usage 82.7% of pages (was 79.4%). Verified directly against webaim.org/projects/million/.
- Soften keyboard/semantic-structure intro: Level A items are still labeled Level A, but 2.4.6 Headings and Labels is correctly tagged AA, and the one-h1 / no-skipped-levels rules are now framed as OD craft conventions on top of WCAG's programmatic-structure floor (1.3.1).
- Tighten <a> activation note: bare <a> without href is not focusable, not a link, and not keyboard-operable. Use <a href="…"> for navigation or <button> for actions. Added a "common mistakes" entry to lock the rule.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-06 09:18:59 +08:00

2.7 KiB
Raw Blame History

name description triggers od
dashboard Admin / analytics dashboard in a single HTML file. Fixed left sidebar, top bar with user/search, main grid of KPI cards and one or two charts. Use when the brief asks for a "dashboard", "admin", "analytics", or "control panel" screen.
dashboard
admin panel
analytics
control panel
后台
管理后台
mode platform scenario preview design_system craft
prototype desktop operations
type entry
html index.html
requires sections
true
color
typography
layout
components
requires
state-coverage
accessibility-baseline

Dashboard Skill

Produce a single-screen admin / analytics dashboard.

Workflow

  1. Read the active DESIGN.md (injected above). Colors, typography, spacing, component styling all come from it. Do not invent new tokens.
  2. Classify what the dashboard monitors (sales, traffic, usage, incidents, ops, etc.) from the brief. Generate specific, plausible metric names and values — no "Metric A / Metric B" placeholders.
  3. Lay out the required regions:
    • Left sidebar (220260px): brand mark at top, 68 nav links with icons, active state uses the DS accent.
    • Top bar: page title on the left, search input + user avatar / status on the right.
    • Main:
      • Row 1: 34 KPI cards (label + big number + delta vs. prior period).
      • Row 2: one primary chart (full width or 2/3) — render as an inline SVG line / bar / area chart drawn from real-looking numbers.
      • Row 3: one secondary chart or table (recent events, top items, etc.).
  4. Write one self-contained HTML document:
    • <!doctype html> through </html>, CSS in one inline <style> block.
    • CSS Grid for the overall layout; Flexbox inside cards.
    • Semantic HTML: <aside>, <header>, <main>, <section>.
    • Tag each logical region with data-od-id="slug" for comment mode.
  5. Charts: inline SVG only, no JS libraries. A line chart is ~10 lines of <polyline> with a subtle area fill. A bar chart is N <rect>s with DS-accent fill. Label axes lightly (muted text, smaller scale).
  6. Self-check:
    • Every color comes from DESIGN.md tokens.
    • Accent used at most twice (sidebar active + one chart highlight).
    • Sidebar + top bar are sticky; main scrolls independently.
    • Density matches the DS mood — airy DSes get more padding, dense DSes (trading, crypto) tighten rows.

Output contract

Emit between <artifact> tags:

<artifact identifier="dashboard-slug" type="text/html" title="Dashboard Title">
<!doctype html>
<html>...</html>
</artifact>

One sentence before the artifact, nothing after.