cds-accessibility

Use this skill to review CDS UI for accessibility after it has been written: confirm that documented props and patterns from CDS are applied, and that the chosen CDS components have official docs describing the interaction the code needs. Do not use this file as a generic WCAG or ARIA handbook. Whenever you need official CDS documentation, load it with the cds-docs skill, which is the single source for current CDS component docs (the official docs site is cds.coinbase.com). Do not guess aria-* or RN prop names from third-party blogs.

When to use

• Use after CDS UI has been written (by you or someone else) to review whether names, state, roles, or announcements match what CDS supports.
• Use to verify React Native accessibility props (accessibilityLabel, accessibilityHint, accessibilityState, accessibilityRole, and any CDS-specific props) against the component docs.
• Use to verify web CDS components are wired with aria-*, as, role, labels, and field patterns as the CDS web component API exposes in the doc.
• Use to check whether a CDS component choice was correct when accessibility behavior (focus, dialog behavior, list semantics) should have driven it—confirm the chosen component's doc matches the task.
• Use alongside cds-code: that skill covers building CDS layout, tokens, and imports; this skill reviews CDS accessibility consumption and CDS-appropriate component choice for a11y after the build.
• Do not use as the only reference for non-CDS pages with no design-system components. Do not replace the official CDS component doc (loaded via cds-docs) with guessed prop names or third-party blog patterns.

Prerequisites

• cds-docs (required): Use the cds-docs skill to load current official CDS component documentation. Choose web or mobile, then load the component pages you need for props and a11y examples. If the cds-docs skill is not installed, tell the user it is missing and that accessibility review accuracy depends on current CDS docs; continue only with what you can verify from the codebase, and flag anything you could not confirm against the docs.
• For full CDS UI build steps (package discovery, styling, theming, visual check), the cds-code skill is the source; this skill reviews the result of that work for accessibility.

Success criteria