How this site works for everyone.
Every page and every form on this site should work for anyone, whatever device, browser or assistive technology they use. This page says what we aim at, how we checked, what we know is not yet right, and how to tell us when something fails.
1 · What we aim at
We hold this site to the Web Content Accessibility Guidelines (WCAG) 2.2, level AA. In practice that means: everything works with a keyboard alone; every image, button and field has a name a screen reader can say; text can be zoomed to 400% without anything being cut off; motion stops when your system asks for reduced motion; nothing flashes, nothing is on a timer, and there are no pop-ups, cookie banners or chat widgets to get past.
The site is plain HTML, CSS and a little JavaScript. Every page reads correctly with JavaScript turned off; the one exception is noted below.
2 · How we checked
On 5 and 6 October 2026 we ran two kinds of checks on all seven pages, at desktop and phone sizes, and in every state of the three request forms (each step, the error messages, the confirmation):
- automated scanners (axe-core and Lighthouse for accessibility; the Nu HTML Checker and html-validate for the markup);
- scripted checks of what scanners cannot see: the order keyboard focus moves in, whether focus is always visible, the skip link, the menu on a phone, the forms with the keyboard alone, what a screen reader is given as the name of each control, reflow at 320 pixels, the text-spacing override, reduced motion, and the size of tap targets.
After the fixes that followed, the scanners report no failure on any page except the one described first in the next section. We keep the full audit and re-run it when the site changes.
What we have not done yet: a pass by a person using a screen reader (VoiceOver on a Mac and an iPhone, NVDA on Windows). That is the next check, and until it is done this page describes what the tools and the scripts could see, not what a blind user experiences.
3 · What is not yet right
These are the things we know about, in the order we intend to deal with them.
- Faded panels on the home page. In the sections "What we do", "Who we serve", "Why work with us" and "Our values", the panels that are not the current one are faded while you scroll. The faded text is below the contrast WCAG asks for. Every panel reaches full contrast when it becomes the current one, and the same text is readable then. We kept the fade on purpose, because it is how those sections tell you where you are; if it gets in your way, your browser's reader view shows the whole text in full.
- Single-choice questions in the forms. Questions such as "How big is your team?" are answered with buttons, not with radio buttons, so a screen reader does not announce them as a group where one answer is expected. They also need JavaScript; with it off, the page offers to send the same request by email instead. We will rebuild them as real radio buttons.
- Field outlines and placeholder text in the forms are lighter than the guideline's thresholds. Every field has its label above it, so nothing depends on them.
- The memo form's step list does not tell a screen reader which step is current, although the step change itself is announced.
- The small numbered lists on the home page move the page to a section but do not move keyboard focus there.
- A few decorative arrows and dots are read out by screen readers as characters.
4 · What comes next
The items above, in that order, are the next changes to the site. After them, the screen-reader pass described in section 2, and then the scanners become part of every deployment, so that no change goes live with a new failure. When each item is done, it leaves this list and the date at the top changes.
5 · Tell us about a problem
If something on this site does not work for you, please write to our contact address with the subject "Accessibility", or call us. Say which page, what you were trying to do, and which browser or assistive technology you use. We answer within two business days, and if a form is what fails, you can send us the same details by email and we will treat them exactly as a form request.
The address is kept out of this page's source so that spam harvesters cannot collect it, which is why it appears only with JavaScript turned on; the same address is on the contact page.
6 · Changes to this page
When this page changes, the date above changes with it. Reviewed 6 October 2026. The principles behind it are the same as on our privacy page: if a sentence isn't true on the page, it isn't true in the system either.