Accessibility Statement for Atlas

Conformance status

Updates since publication

The Web Content Accessibility Guidelines (WCAG) define requirements for making digital content more accessible to people with disabilities. Atlas was assessed against WCAG 2.2 at Levels A and AA, which is 55 individual success criteria. Of those:

Read that table carefully, because the four-way split can flatter a result that does not deserve it. WCAG treats a success criterion as met or not met, with nothing in between. Counted the way the standard itself counts, 29 of the 55 criteria are met and 26 are not (23 supports + 6 not applicable) — the 19 "partially supports" rows fall on the failing side. By level, Atlas meets 17 of the 31 Level A criteria and 12 of the 24 Level AA criteria.

We state it this way deliberately. A reader who added 23 and 19 and concluded that Atlas meets three-quarters of the standard would be wrong, and we would rather say so than let the arithmetic do the flattering. It is also worth saying that Level A is the more serious of the two shortfalls: those are the criteria whose failure tends to stop someone completing a task rather than make it harder.

One note on the six "not applicable" results, five of which concern audio and video. (The sixth is the criterion about controls operated by moving or shaking the device, which Atlas does not use.) Tychron authors no audio or video in Atlas. Atlas does display multimedia messages sent by and to our customers, and that content may contain audio or video we did not create and cannot caption. Those criteria are recorded as not applicable to Atlas as a product; they are not a claim that customer message content is accessible.

Scope of this statement

Applies to

The Atlas customer portal (atlas.tychron.online) and the Atlas administrative portal, an internal operations interface reachable only by Tychron staff

Version assessed

2.5.345

Standard applied

WCAG 2.2, Levels A and AA

Assessment date

29 July 2026

Assessment method

Self-evaluation, combining source review with automated and instrumented browser testing

Browser tested

Chromium only. Firefox and Safari were not tested.

Pages rendered

Fifteen, of the 401 routes the application defines — 105 in the customer portal and 296 in the administrative portal. Source review covered the whole application.

Known limitations

The following barriers are known to us. Each entry describes what a user encounters, who it affects, and where things stand. This list is deliberately specific — a vague statement is not useful to someone deciding whether they can do their job in our software. They are grouped by the way people work, because most readers care about the subset that applies to them rather than the whole catalogue.

If you use a screen reader

1. Most pages have no main heading. Screen reader users often navigate by jumping between headings, and use the first heading to confirm which page they have landed on. In Atlas, most pages currently begin partway down the heading structure instead of with a page title, and one administrative page has no headings at all. Partial workaround: the browser tab title is specific and descriptive on almost every page — but not on the home page of either portal, where it reads only "Atlas". So the workaround is unavailable on exactly the page you land on first. We would rather point that out than offer a workaround with a hole in it. Fix identified; this is our highest priority. Update, 5 August 2026: partially fixed in v2.5.488 — both portals' home pages now begin with a main heading (the account name on the customer portal, the operations title on the administrative one, visually unchanged), which closes the hole in the workaround above on exactly the page it named. The standard index and detail layouts, and the attention page, already carried one; pages built on custom shells — forms, wizards, and a handful of bespoke views — still lack a main heading and keep this item open. Pending re-assessment.
2. Many dropdowns and toggles do not announce what they control. A screen reader may read a dropdown as "Select option" or a switch as "Toggle setting" rather than naming the actual setting. On a page with several of these, they are difficult to tell apart. We count 331 controls in this state — 188 dropdowns and 143 toggles. Fix identified.
3. Confirmation and error messages are visible but not announced. When an action succeeds or fails, Atlas shows a brief on-screen message. That message is not announced by assistive technology, so a screen reader user may not learn the outcome of what they just did. Validation errors attached to a specific form field are announced, with one exception: 23 error displays use a different component that does not announce. Everything else — saves, deletions, exports, copy-to-clipboard, and server errors — is not announced at all. There are 586 such messages across the application. Fix identified. Update, 5 August 2026: substantially fixed in v2.5.488 — the surface that displays these messages is now a persistent polite live region, present in the page before any message lands (the detail that makes announcement actually work), so every such notice raised anywhere in either portal now announces without moving focus. Not covered: the 23 non-announcing field-error displays, inline status text that changes in place, and badge counts that tick over — the re-audit should recount the residual. We have verified the markup, not yet listened to it: screen-reader testing remains undone. Pending re-assessment. Further update, later the same day: the 23 displays now announce as well (v2.5.491 — the block component they share gained the same alert semantics its field-level sibling always had), which leaves inline status text that changes in place, and badge counts, as the remaining gap in this item. Pending re-assessment.
4. Error messages are not linked to the fields that caused them. When a form field is rejected, the error text appears and is announced, but the field itself is never marked as invalid. If you move away and come back to the form, nothing identifies which input is the one at fault. Update, 5 August 2026: fixed in v2.5.491 — while a field is displaying errors, the shared field component now marks its control invalid and links it to the error text, so assistive technology reads the error with the field, including on a return visit. When the errors resolve, all of it is cleanly removed, and any descriptions the control carried for other reasons are preserved throughout. One component change reaches roughly 2,976 fields across the application. Verified in markup and unit tests; screen-reader listening still pending. Pending re-assessment.
5. Data tables do not identify their column headers. 104 tables in Atlas render header cells without the association that tells a screen reader which column a given cell belongs to. Reading a row therefore gives you the values without reliably giving you what each value means. Fix identified: a single change to the shared table component covers all 104. One further table, on the termination-tariff form, has a two-level header that needs its own separate fix. Update, 5 August 2026: fixed in v2.5.488 — every header cell the shared component renders, including the selection and actions columns, now carries its column association, covering all 104 tables in one change. The termination-tariff table's two-level header remains open. Pending re-assessment.
6. Dialogs do not announce their own name. When a dialog opens, keyboard focus moves into it correctly, but the dialog itself has no accessible name, so it may be announced only as "dialog". Fix identified. Update, 5 August 2026: fixed in v2.5.489 — the shared dialog component now takes its accessible name from its own visible heading, so the announced name is the same title a sighted user reads; the one shipped dialog with no heading is named explicitly, and the handful of dialogs that do not use the shared component already carried labels. A unit suite pins the naming logic. This does not close the separate unnamed dropdowns-and-toggles item above — those are different elements, counted separately. Pending re-assessment.
7. The company logo on the sign-in page is an unnamed link. On both portals, the brand logo above the sign-in form is a link with no text alternative, so it is announced without any indication of where it goes. Update, 3 August 2026: fixed in v2.5.467 — the logo link now carries an accessible name. Lighthouse's link-name audit, previously the one accessibility finding on that page, now clears, and the login page audits 100 for accessibility in our instrumented run. That figure describes one automated tool on one page, not the application. Pending re-assessment.
8. Some status icons convey information that is not available as text. Four status indicators render as decorative icons with no text equivalent, so the state they represent is not conveyed to assistive technology. Update, 3 August 2026: fixed in v2.5.469 — each of the four now provides a per-state text label (for example "Active", "Processing", "Cancelled"), rendered as an image role with an accessible name and exposed as a tooltip on hover, so the state no longer rides on colour and shape alone. A unit test pins each of these indicators to a non-empty label so the gap cannot silently reopen. This closes the four indicators the assessment counted; other status surfaces across the application will be spot-checked at re-audit. Pending re-assessment.

If you navigate by keyboard

1. Some elements cannot be reached or operated by keyboard. Individual day cells in the date picker, some rows in shared request lists, and certain horizontally scrolling table regions cannot be operated with a keyboard alone.
2. A few controls show no focus indicator at all. Under real keyboard traversal, 6 of the 44 stops on the customer home page and 5 of the 45 on the administrative home page draw nothing whatsoever when focused. They are the "Customize layout" button and the time-range buttons — Hourly, Today, Last 7 Days, Current Month, UTC, Local — plus a table horizontal-scroll control on the administrative numbers page, which switches its outline off explicitly. On those, keyboard users lose track of their position entirely. Update, 1 August 2026: fixed in v2.5.393 — the focus ring was rebuilt at the token layer, and all eleven of these controls now draw a two-pixel outline. Pending re-assessment. Update, 3 August 2026: extended in v2.5.467 — a single application-wide :focus-visible outline now applies to everything focusable, so keyboard focus no longer falls back to the browser default anywhere in the application. It is written at zero specificity: every purpose-built component ring still wins where one exists. This is a floor, not a repaint, and it does not make the elements in item 1 above keyboard-reachable — that item remains open. Pending re-assessment.
3. The focus indicator is too faint to see reliably. Where a focus outline is drawn, it is drawn in a translucent teal that measures 1.23:1 against the light theme's background and 2.44:1 against the dark theme's, where 3:1 is the requirement. In practice: on a pale screen the ring marking your position may be hard to make out. Together with the entry above, this means Atlas fails both the requirement that focus be visible and the requirement that it have sufficient contrast. The dark theme is better here but still short of the requirement — we are not offering it as a workaround. Fix identified, and grouped with the contrast corrections below. Update, 1 August 2026: fixed in v2.5.393 for the standard themes — the outline colour is now computed per theme to clear 3:1 against the surfaces it actually sits on (the light theme's ring is darkened deliberately, because the brand teal alone measures roughly 2:1 on white; the monochrome modes use pure black/white). The high-contrast display mode's own focus outline, noted under low vision below, is a separate token and is still open. Pending re-assessment. Update, 3 August 2026: that remaining piece — the high-contrast mode's own focus outline — has since been closed in v2.5.469; see the annotation under low vision below.
4. Focus can land underneath a sticky element. The page-level layout reserves space so that a focused control is never hidden behind the fixed header, but scrolling regions nested inside a page do not inherit that treatment. Inside those, a focused control can end up obscured.
5. The Escape key does not close many dialogs. Escape is the conventional way to dismiss a dialog. In Atlas it depends on which dialog you are in. The shared confirmation dialog — the "are you sure?" prompt, used in 62 places — always closes on Escape. Among the 54 other dialogs, 32 do not respond to it at all: the underlying component does send the signal, but those callers never listen for it. Which dialogs respond is not predictable from looking at them, which is worse than a consistent absence would be. Fix identified: the shared dialog component will close on Escape by default, rather than each caller having to ask for it. Update, 5 August 2026: fixed in v2.5.489, with one honest difference from the note above: each dialog closes through the same path its own Cancel control uses — wired at every dialog rather than imposed blindly by the component — which preserves each dialog's in-flight guards, so a dialog whose Cancel is disabled mid-operation does not dismiss by Escape either. By fix time the unpredictable set had grown to 37 of 60 dialog instances; all are wired now, and the keyboard-shortcuts sheet documents the behaviour. One deliberate exception: the one-time secret-key reveal dialog does not close on Escape or an outside click, because its contents are shown exactly once and an accidental keypress would destroy them permanently. We would rather disclose that exception than let consistency destroy someone's key. Pending re-assessment.
6. Ten progress dialogs hold keyboard focus until the operation finishes. This is the one we would most want you to know about, so it is stated precisely. When a dialog is open, Atlas correctly keeps Tab inside it — that is the normal, intended behaviour for a dialog. But nine export dialogs and one account-update dialog contain nothing you can focus, have no dismiss button, and are among the dialogs Escape does not close. While one is open, a keyboard user has no way out of it. What limits this: they are progress dialogs, and they close themselves when the operation behind them finishes — including when it fails, which we checked specifically, because it is the difference between an inconvenience and being stuck. When one closes, keyboard focus returns to the control you opened it from. So the confinement lasts as long as an export takes, not indefinitely. It would become indefinite only if the underlying request never completed at all. Fix identified, and it is one change to the shared dialog component. Update, 5 August 2026: fixed in v2.5.489 — all ten now dismiss on Escape or a completed click outside. Dismissing hides the progress veil only: the export or update keeps running, the controls that started it stay disabled until it truly finishes, its completion message announces (see the status-messages update above), and normal completion still returns focus to the control you started from. The confinement this entry measured in export-lengths is now measured in the time it takes to press Escape. Pending re-assessment.
7. Sessions expire without warning. When a session times out there is no advance notice, no way to extend it, and no return to the page you were on after signing back in. Anyone who needs more time to complete a task is affected, and unsaved work can be lost. Update, 1 August 2026: partially fixed in v2.5.406. A countdown notice now appears two minutes before expiry — five minutes if you have unsaved form work — with a live count, turning urgent and non-dismissible in the final minute (announced assertively to assistive technology at that point, politely before it). When the clock reaches zero, Atlas takes you to sign-in itself and brings you back to the page you were on afterwards, on every expiry path. What remains: there is no one-click extension — the notice's action is an honest "Sign in again" — pending a session-refresh endpoint from the backend team.
8. Several destructive actions have no confirmation step. We searched the whole application for delete-style actions that act on saved data. Of the nine we found, seven take effect immediately on activation with no confirmation and no undo: removing an allowed carrier IP address, deleting a blocked number, deleting a toll-free registration, deleting a notification, deactivating an account, and removing the two kinds of verified-caller registration. An earlier draft of this statement said the opposite — that destructive actions in Atlas are generally confirmed and one was not. That was a generalisation from a single page, and it was wrong in the direction that flattered us, which is the direction that matters. The search that produced the real figure only finds actions wired directly to a button; there may be others reached by other means. Seven is a floor, not a total.
9. Automatically updating panels cannot be paused. Seven areas of Atlas refresh themselves on a timer, and there is no control to pause, stop, or hide the updating. If you need longer to read or work through a panel, it may change under you. The brief on-screen confirmation messages are on the same footing: they dismiss themselves after three seconds, or five for errors, with no way to hold one open long enough to read it. Moving content is a separate matter and is handled: Atlas has decorative animations, but every one of them stops when you set a reduced-motion preference — in your operating system, or in Atlas's own accessibility menu, which offers motion as a setting. We verified that by rendering the application with the preference on and checking that nothing was still animating. It is the data refreshes, not the animation, that you cannot control.

If you use speech input

1. Single-key shortcuts cannot be turned off. Atlas provides single-character keyboard shortcuts that cannot currently be disabled or remapped. Speech-input users, and users who experience unintended keypresses, may trigger them accidentally. The shortcuts are suppressed while you are typing in a text field, which limits but does not eliminate the problem. Update, 1 August 2026: fixed in v2.5.407. The Accessibility panel in the session menu gains a "Single-Key Shortcuts" preference; off disables every single-character shortcut in the product, while the Ctrl/⌘K chord keeps quick find reachable regardless, so turning the preference off costs no capability. The preference persists like the panel's other settings and participates in the tychron.com → portal preference handoff. The keyboard shortcut sheet also gained a visible "Keyboard Shortcuts" entry in the session menu — which keeps working precisely when single-key shortcuts are off and "?" cannot open it — and the sheet states, when the preference is off, that the keys it documents are disabled and where to turn them back on. Remapping is not offered, which the criterion does not require when a turn-off exists. Pending re-assessment.
2. Two controls cannot be activated by speaking their visible label. Speech input works by matching what you say against a control's programmatic name. On two controls, both in the cart screens, those two differ, so saying what is printed on the button does not activate it. An earlier draft said five. Three of those turned out on inspection to be correctly named; the count is corrected downward.

If you fill in forms

1. Some fields are labelled only by the grey text inside them. Placeholder text stands in for a label on the address-list field, the billing-report date range, and the feature-configuration form. That text disappears the moment you start typing, so if you look away mid-form there is nothing left on screen telling you what the field was for, and some screen readers do not announce it in the first place. An earlier draft put this at 41 fields. That number came from a pattern search that counted placeholders on fields which also have a proper label, which are not a problem. Only the three named above were confirmed by inspection, and we would rather publish three we have checked than 41 we have not.
2. Required fields are marked with an asterisk that is never explained. 46 fields carry a bare asterisk to mean "required". No legend anywhere in Atlas says what the asterisk means. Readers who know the convention are fine; readers who do not, and screen reader users who hear the character read out as "star", are not told.
3. When the server rejects something, you are told what is wrong but not how to fix it. Atlas's own client-side checks come from the browser, which does suggest corrections — typing an address with no "@" produces a real hint. But most errors in Atlas come back from our servers, and those messages state the problem without suggesting a remedy. The browser's hints are also transient: they vanish on the next keystroke, and are inconsistently passed to assistive technology.

If you rely on autofill to reduce typing

1. Browser autofill does not work outside sign-in. Atlas identifies the purpose of its authentication fields, so password managers and autofill work on the sign-in and password screens. It does not identify the purpose of fields elsewhere — name, email address, telephone number, postal code and the rest — so on profile, address, and contact forms your browser cannot fill them in for you. Password managers work throughout the authentication flow, and no field in Atlas blocks pasting — we checked every paste handler in the application rather than assuming. One behaves unusually without blocking anything: pasting a list of phone numbers into the search box converts them into a search filter instead of leaving them as text. Update, 1 August 2026: retained deliberately. Atlas is a wholesale operator portal: the people typing into its profile, address and contact forms are overwhelmingly entering their customers' details, not their own. Browser autofill matches fields against the operator's own stored identity, so honouring it on those forms would insert the operator's name, address and phone number into third-party records — an error generator dressed as an accommodation. Sign-in and password flows keep full autofill and password-manager support, and no field anywhere blocks pasting. We will revisit if Atlas ever grows a first-party self-service surface where the person at the keyboard is entering their own details.

If you have low vision, or change how text is displayed

1. Form field borders are below the required contrast in both themes. The outline of an input field measures 1.54:1 against its background in the light theme and 1.96:1 in the dark theme, against a requirement of 3:1. Fields are therefore hard to locate in either theme. We previously drafted this statement saying the dark theme was a workaround. It is not, and we have removed that advice rather than send anyone into the same problem by a different route.
2. Five text colours are below the required contrast in the light theme. They are the text on danger buttons (2.52:1), the sign-in form's overline label (2.68:1), placeholder text (3.33:1 and 3.46:1 in its two settings), and negative-value text (3.73:1), against a requirement of 4.5:1. The currently selected item in the sidebar also falls short on most pages. The dark theme's text colours do meet the requirement — every one of its colour values was computed against the surface it actually appears on — but see the entry above: its form field borders do not, so it is not a general workaround.
3. The icon in banner messages is below the contrast required of a meaningful graphic. Banners carry a coloured icon that indicates what kind of message it is. In the light theme that icon measures 2.15:1 and 2.20:1 against the two ends of the banner's background gradient, where 3:1 is required. In the dark theme it is comfortably above the requirement. An earlier draft listed this among the text colours, judged against the 4.5:1 text threshold. It is not text, the threshold that applies to it is 3:1, and both of the figures we had recorded were wrong. Corrected here rather than quietly dropped.
4. The high-contrast mode's own focus outline is under-contrast. Atlas offers a high-contrast display mode. The outline it uses to show keyboard focus measures 2.72:1, so it does not itself meet the contrast requirement — the accommodation has the same defect it is meant to address. Fix identified, and treated as the most urgent of the contrast corrections. Update, 3 August 2026: fixed in v2.5.469 — the high-contrast focus outline is now a separate token per scheme. On the mode's light surface it uses a darker blue measuring 6.2:1; the dark surface keeps its existing blue at 6.8:1. Both clear the 3:1 requirement with margin. (A single mid-tone colour cannot clear 3:1 against both a near-white and a near-black surface at once, which is why the original shared value failed on the light side.) Figures are computed from the shipped token values against the surfaces the outline actually sits on. Pending re-assessment.
5. Atlas overrides your browser's font-size setting. The base text size is fixed at 14 pixels on desktop, rather than following the default size you have configured in your browser. Browser zoom is unaffected and works correctly, which is the more commonly used mechanism of the two: on the six customer-portal pages we tested at 200% zoom, in both the standard and high-contrast display modes, no content was lost and nothing scrolled sideways. We did not test the administrative portal at 200% zoom, so we are not claiming it. Zoom compensates for this limitation; a font-size preference does not.
6. Some content does not adapt to increased text spacing. If you override line height and letter spacing through browser settings or an extension, a small amount of text in the request catalogue is clipped, and one panel on the home dashboard overflows horizontally in high-contrast mode.
7. Links inside table cells are distinguished only by colour. In data tables, a cell containing a link is not underlined and is set apart from ordinary cell text by colour alone — and by a colour pairing that is itself low-contrast.

If you use a pointer, touch, or a switch device

1. Dialogs dismiss on press rather than on release. Clicking the shaded area outside a dialog closes it the moment the button goes down. If you press there by mistake, you cannot cancel by dragging away before releasing, which is the standard way to abort an accidental press. Update, 5 August 2026: fixed in v2.5.489 — dismissal now arms on press and fires on release, both on the shaded area, so dragging away before releasing cancels an accidental press; a text-selection drag that starts inside the dialog and ends outside no longer closes it either. Pending re-assessment.
2. One help dialog's dismiss button can scroll out of reach. In the help dialog's expanded state on a small screen, the dismiss button can scroll off the bottom and become unreachable by pointer. Workaround: collapse the expanded sample and the button returns, or reach the dismiss button with the Tab key, which still finds it. An earlier draft of this statement offered the Escape key as the workaround here. That was wrong — this is one of the dialogs Escape does not close — and it is corrected rather than removed, because it was the worst kind of error a statement like this can make: false advice given to the person least able to work around it. Update, 5 August 2026: as of v2.5.489 the Escape key does close this dialog — the advice that was corrected as false above has become true, and we note the reversal explicitly rather than silently. The dismiss button scrolling out of pointer reach is still a defect.
3. Some touch targets are small. Across the pages we measured, 44 controls are smaller than the 24-by-24-pixel minimum the standard names; the smallest is a link measuring about 15 by 15 pixels. Every one of them is nonetheless spaced far enough from its neighbours to satisfy the exception the criterion allows for exactly this case, so the requirement is met on the pages we measured — but small targets are harder to hit whether or not an exception applies, and we would rather say so than rest on the exception. One component our source review flagged as a likely genuine failure needs saved filters to exist before it appears, and no saved filters existed in our test data. It is untested rather than passing, and the criterion is recorded as only partially met because of it.

What works well

Stated because an honest statement reports both directions, and because these are the things worth relying on. Where a claim rests on the pages we rendered rather than on the whole application, it says so.

• Every page we tested reflows to a 320-pixel-wide window with no horizontal scrolling and no loss of content. Measured, not estimated: zero pixels of horizontal overflow on all fifteen. At 200% zoom the same result holds on the six customer-portal pages we tested at that setting.
• The dark theme's text colours meet the contrast requirement. We say this on the strength of a separate extraction of all 196 of the dark theme's design tokens — 140 of them colours — composited over the surfaces they actually sit on, not on the automated scanner, which returned no dark-theme failures but also returned 755 dark-theme results it could not decide. Its form-field borders and focus ring do not meet the requirement — see the limitations above.
• Every page has a "skip to main content" link, and every page has a browser tab title. Both are set application-wide — the skip link in all three page layouts, the titles by a single router rule covering all 401 routes — so this covers every page, not only the fifteen we rendered. The titles are specific and descriptive everywhere except the home page of each portal, which is titled simply "Atlas".
• Password managers work throughout sign-in, and no field in Atlas blocks pasting.
• Navigation is consistent, and there are two independent ways to find a page: the sidebar and the Quick Find search. The sidebar is rendered from a single component used in a single place, so its order cannot vary between the routes that have it.
• Dialogs move keyboard focus into themselves when they open and return it to the control you opened them from when they close. The mobile navigation drawer correctly removes its contents from the keyboard order while it is closed. Where dialogs fall short is Escape and the ten progress dialogs described above.
• Reading order matches visual order. We compared the two directly on six pages, including the one whose layout uses the CSS mechanism most capable of causing a divergence, and found none.
• Nothing in Atlas flashes, auto-plays audio, or requires a dragging motion, a multi-finger gesture, or device movement to operate. Where dragging is offered — reordering the home dashboard — there are Move up and Move down buttons that do the same job. They are, however, hard to discover: the panel's instructions do not mention them, and the drag handle beside them is hidden from screen readers. The alternative exists and works; finding it takes more than it should.
• Atlas does not ask you to re-enter information you have already given it within a process. We checked the multi-step forms specifically for this, including one where two steps ask similar-looking questions for genuinely different purposes.
• Signing in does not require you to solve a puzzle, transcribe a code from an image, or remember something unaided. Password managers work, and nothing blocks pasting.

Report a barrier

If you encounter a barrier in Atlas, we want to hear about it. Please tell us the page you were on, what you were trying to do, and the assistive technology, browser, and operating system you were using, if you know them. That detail lets us reproduce the problem rather than guess at it.

How we assessed Atlas

This statement is based on a self-evaluation carried out in several passes, each able to correct the one before it.

First, a full review of the application source against all 55 criteria, with every finding recorded against a specific file and line. Second, an automated scan using axe-core 4.12.1 driven by Playwright, covering fifteen routes across both portals, each tested at four combinations of viewport and theme: desktop light, desktop dark, a 390-pixel phone width, and a 320-pixel width, which is the width the reflow requirement actually names. Third, a set of purpose-built browser probes for the criteria that automated tools cannot decide. Those probes drove real keyboard traversal to test focus visibility, measured centre-to-centre distances between touch targets, applied the text-spacing overrides the standard specifies and looked for clipping, compared visual reading order against document order, rendered the application with a reduced-motion preference set and checked what was still moving, and submitted forms to observe real validation behaviour.

Colour contrast was computed rather than judged by eye. Design tokens were extracted from the running application, colour references resolved, semi-transparent values composited over the backgrounds they actually sit on, gradients evaluated at every stop with the worst stop taken, and contrast ratios calculated arithmetically. This was necessary because the automated scanner returned 2,503 contrast results it could not decide on its own, owing to the layered and semi-transparent surfaces Atlas uses — 755 of them in the dark theme alone. That last figure is why the dark theme got its own separate extraction: the scanner reporting no dark-theme failures meant only that it had not decided, and we had at one point written that up as a pass. It is a pass, but we did not know that until we computed it.

Limits of this assessment

Six limits should be stated plainly, because each of them qualifies something above.

Testing with screen reader software has not been performed. Not delayed or partially done — not done. We have not tested with JAWS, NVDA, or VoiceOver. Our testing reports what browsers expose to assistive technology, which is what those tools consume, but it is not a substitute for using them, and we do not claim otherwise.

We rendered fifteen pages of 401. Findings from source review cover the whole application; findings from browser testing cover the sample. Where a result above depends on the sample, we have said so.

We tested in Chromium only. Firefox and Safari were not exercised, and neither were their assistive-technology pairings. Behaviour may differ there.

The 200% zoom testing covered the customer portal only. Six of its pages, in both display modes. The administrative portal was not tested at that zoom level at all, so nothing above claims a zoom result for it.

Our test environment had very little form content in it. Across the fifteen rendered pages the automated scan encountered eight form controls in total, because the pages with substantial forms need data our test environment does not have and rendered as empty shells. Nearly all of the form-related findings above — labelling, required-field marking, error association — therefore rest on reading the source rather than on observing a form in a browser. We report them at full weight, because a control given no label can only fall back to a generic one, but the distinction is real and this is the largest single gap in our coverage.

Two findings rest on computed styles rather than on something we watched happen. The banner icon's contrast and the reduced-motion behaviour of the animation in banner messages were decided by resolving CSS and compositing colour values, because the banner did not appear on any page our tests could render. The arithmetic is sound and the cascade is unambiguous, but we did not see it.

Corrections we made to this assessment

Our internal findings were reviewed repeatedly before this statement was written, and every review found errors in the one before it. We are recording that here rather than quietly fixing it, because an assessment that hides its own corrections is not evidence of anything.

Some of the errors were findings that were not real. Two components the draft reported as defective already do the right thing — the dropdown and toggle components accept a caller-supplied label, and the container that displays status messages is permanently present in the page — so acting on the draft would have sent our engineers to change code that is already correct. A suspected keyboard trap in the help dialog and a suspected fault in the mobile navigation drawer both turned out on re-reading to be sound. A claim that two steps of one registration form asked the same questions twice was wrong: they ask similar-looking questions for different destinations, which a reader of the code could mistake for duplication and a person who knows the product could not.

Some were counts that did not survive checking. A table count was double what it should have been. A count of 41 unlabelled fields became three once each was inspected. A count of five controls whose spoken label does not match their visible one became two.

The corrections then had to be corrected. A second review found three errors that the first round of corrections had introduced, the most consequential being a passing verdict re-justified on the grounds that the Escape key closes our dialogs — it does not close most of them, and it does not close the one the claim was made about. A third found that our focus indicator's contrast had been measured on the wrong colour, and the true figure was worse. A fourth found the same class of error four more times, and it is worth naming the class, because it is the one to watch for in work like this: in every case a correctly measured number had been attached to the wrong thing. The right contrast ratio filed under the wrong criterion. The right count of animations described as no animation at all. A statement about grid layout that was true of three pages and false of the fourth — the fourth being the only one where it mattered.

The last round produced two corrections that changed what this statement says to you. Destructive actions: we had written that they are generally confirmed, with one exception. A search across the whole application found the ratio is the other way round — seven of nine are unconfirmed. And the ten progress dialogs: we had established that they hold keyboard focus, and then stopped one question short of asking whether a failed export releases you. It does. The difference between "ten dialogs can trap you permanently" and "ten dialogs hold you for the length of an export and then give your focus back" is the difference between a warning you can act on and one that would put you off the product for no reason, and we only have the second version because someone asked the next question.

A final round re-counted every figure in this document that comes from counting places in our own source code, and found three of them low. Our codebase writes the same component two different ways, and the searches behind those counts had only looked for one of the two spellings. There are 62 confirmation dialogs rather than 61, and 143 unlabelled toggles rather than 139, which moves the total number of unnamed controls from 327 to 331. Every number here that rests on counting components has now been re-derived by a method that reads both spellings. We are reporting a correction that made our own results slightly worse because a reader has no way to audit the difference, and a statement that only ever corrects itself in the flattering direction is not worth reading.

We are stating this at length for a reason. Round after round found errors the round before had introduced, which is the strongest evidence we can offer that a self-assessment is not a substitute for being told by the people affected. It is also why we would rather hear from you than be trusted.

Two pieces of advice in earlier drafts were wrong and have been corrected rather than deleted. The first told users who find the light theme hard to read to switch to the dark theme; form field borders fail the contrast requirement in both. The second offered the Escape key as the way out of a dialog whose dismiss button can scroll out of reach, and that dialog is specifically one Escape does not close. Both were bad advice given to the people least able to route around it, which is worse than saying nothing. A third has been added above rather than removed: the browser tab title is offered as a partial workaround for missing page headings, and we now say plainly that it does not work on the home page.

What happens next

Each issue above has an identified remedy. Eight changes account for the majority of the affected surfaces, and they are sequenced first: making status messages announce, restoring page headings, adding column associations to data tables, naming dialogs, labelling the dropdowns and toggles, connecting error messages to their fields, making dialogs close on Escape, and giving the progress dialogs a keyboard way out. Four of the eight are single changes to shared components, which is why they reach so far — the first alone makes 586 existing messages audible by adding two attributes to one element, and the Escape and progress-dialog fixes are both single changes to the same shared dialog component, reaching every dialog in the product. Labelling individual controls is the one large job, because it has to be done at each of the 331 places a control is used. Update, 5 August 2026: six of the eight have shipped — status messages announce and data tables associate (v2.5.488), page headings are restored on the home pages with the custom shells still to do (v2.5.488), and dialogs are named, close on Escape, and give the progress dialogs their way out (v2.5.489). Of the eight, labelling the 331 controls and connecting error messages to their fields remain. Further update, later the same day: a seventh has shipped — error messages are now linked to their fields (v2.5.491). Of the eight, labelling the 331 controls remains.

The contrast corrections are a bounded set of colour values, with the high-contrast mode's own focus outline treated as the most urgent, since an accommodation that fails is worse than none.

We also maintain a set of accessibility linting rules that has never actually run in our build pipeline: it exists as a command, and our verification pipeline does not call it. Its file coverage is also partial — four directories of components and shared views, which leaves most of both portals' page-level code unchecked. Wiring it in and widening it turns a class of these defects from something an audit finds into something a build refuses.

We will review and update this statement as remediation progresses, and re-assess in full at least annually. We have not set dated commitments against individual items here, because a date we miss is worse than no date; progress will be reflected in this statement as it lands.

Appendix: full criterion results

The complete assessment, for readers who need the detail. Levels are as defined by WCAG 2.2.

A rule about this table, made explicit on 5 August 2026 after two renderings of it were caught diverging: every result below is a measurement from the v2.5.345 assessment, and rows move only when a full re-assessment produces new measurements. Shipped fixes — however complete — are recorded in the dated update notes above, never as edits to these rows. Two rows (2.1.4 and 2.2.1) briefly carried updated results following the 1 August update; they have been returned to their assessed values under this rule, with the fix history noted beside them. This keeps the summary counts at the top of this statement and this table derived from the same measurement, and keeps "assessed at v2.5.345" literally true of every row.