Accessibility.
What we aim for, what we know is not right yet, and how to tell us when we have got something wrong.
What we are aiming for
We aim to meet the Web Content Accessibility Guidelines 2.2 at level AA. We are not claiming to have got there. This statement says where we think we are.
What should work
- Every page can be navigated by keyboard, and focus is always visible.
- Text contrast meets AA against the dark background, and text can be resized to 200% without losing content.
- If your system asks for reduced motion, we honour it. Background video is replaced with a still image, the scrolling band stops, and the drawn line on the Solution Foundry page is shown complete rather than animated.
- Background video pauses when it scrolls out of view or the tab is hidden, so nothing loops away behind you.
- Nothing is loaded from a third party without you asking. The one embedded video waits for a click.
What we know is not right yet
We would rather list these than let you find them.
- Diagrams. The five dimensions model and the technology grid are interactive and carry a fair amount of meaning. Each has a text description for screen readers, but a diagram is a poor way to make an argument and we would like to do better than a description of one.
- Product screenshots. Images on the initiative pages have short captions rather than full descriptions of what the screens show.
- Some drawn figures are decorative. Where a figure only restates the sentence beside it, we mark it as decorative and leave the words to do the work. If you think one of them is carrying meaning we have hidden, tell us.
- Narrow screens lose some illustrations. Several drawn elements are hidden below tablet width rather than reflowed. No information is lost, but the page is plainer on a phone than it should be.
Telling us about a problem
Email hello@hubiq.co.uk. Say which page and what happened, and tell us what you were using if you know. It reaches the three HubIQ directors directly. We will reply, and if we cannot fix something quickly we will say so and say when.
Gideon Bullock is accountable for accessibility on this site.
How we test
Keyboard walkthroughs, contrast checks against computed values rather than source colours, and an automated check on every build that fails the build if a style rule is missing. We have not yet commissioned an independent audit. When we do, we will say what it found here.