Keep design and code telling the same story.
Your design files, your code, your live site and your native apps should all agree on what a component is. Parlance holds every one of them to a single shared contract — and shows you the moment any of them drifts.
Free to start · no card required.
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.
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.
Not a screenshot diff. Not a token sync. Not a scanner.
Each of those solves one slice of the problem. Parlance holds the whole system — design, code, live and native — to a single contract, with severity triage and accessibility standards built in.
Screenshot diffs
They flag when a rendered component changes shape.
Parlance checks the component against the contract it must meet — across design, code, live and native at once.
Token sync
It pushes design tokens from one place into your code.
Parlance holds every surface to those tokens and catches the moment one drifts off them.
Accessibility scanners
They scan a single page for issues on demand.
Parlance makes each standard a clause every surface is measured against, continuously.
Design-system docs
They describe how a component is supposed to look.
Parlance enforces that description everywhere your product actually ships.
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.
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
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 auditAutomated
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 reviewEvidence
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 judgeDesign review
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 testingHuman 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 specialistsAssistive tech
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.
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)
color: var(--primary);text-primaryColor("primary")ParlanceTheme.colors.primarycolour / 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
Up and running in three steps.
- 01
Define your contracts
Set up glossaries, design tokens and UI contracts — or start from a preset and adapt.
- 02
Connect your sources
Point Parlance at your design files, code, live products and native apps.
- 03
Audit & enforce
Run audits, triage issues by severity, and keep every surface in line over time.
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.
Built to the standard it checks for.
No borrowed logos, no invented numbers — just what the product does, and the fact that we build Parlance to the same tokens and standards we ask of you.
We use it ourselves
We build Parlance with the same design tokens, contracts and accessibility standards we ask of you — light and dark treated as equals.
Standards-backed
Every accessibility check maps to a published criterion — WCAG 2.2, WAI-ARIA 1.2, Section 508, EN 301 549 — not a house opinion.
Founding cohort
Be one of the first teams to run it, and help shape where it goes next.
Your data stays yours. See exactly what we collect and how we handle it in our privacy policy.
Simple, transparent pricing.
Free forever for one design system. Paid plans from €25 a month.
Bring your design system back into line.
Start free today. Define your first contract in minutes and audit your first surface before lunch.