Use native controls.
Start with buttons, links, inputs, headings, lists, and landmarks. Add ARIA only where native semantics do not express the behavior. Give every control a useful name.
INCLUSIVE BY DESIGNClear for everyone.
Clear for everyone.
Usable every day.
A practical guide to applying this system with care: readable surfaces, predictable controls, useful feedback, and room for different ways of using the web.
Working standard · WCAG 2.2 AA target01 — Accessibility
The baseline
Build toward WCAG 2.2 Level AA across complete pages and journeys. A component can support accessibility; its content, combinations, and final implementation determine whether the experience conforms.
Keep the promise visible.
Label samples as samples. Describe the destination or result of an action. Preserve entered information and give people a clear way to recover from errors.
The library demonstrates these patterns. Automated checks are one part of verification, not a claim that every assistive-technology combination has been tested.
02 — Accessibility
Color, contrast & surfaces
Measure the actual foreground against its adjacent background in every state. Normal text needs at least 4.5:1; large text needs 3:1 (at least 24 CSS px, or about 18.7 CSS px bold). Meaningful icons and the visual boundaries needed to identify controls need 3:1. Decorative borders can stay softer.
Light surfaces
Deep blue on Canvas
#1D5273 / #F6F7F7
Use deeper blue for links and meaningful icons. Sky blue is a fill or accent here, not small text.
Dark surfaces
Pale blue on Blue-black
#C2E9FF / #0A131A
Use pale blue for icons and links. Keep neutral body text light enough to read comfortably.
Glass, texture & color swatches
- Test glass panels over the brightest point beneath them. Keep a stable dark backing if photography or gradients change.
- Use pinstripes as decoration. They must not reduce legibility or carry meaning.
- Put color names and values on a stable neutral label area. Every swatch is a keyboard-operable copy button.
- Pair error, success, and selection colors with words, icons, or patterns. Underline inline links.
03 — Accessibility
Keyboard, focus & targets
Every action must work without a pointer. Keep the tab order aligned with the reading order, make focus visible, and avoid keyboard traps. Skip-to-content bypasses repeated navigation.
- Buttons: Enter or Space activates. Links use Enter. Do not make a clickable card contain conflicting nested actions.
- Accordions: Enter or Space opens the focused heading button. Its expanded state and controlled panel are connected. Collapsed content is hidden from focus and the accessibility tree.
- Tabs: Left/Right moves among tabs; Home/End reaches the first/last. One tab is in the tab order. Tab then moves into the selected panel.
- Focus: use a 3px ring with an offset. Sticky bars must not cover the focused control. Focus and selection are distinct states.
- Targets: aim for 44 × 44 CSS px for stand-alone controls. WCAG 2.2 AA sets a 24 × 24 minimum with defined exceptions, including spacing and inline text.
Accordion pattern · Tabs pattern · Target size · Unobscured focus
04 — Accessibility
Forms that help people succeed
Keep a persistent label for every field; placeholders are examples, not labels. Group related choices with a fieldset and legend. Connect hints and errors to the field they explain.
- Mark required fields in words or with a explained asterisk, and enforce the requirement with native validation constraints.
- Use appropriate input types and autocomplete values. Keep text-entry fields at least 16px to support comfortable mobile use.
- Make the whole checkbox label clickable. Keep the 20px, heavier check centered within its 26px box; show a visible ring on keyboard focus.
- On validation, provide a focused error summary with links to affected fields. Name the issue and explain how to fix it. Retain all valid input.
- Announce success politely and keep the message available. A toast must not be the only source of essential information.
- For attachments, offer a file picker as well as drag-and-drop, show allowed types and size limits, and allow removal before submission.
05 — Accessibility
Content, iconography & media
- Use one descriptive H1 per page and a logical heading hierarchy. Choose heading levels for structure, then apply the visual style.
- Give informative images concise alternative text for their purpose. Use empty alt text for purely decorative images. Do not repeat adjacent text unnecessarily.
- Pair important icons with a visible label. Decorative Font Awesome icons use
aria-hidden="true"; icon-only controls need an accessible name. - Placeholders are labeled specimens, not finished photography. Reassess contrast, cropping, alt text, and text overlays when replacing them.
- Provide captions for prerecorded video with audio, transcripts for audio-only content, and audio descriptions where visual information is not conveyed by the soundtrack.
- Give tables meaningful headers. Scroll a wide table within its own labeled region rather than forcing the entire page sideways.
06 — Accessibility
Reflow, enlargement & motion
Keep content usable at 200% text enlargement and at a 320 CSS pixel viewport, equivalent to 400% browser zoom on a 1280px-wide viewport. Ordinary content should reflow without two-direction scrolling; complex tables may need their own scroll region.
- Use flexible grids and wrapping labels. Do not clip text with fixed heights or hide information just to make it fit.
- Allow custom text spacing without losing content: 1.5 line height, 2em paragraph spacing, .12em letter spacing, and .16em word spacing.
- Respect reduced motion: remove decorative movement, animated scrolling, and moving light effects. Interaction must remain understandable without animation.
- Respect forced colors and high-contrast settings. Keep native control semantics and do not rely on background images for essential information.
Reflow · Text spacing · Reduced interaction motion (AAA practice)
07 — Accessibility
Before a page goes live
Run these checks on complete pages and real content. These local checklist controls are a demonstration; checking them does not certify a release.
Verification record
Use automated scans to catch detectable failures, then test keyboard journeys, focus visibility, screen-reader announcements, zoom and reflow, contrast over real media, and errors. Record the page, browser, assistive technology, viewport, date, findings, and fixes.
Do a dedicated screen-reader review in VoiceOver with Safari and NVDA with a supported browser before treating a release as verified. Include users with disabilities in usability testing where possible.