/ibm-a11y-level1-audit

IBM Accessibility Level 1 — Engineering Compliance Guide

Standard: IBM Equal Access Toolkit v7.3 (required as of October 1, 2024) Aligns with: WCAG 2.2 Level A & AA · US Section 508 · EN 301 549 v3.2.1 Source: IBM Accessibility Requirements

What is IBM Level 1?

IBM divides its accessibility requirements into three progressive levels of pace of completion. IBM assigns individual tasks within each requirement (across the Design, Develop, and Test disciplines) to a level, so teams can adopt accessibility incrementally rather than mapping each success criterion to a single level:

Important: Completing only Level 1 does NOT achieve full WCAG compliance. It represents the first-priority phase in a release planning cycle. However, products completing only Level 1 can still achieve valuable accessibility and many requirements will "Support" conformance.

Scope of this guide

This guide covers only the requirements within IBM's Level 1 pace — the foundational WCAG 2.0 Level A/AA criteria plus 1.4.10 Reflow (the single WCAG 2.1/2.2 addition IBM paces at Level 1, per the v7.3 release notes). A handful of the kept requirements also carry Level 2/3 tasks for full conformance (for example, data tables under 1.3.1, or media alternatives); those follow-on tasks are out of scope here.

Every requirement IBM paces entirely at Level 2 or Level 3 — all WCAG 2.1/2.2 additions and the media audio-description criteria — is listed in Deferred to Level 2 & Level 3 with its authoritative IBM pace level. Those are not part of a Level 1 release.

Quick Reference Checklist

Principle 1: Perceivable

Principle 2: Operable

Principle 3: Understandable

Principle 4: Robust

Deferred to Level 2 & Level 3

The following criteria are not part of Level 1 and are excluded from the checklist above. Pace levels are taken from the IBM v7.3 release notes (WCAG 2.1 criteria were added in v7.1, WCAG 2.2 in v7.3). Address these in later release phases.

Media (1.2.x) applies only to prerecorded/live audio and video, which this UI does not currently ship. For completeness: captions (1.2.2 Prerecorded, 1.2.4 Live) are IBM Level 1, while audio-only/video-only alternatives and audio descriptions (1.2.1, 1.2.3, 1.2.5) are Level 3.

Section 508 (Software-specific)

Note: These Section 508 software requirements target non-web software and are tracked separately from the WCAG pace levels above (they are not assigned a Level 1/2/3 pace). For a web UI they are largely satisfied by 4.1.2 Name, Role, Value.

These apply to non-web software and desktop/mobile applications:

Engineering Implementation Guidance

These are practical implementation patterns. Most support Level 1 criteria; a few support criteria that IBM paces at Level 2/3 (tagged inline) and are included so the patterns stay in one place.

HTML/Semantic Structure

<!-- GOOD: Semantic structure -->
<main>
  <h1>Page Title</h1>
  <nav aria-label="Primary navigation">...</nav>
  <section aria-labelledby="section-heading">
    <h2 id="section-heading">Section Name</h2>
  </section>
</main>
<footer>...</footer>

<!-- GOOD: Proper form labels -->
<label for="email">Email address</label>
<input id="email" type="email" autocomplete="email" required aria-describedby="email-error" />
<span id="email-error" role="alert">Please enter a valid email address.</span>

Color Contrast

Body text:        contrast ≥ 4.5:1   (1.4.3 — Level 1)
Large text:       contrast ≥ 3:1    (1.4.3 — Level 1; ≥18pt regular or ≥14pt bold)
UI components:    contrast ≥ 3:1    (1.4.11 — Level 2; borders, icons, focus rings)
Disabled states:  exempt
Logos/brand:      exempt

Recommended tools: IBM Equal Access Checker (browser extension for Chrome/Firefox), axe DevTools, Colour Contrast Analyser.

Focus Management

/* NEVER do this without a visible replacement */
:focus { outline: none; }

/* DO this instead */
:focus-visible {
  outline: 2px solid #0f62fe; /* IBM Blue — meets 3:1 contrast */
  outline-offset: 2px;
}

// When opening a modal, move focus to the first focusable element
dialog.addEventListener('open', () => {
  dialog.querySelector('button, [href], input, [tabindex]').focus();
});

// Trap focus inside the modal while open
// Release focus and return it to the trigger element on close

Keyboard Navigation

All custom interactive components must support standard key interactions:

ARIA Usage

<!-- Live regions for status messages -->
<div role="status" aria-live="polite">File uploaded successfully.</div>
<div role="alert" aria-live="assertive">Error: Session expired.</div>

<!-- Custom buttons with meaningful labels -->
<button aria-label="Close dialog">×</button>
<button aria-expanded="false" aria-controls="menu-id">Menu</button>

<!-- Icon-only buttons always need accessible names -->
<button aria-label="Search">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

<!-- Loading states -->
<button aria-disabled="true" aria-busy="true">Saving...</button>

Images and Media

<!-- Meaningful image -->
<img src="chart.png" alt="Bar chart showing Q4 revenue increased 30% YoY" />

<!-- Decorative image -->
<img src="divider.png" alt="" role="presentation" />

<!-- Complex image with long description -->
<figure>
  <img src="architecture.png" alt="System architecture" aria-describedby="arch-desc" />
  <figcaption id="arch-desc">
    Three-tier system: frontend React app calls REST API, which connects to PostgreSQL database.
  </figcaption>
</figure>

Touch / Pointer Targets (supports 2.5.8 Target Size — IBM Level 2)

/* Ensure all interactive elements meet 24×24px minimum */
button,
a,
[role="button"],
input[type="checkbox"],
input[type="radio"] {
  min-width: 24px;
  min-height: 24px;
}

/* Preferred: 44×44px for comfortable mobile interaction */
.btn-touch {
  min-width: 44px;
  min-height: 44px;
}

Text Spacing Resilience (supports 1.4.12 Text Spacing — IBM Level 3)

Your layouts must not break when users apply these overrides via browser/OS:

/* Your CSS must gracefully handle ALL of these applied simultaneously */
line-height: 1.5 !important;
letter-spacing: 0.12em !important;
word-spacing: 0.16em !important;
/* paragraphs: 2× font-size spacing */

Test by injecting the WCAG 1.4.12 bookmarklet to verify no content is clipped or overlapping.

Testing Tools

Development Workflow

1. Design phase: Confirm color contrast, touch targets, focus states, and information hierarchy meet Level 1 before handoff.
2. Development phase: Use semantic HTML first; add ARIA only when no native element exists.
3. Component completion: Run IBM Equal Access Checker (or axe) — aim for zero violations.
4. Pull request: Include an accessibility section in your PR description noting what was verified.
5. Before release: Conduct a manual keyboard walkthrough and brief screen reader test on critical flows.

IBM Automated Checker Integration (CI)

# Install the IBM accessibility-checker
npm install --save-dev accessibility-checker

# Run against a URL
npx achecker http://localhost:3000

// Jest/Playwright integration example
const aChecker = require('accessibility-checker');

test('Home page has no accessibility violations', async () => {
  const results = await aChecker.getCompliance('http://localhost:3000', 'home-page');
  expect(aChecker.assertCompliance(results)).toBe(0);
});

New in WCAG 2.2 (IBM v7.3)

Six new criteria added — all required as of October 2024. None are Level 1; they appear in Deferred to Level 2 & Level 3 above:

Note: 4.1.1 Parsing has been removed from WCAG 2.2 and is no longer a requirement in IBM v7.3.

Common Failures to Avoid

References

• IBM Equal Access Toolkit
• IBM Accessibility Requirements v7.3
• IBM Accessibility Checker
• WCAG 2.2 Understanding Docs
• ARIA Authoring Practices Guide
• IBM Decision Trees for WCAG 2.2