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

Latest update

7 September 2026, covering Atlas v3.0.174 to v3.0.182. Atlas moved to its 3.0 line after the August updates; the version assessed is unchanged.

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. Update, 5 September 2026: the shared-component fix shipped in v3.0.163 — shared switches and dropdowns now take their accessible name from the actual visible field label. The portal team reproduced the defect first, on the account access form, where twenty different switches all announced as "Toggle setting". The connection follows label changes, covers older callers that omitted an input id, and works for controls that appear after loading; grouped campaign flags, standalone channel and authorization switches, and selectors inside tables get their own names rather than the group heading, and form submission names are no longer used as dropdown labels. Regression coverage mounts the real account access form and checks all twenty names, state changes and disabled controls. This addresses the shared naming defect; it does not claim every control on every route has been re-assessed, and the 331 above stays as the historical count. Verified in markup and browser exposure, not yet by listening. Pending re-assessment. Update, 6 September 2026: the controls that do not use the shared switch or dropdown follow — email-list fields (v3.0.167); feature-setting thresholds, repeated override controls, and shared number and date inputs (v3.0.168); decimal and secret fields, the raw-data view toggle, and the individual controls in design examples (v3.0.172) — each now named from its visible label. Other custom control types remain in the register. Pending re-assessment. Update, 7 September 2026: more control types now expose their name or state, across v3.0.174 to v3.0.182 — tab disclosures and billing categories say whether they are expanded, role presets and selected saved-search presets expose their selection, the customer Orders All/Mine scope exposes which is selected, request checkboxes carry record-specific names, shared Edit actions use one named Edit icon, Account menu items expose their role and the phone opener its open state, and the campaign JSON disclosure exposes its expanded state. Verified in markup and browser exposure, not by listening. Pending re-assessment.
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. Update, 7 September 2026: extended to server-side guidance on the reviewed Profile form in v3.0.180 — the server's field guidance is associated with its input, and saving keeps a meaningful focus destination. One reviewed flow, not a survey of server errors. 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. Update, 5 August 2026, evening — found by listening: the first structured VoiceOver pass found that a named dialog was still not being read on entry. Focus went to the first button, which announced only itself, and the body copy had no description role, so a confirmation dialog opened as "Close, button" and nothing else; the title wiring above was present and correct, and muted anyway. Fixed the same day in v2.5.498 — focus now lands on the dialog itself, named by its visible title before focus moves; dialogs whose body is prose mark that prose as their description, and it is read on entry with the title; confirmation dialogs are alert dialogs, whose contract is exactly "read the title and the description before the user acts", and no longer open with a button pre-focused, so a reflexive Enter activates nothing. Dialogs that are forms or tools — imports, pickers, editors — keep title-only announcement deliberately. Measured in the built application; awaiting the listener's confirmation.
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.
9. Ordinary text was announced as "clickable". Found by screen-reader listening on 5 August 2026; not in the original assessment, which could not see it — markup review cannot see event listeners. Lines of non-interactive text — a credit-limit figure was the example — carried a trailing "clickable" in VoiceOver, because the application listened for mouse events on the whole document, and Safari reports that honestly: if the document responds to clicks, everything in it is clickable as far as assistive technology can tell. When everything claims to be clickable, the controls that really are lose their signal. Fixed in v2.5.499: the whole-page listeners moved from the document to the window, where they receive the same events at the same moment but are not part of the page assistive technology describes. The behaviours they power — the unsaved-changes warning, menu and column-picker dismissal on outside clicks — pass the full journey suite unchanged. Awaiting the listener's confirmation.
10. Dashboard statistics read as fragments rather than facts. Found by a recorded VoiceOver walk on 5 August 2026; not in the original assessment. The home page's balance card took ten cursor stops to convey five facts — a label, then a number, then the next label — leaving the listener to hold each label in mind and hope the next number belonged to it, with adjacent stops bleeding together. Fixed in v2.5.500, then found regressed the same day: each statistic tile now exposes one combined line — "Available credit: $563.80" — with the visual tile unchanged, and the credit-usage bar is a real meter announcing its percentage; covered are the balance and activity cards on both portals, the account pages that reuse them, the order workspace counters and the conversation summary pills. But the listener's second walk, on his Safari/VoiceOver build — which reads text marked hidden from assistive technology — heard each fact once by design and twice more by platform behaviour, with the highlight landing in the wrong place. Our verification had measured the markup in a different browser engine and could not see this; it is the cross-browser screen-reader blind spot the limits section names, live. Still open: v2.5.501 ships a comparison exhibit of four candidate renderings for the listener to walk once, and the pattern his screen reader reads exactly once will roll out to every tile site. We would rather resolve this by ear than by a third guess. The charts on the home cards and the analytics page now announce as one named image each; a spoken alternative for the data they draw remains open, and is recorded for the re-assessment — naming a chart is not conveying it.

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. Update, 6 September 2026: addressed in v3.0.168 — shared table scroll regions can now be reached by keyboard even when their overflow is too small to display a slider, and the portal team reports calendar day selection and request-link navigation checked from the keyboard. Scoped work with component and browser regressions, not a re-assessment of the item. Pending re-assessment. Update, 7 September 2026: on touch devices and in narrow spaces the date picker is now the browser or device's native one, whose keyboard behaviour belongs to the browser; wider desktop layouts keep the calendar grid, and switching between date and time preserves focus (v3.0.174). Several menus gained full keyboard operation: the Columns picker takes focus when opened, closes on Escape with return to its opener and closes when navigation leaves it (v3.0.176); the Account menu supports arrow keys, Home/End, Enter/Space, Escape with return and Tab exit (v3.0.179); the Attention section picker supports keyboard reordering and exit, and the terms dialogs, runtime-error recovery, installation guidance and design-example dropdown follow the same entry-and-return behaviour (v3.0.180); an upload can be removed by keyboard with focus returned, the campaign JSON disclosure responds to Space, and long notification messages scroll by keyboard (v3.0.182). Sampled flows in both portals, not a re-assessment of the item. Pending re-assessment.
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. Update, 6 September 2026: partially addressed in v3.0.168 — inside shared dialogs and their nested body scrollers, a focused control is now revealed above the sticky action bar, using the bar's current dimensions. Other nested scrolling regions remain as described. Pending re-assessment. Update, 7 September 2026: three more cases — the layout-customisation panel now accounts for the footer and mobile navigation so its Done button stays reachable (v3.0.175); where the reviewed validation flow returns focus to a field covered by a floating error message, the page reveals the field without dismissing the message or moving focus (v3.0.179); and a notification leaves room for a focused form field above the bottom navigation (v3.0.182). Other nested scrolling regions remain as described. Pending re-assessment.
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. Correction, 5 August 2026, evening: "all are wired now" was true of every dialog built on the shared component and untrue of the one that is not. The home page's Customize Layout panel — a dialog by role and name — predates the component-level fix, was never in its sweep, and did not respond to Escape or any key at all; a listener found it on a recorded walk, unable to leave it without a mouse. Fixed in v2.5.501: opening it moves focus to the named panel, Escape closes it from anywhere in the widget, and closing returns focus to the button that opened it. The sweep's coverage was the component's dialogs, not "all dialogs", and we are correcting the claim rather than narrowing it after the fact. Update, 6 September 2026: a date picker opened inside another dialog now gets its own keyboard handling, and Escape returns focus to the date field without closing the parent; dialog keyboard navigation skips collapsed and inactive content (v3.0.168).
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. Update, 5 August 2026, evening: fixed in v2.5.493, and both of this entry's self-corrections proved out. Five of the seven now open the shared confirmation dialog before acting, each naming exactly what is about to happen: removing an allowed carrier IP, deleting a blocked number, deleting a toll-free registration, deleting a notification, and deactivating an account. The two verified-caller registrations were not wired: they are the Google Verified SMS and Verified Calls registrations, both discontinued by Google; the pages are no longer used and are queued for removal, and we would rather say so than count a confirmation on a dead page. The census this entry predicted found two more instant deletes of saved records — removing a voice-routing destination and removing a text-to-speech message, on both portals — and they confirm as of the same release. Removing a row that has never been saved still acts directly, because there is nothing to lose, and deleting an abandoned payment attempt is recorded as a near-miss rather than wired. Since v2.5.489 the confirmation dialog announces its title, closes on Escape and cancels on drag-away, so the new confirmations arrive with the full dialog behaviour. Pending re-assessment.
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. Update, 7 September 2026: the draft-name action and the CSV upload now include their visible wording in their accessible names (v3.0.174). Whether either is one of the two cart controls counted here has not been checked, and the portal team lists speech-input testing as still open. Pending re-assessment.

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. Update, 6 September 2026: the address-list field now keeps a visible label above each address, with each field and its add/remove actions carrying the list's purpose, labels that stay once an address is entered, and validation errors attached to the affected address (v3.0.167); the feature-configuration form's thresholds and repeated override controls have contextual names (v3.0.168); and the customer billing month selector — the billing-report date control named here — was found on inspection to already carry a persistent label. Pending re-assessment.
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. Update, 6 September 2026: partially fixed in v3.0.168 — required fields in the shared request forms now say "(required)" beside the label, and conditional guidance follows the selected company type without discarding what has already been entered. Fields outside the shared request forms keep the bare asterisk for now. Pending re-assessment. Update, 7 September 2026: the saved-search name field now carries a persistent label with explicit required guidance (v3.0.177). Pending re-assessment.
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. Update, 7 September 2026: two bounded improvements to error recovery, neither a change to server messages: when a saved search cannot be written to browser storage, the draft or existing preset stays in place with an error and a retry path (v3.0.177), and values already entered in a form remain available when a validation message is dismissed (v3.0.182). The reviewed Profile form now also associates the server's field guidance with its input (v3.0.180). Server errors elsewhere still state the problem without a remedy. Pending re-assessment.

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. Update, 5 August 2026, evening: fixed in v2.5.492 — the border token was re-derived per theme and now measures at least 3.5:1 in the light theme and 3.7:1 in the dark, at every stop of the field background gradient, in the same hue families. Figures computed against the composited surface with the assessment's own arithmetic, first calibrated by reproducing this statement's published values to the digit, and reviewed on the live portal in both themes. Pending re-assessment.
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. Update, 5 August 2026, evening: fixed in v2.5.492 — danger buttons keep their near-white text over a deeper red (5.0:1 at the worst stop, 4.75:1 on hover, which the original values also failed); the sign-in overline is a deeper amber at 4.9:1; placeholders measure 4.8:1 and 5.2:1 in their two settings; negative values 4.9:1; and the selected sidebar item gets a dedicated per-theme token at 4.76:1 light and 5.6:1 dark, replacing a raw palette colour that measured 1.79:1 — further off than anything else in the set. Pending re-assessment.
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. Update, 5 August 2026, evening: fixed in v2.5.492 — the icon's backing deepened, and the glyph now measures 4.06:1 and 4.10:1 against both ends of the gradient. The dark theme was already passing and is untouched. Pending re-assessment.
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. Update, 7 September 2026: the September work was checked with root text enlarged to 200% on both portals at phone and tablet widths, and the wrapping and stacking corrections across v3.0.174 to v3.0.182 come from those checks. Root text enlargement is not browser zoom, so the untested administrative-portal zoom result stands, and the base-size lock this entry describes is unchanged. Pending re-assessment.
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. Update, 5 August 2026, evening: an underline fix is drafted and awaiting its own visual review; it has not shipped, and this item stays open.

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. Update, 6 September 2026: the permissions Help dialog was rechecked with its example expanded (v3.0.172): its sticky footer keeps the Dismiss button visible and clickable on phone and tablet layouts, including with text enlarged to 200%, and closing returns focus to the opener. The portal team reports this as confirming the current behaviour and adding regression protection for the defect disclosed here. Pending re-assessment. Update, 7 September 2026: a related regression, disclosed rather than folded in: the responsive-layout change in v3.0.178 let a detail-page confirmation sit behind the mobile navigation. v3.0.179 corrects it — shared dialogs now render above page containers, long confirmation text wraps with its action buttons aligned, and dialog buttons keep their larger touch areas independently of the form that opened them. Pending re-assessment.
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. Update, 6 September 2026: the SMS and MMS studios now preserve the portal's 44-pixel touch-target floor for their controls and shared navigation on touch devices, with compact tablet fields keeping at least 16-pixel text (v3.0.167), and the specialised-field actions changed in v3.0.172 retain a 44-pixel target including in compact spacing. Remaining touch-target issues elsewhere stay open. Pending re-assessment. Update, 7 September 2026: the largest batch of touch-target work so far, v3.0.174 to v3.0.182, summarised in the 7 September note above: the 44-pixel floor now reaches calendar, tab, role, billing and request-wizard controls, the home pages' controls and shortcuts, the shared list-page toolbar and paging, record links in Orders, billing reports and Requests, the Account menu, the Attention page, Settings and Profile, and the 10DLC studio — on touch devices only, with desktop layouts deliberately kept compact. The saved-filter component this entry could not test was exercised with populated saved searches in v3.0.177's checks; the portal team says that does not replace the historical target census. Remaining small table links and other touch-target observations stay in its backlog, and no whole-portal target claim is made. Pending re-assessment.

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. Update, 5 August 2026, evening: the handle's glyph — a braille pattern character that screen readers announced as "dots one two three four five six" — is now drawn as shapes rather than typed as text (v2.5.501), and the customizer panel itself now follows the dialog keyboard contract; see the Escape entry above.
• 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. Update, 5 August 2026, evening: this began to change on 5 August — a structured VoiceOver pass against the current build, including two recorded walks of the customer home page, produced the four findings recorded in the screen-reader section above, each fixed the same day and one found regressed under the listener's own Safari/VoiceOver build. It is a start, not a re-assessment: one screen reader, one listener, a handful of pages, and NVDA and JAWS still untested. The September updates claim no new listening results. The re-assessment now under way treats assistive-technology listening as a required pass, not an afterthought.

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. Update, 5 August 2026, evening: it does. The statistics-tile fix verified in one engine reads worse under Safari with VoiceOver, which is this limit made concrete; see the screen-reader section.

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. Update, 7 September 2026: the September implementation checks enlarged root text to 200% on both portals; that is not browser zoom, and this limit stands until a re-assessment zooms the administrative portal.

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.

Corrections since publication. The 5 August update said every dialog now closes on Escape. That was true of every dialog built on the shared component and untrue of the home page's layout customizer, which is not built on it — a listener found the difference, and it was fixed in v2.5.501. The same walk found that the statistics-tile fix (v2.5.500) reads worse, not better, under Safari with VoiceOver; it is recorded above as open rather than fixed. Both corrections are noted where the claims sit.

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. Update, 5 September 2026: the eighth has its shared-component fix (v3.0.163), with the control types that do not use the shared components following on 6 September — see the screen-reader section. All eight are now shipped in some form; none has been re-assessed.

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. Update, 5 August 2026, evening: the high-contrast outline shipped in v2.5.469 and the rest of the set as one token sweep in v2.5.492; the structural items — the font-size lock, text-spacing clipping and table-link underlines — remain, and are listed under low vision above.

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.