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 evaluates your sources against recognised accessibility standards, and keeps the evidence alongside your contract:

  • 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 issues 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 for when you need a higher bar.

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 source 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 an issue, just as it would be the other way round. This means an accessible light theme and an inaccessible dark one cannot slip through unnoticed — both are held to the same standard.

How accessibility issues 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.

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

See audits for how issues, 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 the checkable parts of those requirements into contracts and running them automatically across every source, Parlance turns accessibility from a periodic snapshot into continuous evidence — for light and dark, in design and in code, on the web and in native apps. Automated checks do not certify compliance or replace manual and assistive-technology testing; they keep the parts a machine can verify honest between expert reviews.

Next steps