Skip to main content
Design-to-code contract platform

Keep design and code telling the same story.

Parlance audits your design files, code, live products and native apps against shared UI contracts, glossaries, design tokens and the accessibility standards that matter — so design and code never quietly drift apart.

Free to start · no card required.

Launch updates

A short email when something ships — new extension surfaces, new audit rules, EAA guidance. No noise, one-click unsubscribe.

A demonstration of a Parlance contract audit: it checks a primary button’s clauses, catches a radius drift (a hardcoded 6px where the design token radius / md is 10px), and resolves it.

Standards & regulations

Audits against the standards that matter.

Selling to consumers in the EU? Read our European Accessibility Act guide.

What it does

A contract for your whole design system.

Define it once. Enforce it everywhere your product lives.

UI contracts

Describe what every component must be — structure, properties and states — then hold each surface to it.

Drift detection

See the moment design, code, live and native diverge — each issue tagged by severity, with the token it expected and the value it found, so the fix is obvious.

Glossaries & tokens

One shared vocabulary for colour, spacing, type and motion, sourced straight from your design tokens.

Severity triage

Issues ranked critical to minor, so what blocks a release is obvious and the rest can wait its turn.

Light & dark, equally

Both themes are first-class, mode-aware audit targets — never bolted on as an afterthought.

One contract, every surface

Design, code, live and native — held to the same contract.

Define a component once, and Parlance evaluates every surface against it. Watch a real drift surface on each — a hardcoded radius, the wrong spacing token, contrast under the line, a missing accessible name — caught by severity, then brought back in.

A demonstration of one Parlance contract for a primary button, evaluated across the four surfaces Parlance audits. In design, a 6px corner is hardcoded where the radius / md token (10px) is required; in code, the spacing / 3 token is used where the contract sets spacing / 4; on the live page, text contrast falls to 4.1 : 1, below the 4.5 : 1 WCAG AA minimum; and in the native app, the button is missing its accessible name. Parlance flags each disagreement by severity, then the surfaces are brought back into line with the contract. Automated checks like these complement, and do not replace, manual and assistive-technology testing.

Standards & evidence

Accessibility evidence, built in.

Every audit turns the standards that matter into concrete, stored evidence — the issue found, the standard and criterion it maps to, its status, and where it is kept and exported. Pick a standard to see what Parlance captures.

Standards audited — select one to see the evidence

WCAG 2.2: International guidelines for making web content more accessible to people with disabilities.WAI-ARIA 1.2: Technical roles, states and properties that help assistive technologies understand dynamic interfaces.HTML: Checks the semantic structure and native accessibility of the document.CSS: Checks visual presentation issues such as contrast, focus visibility, reflow and content hiding.Section 508: United States federal accessibility requirements for information and communication technology.EN 301 549: The European accessibility standard for digital products and services, including requirements used alongside EU accessibility legislation.

Parlance gathers and stores this evidence and flags issues for review. It does not certify compliance, or replace expert and assistive-technology testing.

EN 301 549 underpins the European Accessibility Act. This is general information, not legal advice — see the EAA guide.

Parlance maps each accessibility standard it audits to concrete evidence it captures and stores. For each standard below: what it covers, and an example of the evidence a Parlance audit produces.

  • WCAG 2.2: International guidelines for making web content more accessible to people with disabilities. Example evidence: label text 4.1 : 1, which the contract expected to be ≥ 4.5 : 1; mapped to 1.4.3 Contrast (Minimum) under WCAG 2.2 · AA, flagged as serious for review, and captured to the audit trail as an exportable record.
  • WAI-ARIA 1.2: Technical roles, states and properties that help assistive technologies understand dynamic interfaces. Example evidence: aria-checked missing, which the contract expected to be state exposed; mapped to switch · aria-checked under WAI-ARIA 1.2, flagged as serious for review, and captured to the audit trail as an exportable record.
  • HTML: Checks the semantic structure and native accessibility of the document. Example evidence: control is a <div>, which the contract expected to be <button>; mapped to native element / role under HTML, flagged as moderate for review, and captured to the audit trail as an exportable record.
  • CSS: Checks visual presentation issues such as contrast, focus visibility, reflow and content hiding. Example evidence: outline: none on :focus, which the contract expected to be visible focus; mapped to focus appearance under CSS, flagged as serious for review, and captured to the audit trail as an exportable record.
  • Section 508: United States federal accessibility requirements for information and communication technology. Example evidence: image alt missing, which the contract expected to be text alternative; mapped to aligned to WCAG 1.1.1 (A) under Section 508 · ICT, flagged as serious for review, and captured to the audit trail as an exportable record.
  • EN 301 549: The European accessibility standard for digital products and services, including requirements used alongside EU accessibility legislation. Example evidence: content clips at 320 px, which the contract expected to be reflows to 320 px; mapped to 1.4.10 Reflow (AA) under EN 301 549 · clause 9, flagged as moderate for review, and captured to the audit trail as an exportable record.

Parlance gathers and stores this evidence and flags issues for review. It does not certify compliance, or replace expert and assistive-technology testing.

What automation covers — and where people take over.

Automated audits catch a real, specific set of accessibility issues continuously. The rest needs people. Here is the honest split — so you know exactly what Parlance covers, and where human testing takes over.

Checked automatically, on every audit

Colour contrast against WCAG 2.2 AA and AAA in light and dark, design-token and semantic-role drift, missing alt text and control labels, and target sizes below the minimum — run continuously across design, code, live and native.

Captured as evidence for review

Every issue carries a severity, a location and the expected-versus-actual values — the record a designer, engineer or external auditor needs to act on. Parlance gathers the evidence; a person still makes the call.

Flagged for a human to judge

Whether alt text is genuinely meaningful, whether reading and focus order make sense, whether structure matches intent — a machine can surface these, not settle them. Parlance points; your team decides.

Left to hands-on testing

Keyboard journeys end to end, error recovery, cognitive load and real-content edge cases need a person driving the product. Automated checks narrow the search; they do not replace the walkthrough.

Needs assistive technology and specialists

Screen readers, voice control and switch access — and, for legal conformance, specialist and legal advice — sit outside any automated tool.

Continuous monitoring keeps the checkable parts honest between reviews — it does not certify compliance or replace an expert audit. Selling into the EU? See the EAA guide for how a fixed-scope conformance audit and continuous monitoring fit together.

Translate once, ship anywhere

One set of tokens. Every framework.

Define your colour, spacing, type and motion once — Parlance translates each into the declaration your team actually ships, across web, iOS and Android. Pick a token and see.

Pick a token

Ships ascolour / primary = var(--primary)

CSS
color: var(--primary);
Tailwind
text-primary
SwiftUI
Color("primary")
Compose
ParlanceTheme.colors.primary

colour / primary translates to CSS: color: var(--primary);; Tailwind: text-primary; SwiftUI: Color("primary"); Compose: ParlanceTheme.colors.primary

Every framework we cover

18 framework targets, four platforms

One token, translated to the declaration each team actually ships.

Web

CSS dialect
  • HTML
  • CSS
  • SCSS
  • Tailwind
  • React
  • Vue
  • Angular
  • Svelte
  • styled-components
  • Emotion

Apple — iOS · iPadOS · macOS

SwiftUI dialect
  • Swift
  • SwiftUI
  • UIKit

Android

Compose dialect
  • Kotlin
  • Jetpack Compose
  • Android XML

Cross-platform

native dialects
  • React Native
  • Flutter
How it works

Up and running in three steps.

  1. 01

    Define your contracts

    Set up glossaries, design tokens and UI contracts — or start from a preset and adapt.

  2. 02

    Connect your sources

    Point Parlance at your design files, code, live products and native apps.

  3. 03

    Audit & enforce

    Run audits, triage issues by severity, and keep every surface in line over time.

Meet your team where they work

Extensions for every step of the workflow.

From the design canvas to the editor to CI — Parlance plugs into the tools your team already uses.

Explore extensions
5 of 5 clauses pass

Bring your design system back into line.

Start free today. Define your first contract in minutes and audit your first surface before lunch.