Accessibility
This site aims to conform to WCAG 2.2 level AA. This page says what has been done, what has been tested, and what has not.
Standard
THINK aims to meet theWeb Content Accessibility Guidelines 2.2at level AA. Accessibility is treated as a build requirement rather than a later remediation task, and automated checks run as part of the site's test suite.
What is implemented
- Structure. Semantic header, navigation, main, and footer landmarks on every page, with one clear H1 and a heading outline that reflects the content.
- Skip link. The first focusable control on every page moves focus to the main content.
- Keyboard. Every interactive element works by keyboard. Menus use buttons for disclosures and links for destinations, close on Escape, return focus, and do not trap it.
- Focus visibility. A three-pixel focus outline with offset, on every focusable element, meeting the visibility requirements in WCAG 2.2.
- Contrast. Every text colour pair used in production is verified by an automated test against 4.5:1 for normal text and 3:1 for large text. Boundaries that carry meaning use a stronger border colour to meet the 3:1 non-text requirement.
- Colour independence. No information is conveyed by colour alone. Answer strength in Think Lab exercises is labelled in words as well as coloured.
- Zoom and reflow. Layouts use relative units and reflow to a single column at 200 percent zoom and at 320 pixels wide without loss of content or horizontal scrolling.
- Motion. The
prefers-reduced-motionsetting is honoured, and there is no autoplaying or looping motion anywhere on the site. - Targets. Interactive controls have a minimum target size of 44 by 44 pixels.
- Images. Informative images carry contextual alt text. Decorative images carry empty alt attributes.
- No JavaScript requirement. All content and navigation work with scripts disabled. Think Lab exercises fall back to a plain answer key containing every explanation.
- Print. Every toolkit resource has a print stylesheet that removes navigation and prints link destinations in full.
What has been tested
Automated accessibility checks run against representative built pages as part of the site's verification suite, alongside checks for heading structure, alt text, and colour contrast. The exact commands and results for the current release are recorded in the repository build report.
Manual keyboard testing has been performed on the header navigation, mobile menu, Think Lab exercises, and listing filters.
What has not been tested
We state this rather than implying a level of assurance we do not have.
- Screen reader testing across the full range of assistive technology and browser combinations has not been carried out.
- Testing with users of assistive technology has not yet been conducted.
- Voice control and switch access have not been specifically tested.
Automated testing detects a minority of accessibility problems. The absence of automated failures is not a claim of conformance.
Known limitations
- The mobile navigation menu requires JavaScript to open. Without it, every destination remains reachable through the footer and the site map, both of which are plain links present in the page source.
- Site search uses a static index that loads on demand and therefore requires JavaScript. The site map and hub pages provide a complete non-search route to every page.
Reporting a barrier
If any part of this site is difficult or impossible for you to use, write toinfo@arac-international.org describing what you were trying to do and what happened. Tell us what would help. If you need a resource in a different format, ask and we will supply it.
Reports of accessibility barriers are treated as defects, not feature requests, and are prioritized accordingly.