Clarity Accessibility
Access only works when it can work for you.
Accessibility is not a single setting or a badge. It belongs in language, structure, motion, contrast, keyboard access and every new interaction.
How we work
More ways in. Fewer barriers between.
Perceivable
Scalable text, alternative text and no information conveyed through colour alone.
Operable
Keyboard access, visible focus and no essential interaction that depends only on complex gestures.
Calm motion
Reduced motion and reduced transparency are respected as separate system settings.
Understandable
Clear language, stable navigation, unambiguous errors and confirmation before consequential actions.
Robust
Semantic HTML and accessible names provide the foundation for assistive technologies.
On this website
System settings continue to work.
The current implementation includes a skip link, visible focus states and semantic headings. It respects reduced motion, reduced transparency and increased contrast as separate settings.
Animation is a progressive enhancement: content remains visible without JavaScript and with reduced motion. Forms use real labels and error messages rather than purely visual cues.
That is an implemented starting point — not a declaration of formal WCAG conformance.
In the Clarity app
Foundations that already respond to your system.
These statements describe implementations that can be evidenced in the current source. They do not mean that every individual surface has already received a complete review.
Relative text
Core SwiftUI building blocks use relative text styles so Dynamic Type can enlarge content instead of squeezing it beneath a fixed point size.
Spoken meaning
At reviewed points, complex values, chart elements, statuses and icon-only buttons have their own VoiceOver labels, values or hints.
Less motion
Several core transitions and value animations read Reduce Motion and switch to calm identity or opacity states.
System contrast
ClarityKit leaves contrast and accessibility palettes to system colours instead of forcing a separate colour table for every setting.
Targets and order
Reusable controls account for 44-point targets, semantic groups, headings and selected states.
Verification status
Implementation and evidence are two different things.
That is why this page shows not only what has been built, but what still has to be evidenced before any formal statement.
- Website today
- A skip link, semantic regions, visible focus, real form labels, alternative text and progressive reveals are implemented.
- Clarity foundations today
- Dynamic Type, VoiceOver metadata, Reduce Motion and system-based contrast can be evidenced in core and several feature-specific views.
- Still open
- A complete, documented review of the entire app with real assistive technologies and people who use different access methods.
- Publication boundary
- Until that review is complete, we claim neither a WCAG conformance level nor a fully accessible app.
Review route
Test first. Claim second.
Before a conformance statement, automated checks, complete keyboard navigation, zoom and reflow, screen-reader tests, contrast measurement and tests with people who use different access methods all belong in a documented acceptance process.
- Keyboard access and visible order
- VoiceOver and accessible names
- 200% zoom and narrow reflows
- Reduced motion, transparency and increased contrast
- Errors, status messages and time-sensitive flows
A barrier is a product defect.
Tell us the page, device, browser or assistive technology and what you were trying to achieve. We do not invent a response deadline, but we do provide a clear support case with a traceable status.