This site is built to WCAG 2.2 Level AA. That is contractual, not aspirational. On we audited the pages we had built that day, at two screen widths, and found no contrast failures, nothing scrolling sideways, and no tap target under 24 pixels. That covers those pages on that date rather than the whole site. The sections below say what the measurement saw, what it could not see, and what is still open.
WCAG 2.2, Level AA. Fifty-six success criteria, published by the W3C, testable one at a time. We hold Level AA and we do not claim Level AAA anywhere, including where we happen to meet it.
The European Accessibility Act has applied since June 2025 to many digital services offered to people in the EU. Where a supplier sits in relation to it depends on the contract and the sector. We are not going to argue that boundary; we hold the standard.
What was measured
The sweep runs against a production build rather than the development server, so it measures the stylesheet that actually ships. It reads the colour of every text node on the page, the width of every control you can operate, and whether the document scrolls sideways.
Every text node on every page in the table, read as the browser computed it.
At 375 pixels, which is the narrow phone the sweep is calibrated to.
The raw box of every control, with no spacing exception applied to it.
Measured by us, in the rendered page, on . The method, the pages and the caveats are below.
Every page built on that date, at 375 pixels and at 1440 pixels. The portal preview is an internal review screen rather than a public page; it is here because it is the densest thing we have drawn.
| Page | Viewport | Contrast failures | Horizontal overflow | Targets under 24px |
|---|---|---|---|---|
| Home page (/) | 375 px | 0 | None | None |
| Home page (/) | 1440 px | 0 | None | None |
| Portal preview (/design/portal) | 375 px | 0 | None | None |
| Portal preview (/design/portal) | 1440 px | 0 | None | None |
An automated pass reads computed colour and box sizes. That is enough to catch the single commonest accessibility failure on the web and almost nothing else. Everything in this list is checked by a person against the ledger below, or it is in the open items further down.
Non-text contrast: borders, icon strokes and focus rings. The sweep reads text colour only, so these were checked by hand against the ledger below.
Text sitting on a texture, a gradient or an image. The standing rule is that no text sits on one without its own solid background, and that is judged by eye.
Content generated by CSS rather than written in the page.
What a screen reader actually announces.
Forced-colours and high-contrast modes.
The eligibility checker, which had not been built when the sweep ran.
The target-size check is deliberately strict. WCAG lets a small target pass if there is enough clear space around it, and a stacked column of text links technically qualifies. On a mid-range phone held in one hand that is a compliance argument rather than a usable control, so our sweep reports the raw box and we fixed the links instead of citing the exception.
Pages built after that date are checked the same way as they ship, at both widths. The table is a snapshot of one day, and it says so rather than quietly ageing. We would rather write both of these lists than publish a green tick.
The colour rules
Every pairing that ships on this site was computed in the rendered page, in sRGB, not sampled from a colour swatch. If a pairing is not in this ledger it has not been measured, and if it has not been measured it does not ship.
The brand colour is invisible as text on a white page. It fills buttons and bands and nothing else. Every marigold button carries a darker gold lip, because the fill on its own cannot be told apart from the paper it sits on.
This is why text on a gold field is almost black. It is also why nothing pale ever sits directly on marigold: our lightest ink on the same gold measures 1.60:1, which carries nothing at all.
When you see a gold word in a sentence on this site, this is the colour it is. It clears the 4.5:1 body-text threshold with room to spare, which is the only reason it is allowed to be small.
The accent word in a large heading, and nothing else. On a 15px label the same colour is a failure, which is why the two golds are separate tokens rather than one token used carefully.
Prose on this site never goes lighter than 6.82:1, which is the muted grey used for footnotes. Lightening body text because it looks calmer is not a decision anyone here gets to make.
The thresholds those ratios are judged against are not ours. Normal text needs 4.5:1. Text at 24 pixels, or 18.66 pixels bold, needs 3:1. The boundary of anything you can press needs 3:1 against the page behind it, which is why every marigold button on this site carries a darker gold lip and why a gold button never sits on a gold band.
How it is built
Every page has exactly one h1 and no skipped heading levels. Every page has a header, a navigation, a main and a footer that assistive technology can jump between, and a skip link that is the first thing a keyboard reaches. The six below are the ones worth explaining, and each one carries the way you check it.
Nothing on this site plays on its own, flashes, or moves in a way that carries information. The entrance movements are decoration. Both the ones written in CSS and the ones driven by script stop under reduced motion. The page is finished without either.
Why this is not a stretch goal
An independent annual analysis of home pages finds detectable failures on almost all of them. The failures are not exotic. They are the same four every year, and every one of them is settled by how a page is put together rather than by what it cost.
That figure and the three beside it come from an independent annual analysis rather than from an official body, and our research ledger grades them corroborated secondary. We print the grade because a number without one is the thing this whole site is arguing against.
Three questions, each one a labelled group of radio buttons rather than a row of clickable boxes. The labels stay visible. The whole thing completes with a keyboard alone, the answers survive going back a step, and the result is on screen for free with no account and no email address. If any part of that is not true when you use it, that is a defect and we would like to hear about it.
Open items
None of these stops the site being usable today. All of them are things a careful reader would find on their own, so there is no version of this page where hiding them is the better move.
4 open, 1 closed since the sweep.
Because the alternative is a statement that says everything is fine, and nobody who works in this field believes one of those. A page naming specific open items is checkable. A page claiming zero is only checkable by finding the first one.
There is a second reason, and it is commercial rather than moral. A European university asking us to evidence conformance will ask for exactly this list, alongside the automated results and a record of the manual passes. Keeping it current is less work than reconstructing it during a procurement round.
We test with a screen reader. That is not the same thing as testing with somebody who uses one every day, and we are not going to write it up as though it were.
Everything on this page is our own measurement, which is why the method is published beside it. An external audit is the obvious next step and it has not been booked.
The table above covers the pages that existed on the day. Anything built since is checked as it ships, at both widths, rather than the whole site being swept again. So that table is a snapshot and not a running total.
The native disclosure tells assistive technology whether it is open or closed, so the state is correct. The wording is not, and it is on the list.
Individual bands used to set their own scroll offset, one at a time. The durable fix is one scroll offset on the document itself, and it shipped, so a fragment link and a focused control both clear the header now. It stays on this list because a list that only grows records nothing.
If something on this site is hard or impossible to use, write to accessibility@uniconnect360.com. Tell us which page, what you were trying to do, and what happened instead. If you know your browser or the assistive technology you were using, that helps. If you do not, send it anyway.
Opens your own mail app, addressed to accessibility@uniconnect360.com.
A person reads it and answers it. We will tell you what we found and whether we can fix it. If it is a real barrier and the fix is not quick, it joins the list further up this page with the date you reported it, so you can watch it rather than take our word for it.
We have not published a reply-by date, because we have not staffed one and a target we cannot hold is worth nothing to you.
There is no contact form here. This website collects nothing: no name, no email address, no account, so the only way to reach us is a message you send yourself, from your own mailbox, which you can keep a copy of.
