Under Construction: The content on this site draft material. It is not the official content of this site and should not be followed at this time.

Not Legal Advice: The content on this site is provided for informational purposes only and does not constitute legal advice. Consult a qualified attorney for advice specific to your situation.

This library ships as plain dist/a11y-defense-components.css and dist/a11y-defense-components.js so teams can distribute and consume it without a framework or build pipeline.

What ships

  • dist/a11y-defense-components.css – monochrome component styles using black, white, and grayscale with visible focus treatment
  • dist/a11y-defense-components.js – vanilla JavaScript behaviors for the interactive patterns in this system
  • package.json – package metadata with direct exports for the JavaScript bundle and stylesheet

Supported patterns

Native-first components

These components use native HTML semantics and rely primarily on CSS:

  • Button
  • Checkbox
  • Radio group
  • Select
  • Slider
  • Table
  • Breadcrumb
  • Pagination
  • Card
  • Alert
  • Skip link

Enhanced interactive components

These components keep native HTML where possible and add JavaScript only for the required behavior:

  • Accordion
  • Disclosure
  • Tabs
  • Dialog / modal
  • Menu button
  • Switch
  • Tooltip
  • Toast
  • Combobox
  • Tree view

Distribution

<link rel="stylesheet" href="/dist/a11y-defense-components.css">
<script src="/dist/a11y-defense-components.js" defer></script>

The script auto-initializes on DOMContentLoaded. For dynamically inserted markup, call A11yDefenseComponents.init(rootElement).

Package consumers should import the JavaScript entry point and the stylesheet separately:

import A11yDefenseComponents from 'a11y-defense-components';
import 'a11y-defense-components/styles';

A11yDefenseComponents.init(document);

The package name in both examples and package.json is a11y-defense-components.

Markup conventions

The library expects semantic HTML plus the same ARIA and keyboard patterns already documented in the design system.

  • Accordions use data-a11y-accordion with .a11y-accordion__trigger buttons
  • Disclosures use data-a11y-disclosure
  • Tabs use data-a11y-tabs and standard tablist / tab / tabpanel roles
  • Dialog triggers use data-a11y-dialog-open; close buttons use data-a11y-dialog-close
  • Menu buttons use data-a11y-menu-button
  • Switches use data-a11y-switch on a <button role="switch">
  • Toast triggers use data-a11y-toast-trigger
  • Tooltip triggers use data-a11y-tooltip-trigger
  • Combobox wrappers use data-a11y-combobox
  • Tree views use data-a11y-tree

Example

<link rel="stylesheet" href="/dist/a11y-defense-components.css">

<div class="a11y-card">
  <h2 class="a11y-card__title">Review status</h2>
  <p>Use native controls first, then opt into JavaScript behaviors only where the pattern requires it.</p>
  <button class="a11y-button" type="button">Primary action</button>
</div>

<div class="a11y-accordion" data-a11y-accordion>
  <h2 class="a11y-accordion__heading">
    <button
      class="a11y-accordion__trigger"
      type="button"
      aria-expanded="false"
      aria-controls="library-panel-1"
    >
      Keyboard support
    </button>
  </h2>
  <div class="a11y-accordion__panel" id="library-panel-1" hidden>
    <p>Arrow keys move between triggers. Enter and space toggle the current section.</p>
  </div>
</div>

<script src="/dist/a11y-defense-components.js" defer></script>

Accessibility guardrails

  • The shipped palette is limited to black, white, and grayscale for predictable contrast
  • Focus indicators are always visible and do not rely on color alone
  • JavaScript behaviors are written as progressive enhancement around semantic HTML
  • Interactive patterns follow the same WCAG 2.2 A / AA and WAI-ARIA APG guidance used elsewhere in the design system
  • Components avoid layout assumptions so they can be placed in block, grid, flex, or fixed-width contexts

Integration notes

  • Use the CSS classes directly or map them in your own templates
  • Keep accessible names visible and stable
  • Prefer native controls over custom equivalents whenever native HTML already meets the requirement
  • Test any composed experience with keyboard-only navigation and screen readers before release