Skip to main content
parlance — home

Accessibility

Accessibility is first-class in parlance, not a separate pass bolted on at the end. The same contracts and glossaries that keep design and code aligned also hold your product to recognised accessibility standards — and they do so for light and dark equally.

Standards covered

parlance audits your surfaces against the standards that matter for accessible, conformant interfaces:

  • WCAG 2.2 — the Web Content Accessibility Guidelines, including contrast and other success criteria.
  • WAI-ARIA 1.2 — the Accessible Rich Internet Applications specification for roles, states and properties.
  • Section 508 — the United States federal accessibility requirements.
  • EN 301 549 — the European accessibility standard for ICT products and services.

These standards are evaluated alongside structural checks against your contracts, so accessibility findings appear in the same audit as everything else rather than in a separate report.

Contrast checking

Colour contrast is checked against WCAG 2.2, and the result is reported at both conformance levels:

  • AA — the standard target for body text and interface elements.
  • AAA — the enhanced target where you need a stronger guarantee.

Contrast is part of the contract itself. A contrast clause ties a foreground and background pairing to an accessible result, so the requirement is enforced rather than merely suggested. Because colour values come from semantic roles in your glossary, the contrast that was verified when you built the theme is the same contrast checked when a surface is audited.

You also see contrast live while you work. In the Theme editor, as you map semantic roles to light and dark values, parlance reports the contrast of each meaningful pairing against AA and AAA in real time — so an inaccessible combination is visible the moment you create it, not weeks later in an audit.

Light and dark as equal targets

In parlance, light and dark are both first-class. Neither is the primary mode with the other treated as an afterthought.

Every contrast check runs in both. A semantic role is defined for light and for dark together, and both values are audited. A pairing that passes AA in light but fails it in dark is a finding, just as it would be the other way round. This means a product cannot ship an accessible light theme and an inaccessible dark one — both are held to the same standard.

How accessibility findings show up in audits

Accessibility results are part of the same audit as the rest of a contract's clauses. When you audit a design file, a code repository, a live URL or a native app, accessibility checks run alongside structural ones, and the results are reported together.

  • Findings are grouped by severity, so the most serious accessibility problems surface first.
  • A contrast failure, or a value that does not match its accessible glossary entry, is reported as drift against the contract.
  • Because light and dark are audited together, findings make clear which mode is affected.

See audits for how findings, severities and drift are presented.

Why it matters

Accessibility is both a legal and an ethical baseline, and standards such as WCAG 2.2, Section 508 and EN 301 549 set out what conformance requires. By building those requirements into contracts and checking them automatically across every surface, parlance turns accessibility from a periodic, manual review into a continuous guarantee — one that holds for light and dark, in design and in code, on the web and in native apps.

Next steps