Accessibility
Blink should be usable by as many people as possible. This page covers only our accessibility commitments, standards, and how to reach us about barriers — nothing else.
Our commitments
What we design and test for on every release cycle.
Keyboard-first navigation
Core marketing pages and product flows are operable with a keyboard alone — including focus order, visible focus rings, and skip links to main content.
Screen-reader semantics
Headings, landmarks, labels, and ARIA where needed are structured so assistive technologies can announce Blink’s content in a predictable order.
Contrast & typography
Text and interactive elements target WCAG 2.2 AA contrast on our dark theme. We avoid relying on color alone to convey meaning.
Motion preferences
Decorative motion can be reduced. Prefer reduced motion when your system requests it, and use the site motion control when available.
Standards we target
- Target standard
- WCAG 2.2 Level AA
- Supported platforms
- Modern evergreen browsers on web, iOS, and Android
- Assistive tech
- VoiceOver, TalkBack, NVDA, and JAWS (latest stable)
- Feedback channel
- accessibility@blink.app
Day-to-day practices
Concrete patterns we apply across Blink surfaces.
Forms & errors
Inputs expose associated labels, required state, and clear error text that is announced to assistive technologies.
Images & media
Informative images include alternative text. Decorative art is hidden from assistive tech. Captions and transcripts are planned for long-form video.
Touch & hit targets
Primary controls are sized for touch and pointer accuracy, with spacing that reduces accidental activation.
Continuous improvement
Accessibility is part of design review and release QA. We track issues, prioritize blockers, and ship fixes in regular releases.
Found a barrier?
Tell us what you were trying to do, which page or screen, and which assistive technology you use. We prioritize accessibility defects alongside security issues.
Contact accessibility support