What we have built for, what we have tested, and where the gaps are
A statement worth reading says both halves. This one names what the software does today, says plainly that no independent audit has been carried out, and lists the places we already know fall short.
Six things the software does today
Each of these is in the markup rather than in a plan, and each is held in place by a test that fails when it is removed.
Menus, drawers, grids that scroll sideways and the preview panes in the console all take focus in a sensible order, and a scrollable region that a mouse can reach can be reached by a tab key too.
Each navigation region carries its own label rather than sharing one, so a screen reader's landmark list says "Product" and "Company" instead of offering "navigation" four times.
One heading at the top of a page and the rest beneath it. The console's previews draw the same components the public pages do, a level down, so a preview never introduces a second top.
Every image is stored with its width and height, so a page settles before you start reading rather than shoving the paragraph down when a file arrives.
The type scale is relative, so a reader who sets a larger default gets a larger site rather than a scrollbar.
Every layout is written to the viewport the browser actually gives it, including the one an address bar is covering, so a button at the bottom of a screen stays reachable.
Four gaps we know about
Naming a gap is the part of a statement that is worth something. Each of these is open work rather than a decision.
The software has been built against WCAG 2.2 AA and has not been tested against it by anybody outside the team. Until it has, this page claims practices rather than conformance.
A four-column comparison scrolls sideways on a phone. It is reachable by keyboard and announced as a scrollable region, and sideways scrolling is still the worst way to read a table.
The palette was chosen against the ratios and is verified by a person rather than by a build step. A tenant that uploads a logo gets a palette derived from it, which is the case most likely to fall below.
VoiceOver on macOS and iOS. NVDA and TalkBack have had far less, and the gap between "marked up correctly" and "pleasant to listen to" is only found by listening.
A barrier reported to us is added to this list, whether or not it is fixed the same week.
Report a barrier, and hear back
A barrier that stops you finishing a task is a fault of the same kind as a wrong total. It is handled the same way.
- Say what you were doing
The screen, the task and the assistive technology — "the invoice list, with VoiceOver on iPhone" is enough to reproduce most of what gets reported.
- Send it to support
The support address on the contact page reaches the same queue a billing question does, and an accessibility report is raised at the same priority as a fault.
- Hear back within one working day
An acknowledgement that names what we understood, so a misread report is corrected before anybody spends a week on the wrong thing.
- See it on this page
Anything confirmed joins the list above with its date, whether it is fixed that week or that quarter.
Judge the software on your own screen
Forty minutes on your own figures, with whatever you normally use to read a screen. If something gets in the way, that is the most useful thing to come out of the call.