Last updated 7 October 2026
We are working towards WCAG 2.1 level AA. This site is four pages and one form, so this statement is short, and it is written from testing rather than from intention.
- Colour contrast. Every text colour was measured against the background it sits on rather than judged by eye. The waitlist button is 7.3:1. White over the photograph on the institutions page is 8.3:1 at its worst pixel, which is the lit sign in the background and not the general darkness. The mint used elsewhere on the site is 1.48:1 on white, so it is never set on white: it appears only on the coloured blocks, where it clears 5:1.
- Keyboard. Everything can be reached and used from the keyboard. A skip link is the first item in the tab order. One focus style is defined for the whole site, so no control can be left without a visible ring. The destination and date pickers move between their options with the arrow keys and close on Escape.
- The questions. The FAQ is built from the browser's own disclosure element rather than from scripted panels, so it opens from the keyboard, is announced correctly, and can be searched with find-on-page even while closed.
- The form. Every field has a label attached to it, not a placeholder standing in for one. The consent box is not ticked in advance. If sending fails, the message is announced to assistive technology rather than only turning red.
- Images. The photographs are decorative and hidden from assistive technology; they carry nothing the text does not. The one link that is only an icon, LinkedIn in the footer, has a name.
- Motion. If your system asks for reduced motion, transitions and animations are switched off.
- Small screens. Checked at 360 pixels: nothing overflows sideways, so no part of the site has to be read by scrolling horizontally.
- No test with real assistive technology. The keyboard and the markup have been checked by hand; nobody has driven this site with a screen reader, and no disabled person has been asked to try it. Until that happens this page claims conformance on paper, which is not the same thing.
- No automated audit of this build. The checks above were made by hand and by measurement. We have not run an automated tool across these pages, and we will not claim a clean report we do not have.
- The destination picker is custom. It behaves like a native menu from the keyboard, but it is built rather than borrowed, and a built control is the thing most likely to behave differently under a screen reader. It is first on the list when real testing happens.
- No formal EN 301 549 declaration. Required for public-sector procurement in the EU, and it needs an audit we have not commissioned.
- Write to info@unixplore.eu and say what you were trying to do. An access problem is a defect with a higher priority than a feature, and we will tell you when it is fixed rather than closing the thread. If you cannot use the form, send us your address in an email and we will add you to the waiting list ourselves.