Accessibility

Accessibility is a requirement for usable enterprise software. This page is our internal stance: how the Funnel Design System contributes, what we still need to build or prove, and what every application must still do. It complements (and does not replace) a public accessibility statement, procurement artifacts like a VPAT/ACR, or formal conformance claims for specific products.

Standards that matter for enterprise tools

Buyers and regulators increasingly expect documented accessibility. Common references:

Artifact / standard	Role
WCAG 2.2 (Level AA)	De facto target for web UIs; most enterprise RFPs cite AA.
VPAT® / ACR	Voluntary Product Accessibility Template—structured report of how a product meets WCAG, Section 508, and often EN 301 549. Used in procurement.
Section 508 (US) / EN 301 549 (EU ICT)	Legal or contractual baselines for many public-sector and large-enterprise deals.
W3C accessibility statement	User-facing page: commitment, standard used, known limitations, contact for barriers.
Organizational policy (WAI)	How the company defines scope, ownership, testing, and timelines—useful for engineering + legal alignment.

Note: Claiming “WCAG AA compliant” or publishing a VPAT requires evidence (testing scope, product version, known exceptions). This document describes direction and system capabilities, not a certified audit result.

Principles

People first — Support real use: keyboard, screen readers, zoom, contrast needs, motion sensitivity, and cognitive load; not checkbox compliance alone.
System + product — Tokens and components remove duplication, but applications still own flows, content, data tables, and third-party embeds.
Prefer standards — Use platform conventions (focus visibility, semantics, reduced motion) over one-off hacks.
Progressive — Ship improvements continuously; document known gaps and remediation plans for stakeholders.

What the design system provides today

These are concrete capabilities in this repository that teams can rely on when building on Funnel UI.

Visual themes and user preferences

Light / dark — Documented mode switching; design tokens adapt per mode.
**High contrast ** — Additional token sets strengthen borders and contrast-related decisions for component colors.
Larger text — html.large-text switches the base font scale via --f-fonts-base → --f-fonts-base-large.
User preference — Nav app lets users choose light, dark or OS defult mode and accessibility settings mentioned above (larger text and higher contrast)

Motion

Reduced motion — Several components and utilities scope transitions under @media (prefers-reduced-motion: no-preference) (e.g. buttons, dropdowns, modals, toggles, tooltips, theme utilities). Guidelines: Animation principles.

Focus and interaction

Consistent focus — Documented fun-outline / focus-visible:fun-outline pattern and token-backed focus ring for keyboard users. See Interaction states.

Foundations

Typography and color tokens — Intentional scales and semantic tokens; apps should use tokens instead of hard-coded values so theme variants (including large text and high contrast) remain coherent.

Web components

Stencil-based components — Many patterns (labels, roles, keyboard support) are implemented in shared components; consuming apps should prefer these over bespoke controls when possible.

Gaps and planned work

The following are typical next steps for a mature enterprise posture. Treat as a backlog to prioritize, not a promise of order or date.

Area	Why it matters	Planned / desired direction
Conformance evidence	Procurement asks for proof	Define test scope per product; maintain VPAT/ACR updates per major release; track known issues with remediation.
Automated + manual QA	WCAG needs more than linting	Add or standardize axe/similar in CI for docs and critical paths; keyboard and screen reader test scripts for core flows.
Component audit coverage	Gaps hide in complex widgets	Systematic review of comboboxes, tables, date pickers, charts, and custom overlays for roles, names, focus management, and announcements.
Authoring guidance	Content breaks a11y faster than chrome	Expand guidelines for headings, alt text, error summaries, live regions, and data visualizations.
Third-party content	Embeds are often non-conforming	Policy for iframes, maps, chat widgets, and PDFs (viewer choice, transcripts, captions).

What product teams must own

Even with a strong design system, each application is responsible for:

Semantics and structure — Correct headings, landmarks, labels (<label>, aria-label only when necessary), and associations for custom fields.
Keyboard — Full flow without traps; logical tab order; shortcuts documented and not conflicting with AT.
Focus management — Open/close dialogs and routed views; return focus; avoid stealing focus on unrelated updates.
Dynamic content — Loading, errors, and async updates communicated accessibly (e.g. aria-live, polite/assertive choices).
Non-text content — Icons with text or accessible names; charts and images described where needed.
Contrast in context — Tokens help, but data overlays, badges on images, and custom colors can still fail WCAG; verify in both themes and high contrast.
Zoom and reflow — Layouts that work at 200% zoom and with large text class combinations; no clipped essential controls.
Sizing outside tokens — Prefer design tokens first. When you must break away, use rem (or other root-relative sizing) for type and spacing so browser text size, page zoom, and Funnel’s large-text theme scale predictably. Fixed px for body-scale text or tight layout boxes is a common source of clipped or unreadable UI.
Small screens and touch — Treat mobile and narrow viewports as core surfaces: no hover-only essential actions; touch targets large enough to meet WCAG expectations (e.g. 2.5.8); support orientation changes; ensure reflow so users can complete tasks without horizontal scrolling traps for whole flows.
Respect user settings — Honor prefers-reduced-motion; apply setTheme (or equivalent) so user-chosen high contrast / large text actually applies at document.documentElement.
Procurement readiness — For customer-facing commitments, coordinate with legal/compliance on public statement, VPAT scope, and support contacts. Draft ACR / VPAT working templates (cover sheet, WCAG 2.2 AA criterion table, evidence log, 508 / EN 301 549 notes) live in the design repository under docs/accessibility/ — copy into the official ITI VPAT for customer delivery.

Related guidelines

Interaction states — Focus outline and states
Animation principles — Reduced motion
Typography — Type scale and emphasis
Sizes — Spacing and layout scale
Colors — Token usage and modes
Setup — Integrating @funnel-io/theme and setTheme

Feedback

Improvements to this stance or to system-level accessibility should go through the normal contribution channels. For barriers in a live product, routes typically include support and/or a dedicated accessibility contact once defined by the product org.