core-foundations-accessibility-baseline

name	core-foundations-accessibility-baseline
description	Always-on accessibility baseline for every user-facing artifact and interface. Use to enforce perceivable, operable, understandable, and robust access before design, build, platform overlays, or verification add specifics.

Accessibility Baseline

Accessibility is a foundation, not a feature. Every interface starts from the W3C WAI principles: perceivable, operable, understandable, and robust.

Source: W3C WAI Accessibility Principles https://www.w3.org/WAI/fundamentals/accessibility-principles/

Non-negotiable standard

Use current WCAG AA as the default target unless a project sets a stronger standard. Do not treat this skill as the complete checklist; use it as the floor that every design and build task must preserve, then load phase/platform skills for details.

Never defer an accessibility issue that blocks a core task, hides information from assistive technology, traps focus, removes keyboard access, relies on color alone, prevents text resizing, causes unsafe motion/flashing, or prevents form completion.

Baseline gates

Perceivable

• Provide text alternatives for non-text content: icons, controls, images, charts, files, audio, video, and embedded applications need a meaningful accessible name or description.
• Prefer real text over images of text. If visual text is unavoidable, provide an equivalent.
• Preserve information when presentation changes: headings, lists, tables, fields, order, and relationships are represented structurally, not only through layout or styling.
• Make content distinguishable: color is never the only signal; default foreground/background contrast is sufficient; text can resize and reflow without losing information or controls.
• Provide alternatives for media: captions, transcripts, audio description, or another equivalent path appropriate to the content.

Operable

• Every task available by pointer is available by keyboard or another non-pointer path.
• Focus is visible, ordered meaningfully, and never trapped. Repeated content has a bypass route when it would slow keyboard users.
• Users have enough time. Time limits, auto-advance, moving content, interruptions, and session expiry must be stoppable, extendable, recoverable, or truly essential.
• Avoid flashing and unsafe motion. Provide reduced-motion behavior for nonessential animation.
• Navigation makes location and action clear: page/view titles, headings, link purpose, current location, and next steps are understandable without visual guessing.
• Gestures, device motion, drag, and fine pointer actions have alternatives that require less dexterity. Touch targets are large enough for reliable activation and accidental activation is recoverable.

Understandable

• Use clear, task-oriented language. Define unusual terms when the user must understand them to proceed.
• Identify language when content may be read aloud or processed by assistive technology.
• Keep repeated navigation, labels, and component behavior predictable. Significant context changes do not happen without the user's action or consent.
• Help users avoid and correct mistakes: instructions, validation, error messages, correction suggestions, review steps, and undo/reversal exist where the cost of error is meaningful.

Robust

• Prefer native semantics and platform controls. Custom controls must expose the same name, role, value, state, and interaction model as the control they replace.
• Use valid, well-structured markup or platform accessibility APIs so current and future assistive technologies can interpret the interface reliably.
• Treat third-party widgets and generated content as untrusted until their accessible names, keyboard behavior, and assistive-technology output are verified.

Phase handoff

• Design work loads this skill before core-design-* so layout, color, motion, and content do not create barriers.
• Build work loads core-build-accessibility-implementation for semantics, focus, forms, dynamic content, and custom controls.
• Verification loads core-verify-accessibility-audit when proving the result.
• Web and mobile overlays may add platform mechanics, but they do not restate or weaken this baseline.