Accessibility
Accessibility Statement
Human Benchmark is committed to ensuring digital accessibility for people with disabilities. We aim to conform to WCAG 2.1 Level AA.
On this page
Our Commitment
Human Benchmark is committed to ensuring that our website and cognitive tests are accessible to all users, including people with disabilities. We believe cognitive self-knowledge should be available to everyone, and we work continuously to lower barriers to access.
We aim to conform to the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA. These guidelines explain how to make web content more accessible to people with disabilities, covering visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities.
Accessibility is an ongoing effort, not a one-time task. We conduct regular audits, act on user feedback, and update our implementation as standards evolve.
Measures Taken
We have taken the following measures to ensure accessibility of Human Benchmark:
All interactive elements - buttons, links, form controls, and test interactions - are accessible via keyboard. Tab order follows a logical reading sequence. No keyboard traps exist.
Text and interactive element colour contrast meets or exceeds WCAG AA minimums (4.5:1 for normal text, 3:1 for large text and interface components). Tested using automated and manual contrast checking tools.
All images include descriptive alt text. Interactive elements carry appropriate ARIA labels, roles, and states. Dynamic content updates use aria-live regions to announce score results and state changes.
The interface renders correctly at 200% zoom without loss of content or functionality. Text can be resized up to 200% using browser controls without triggering horizontal scrolling or overlapping content.
Focus states are clearly visible on all interactive elements using a 2px blue outline (sufficient contrast ratio), allowing keyboard-only users to track focus position across the interface.
Pages use correct HTML5 landmark elements (header, nav, main, footer), logical heading hierarchy (h1-h3), and semantic markup throughout, enabling efficient screen reader navigation.
Form errors are identified in text, not by colour alone. Error messages are programmatically associated with the relevant input field using aria-describedby, so screen readers announce errors on focus.
All pages adapt to viewport sizes from 320px wide upwards. Content reflows on narrow screens without horizontal scrolling. Touch targets are a minimum of 44x44px on mobile devices.
Conformance Status
The following table summarises our conformance against selected WCAG 2.1 success criteria. "Supported" means the criterion is fully met. "Partially supported" means known gaps exist that we are actively working to resolve.
| Criterion | Level | Status | Notes |
|---|---|---|---|
| 1.1.1 Non-text content | A | Supported | All images have descriptive alt text; decorative images use alt="" |
| 1.3.1 Info and relationships | A | Supported | Semantic HTML5 throughout; logical heading hierarchy |
| 1.4.1 Use of colour | A | Supported | Colour is never the only means of conveying information |
| 1.4.3 Contrast (minimum) | AA | Supported | All text meets 4.5:1 minimum; large text meets 3:1 |
| 1.4.4 Resize text | AA | Supported | Text resizes to 200% without loss of functionality |
| 2.1.1 Keyboard | A | Partial | Navigation and forms fully keyboard accessible; some test interactions require mouse/touch by design (see Known Limitations) |
| 2.4.1 Bypass blocks | A | Supported | Skip-to-main-content link present on all pages |
| 2.4.3 Focus order | A | Supported | Focus order follows DOM order and logical reading sequence |
| 2.4.7 Focus visible | AA | Supported | 2px blue outline visible on all focusable elements |
| 3.1.1 Language of page | A | Supported | lang="en" set on all page html elements |
| 3.3.1 Error identification | A | Supported | Form errors described in text; associated with fields via aria-describedby |
| 4.1.2 Name, role, value | A | Supported | All UI components have accessible name, role, and state via ARIA |
Known Limitations
We are transparent about areas where the tests have inherent accessibility constraints due to what is being measured:
Reaction Time Test - Motor impairments
The Reaction Time test measures how quickly a user can click a mouse button or tap a touchscreen. Users with motor impairments or who use alternative input devices (switch access, eye tracking, head mouse) will score systematically higher times that reflect the device latency of the assistive technology, not their neural processing speed. We note this limitation prominently on the test page. We are researching alternative measurement models for switch-based input.
Aim Trainer - Pointer precision requirement
The Aim Trainer measures motor control precision (Fitts' Law). It requires the ability to position a pointer accurately on small targets. This test is not meaningfully accessible to users without fine pointer control. The scores for users with conditions affecting motor precision (Parkinson's disease, essential tremor, etc.) will reflect the condition, not solely the underlying neural aim processing speed.
Visual tests - Low vision and colour blindness
Visual Memory and Chimp Test use spatial pattern recognition that relies on visual acuity. Users with low vision who use screen magnification may find the grid layouts disorienting at high zoom. We are working to add high-contrast and larger-grid display modes. The tests do not currently use colour as a primary differentiator, so most forms of colour blindness do not affect score validity.
Screen reader users - Live score announcements
The live score feed on the homepage uses aria-live="polite" to announce new entries. On some screen reader / browser combinations, rapid updates (every 2.8 seconds) may be announced in a way that interrupts reading flow. You can dismiss or ignore the live feed area; it is purely decorative and contains no essential information.
Testing Approach
Our accessibility testing approach combines automated tools with manual testing:
Automated testing
- axe-core accessibility engine on every page
- Lighthouse accessibility audit (score target: 95+)
- Colour contrast checker (WebAIM Contrast Checker)
- HTML validity (W3C Markup Validator)
Manual testing
- Keyboard-only navigation of all pages and tests
- NVDA (Windows) screen reader review
- VoiceOver (macOS / iOS) screen reader review
- 200% zoom rendering review across major browsers
Assistive Technology Compatibility
Human Benchmark has been tested with the following assistive technology combinations:
| Screen reader | Browser | Platform | Status |
|---|---|---|---|
| NVDA 2024.x | Chrome, Firefox | Windows 11 | Supported |
| VoiceOver | Safari | macOS 14, iOS 17 | Supported |
| JAWS 2024 | Chrome, Edge | Windows 11 | Mostly supported |
| TalkBack | Chrome | Android 14 | Supported |
Feedback and Contact
We actively welcome accessibility feedback. If you encounter a barrier that prevents you from using any part of Human Benchmark, please let us know.
When reporting an accessibility issue, please include: the page URL, the assistive technology and version you are using, the browser and operating system, and a description of the barrier you encountered. This helps us reproduce and fix the issue quickly.
We aim to respond to all accessibility feedback within 5 business days and to resolve issues within 30 days where technically feasible.
Formal Complaints
If you are not satisfied with our response to an accessibility complaint, you have the right to escalate. Depending on your jurisdiction, you may contact:
- EU / EEA: Your national supervisory authority under the European Accessibility Act
- United States: The U.S. Access Board or file a complaint under Section 508
- United Kingdom: The Equality and Human Rights Commission
For complaints about our website specifically, you may also contact us directly at [email protected].