Accessibility of this service
We sell accessibility work to government, so our own interface is fair game. This is what we target, how we check it, and what we currently know is not right.
Last reviewed September 2026.
What we target
WCAG 2.1 Level AA for the GovAccess web application and for the documents it produces. That is the standard the Department of Justice’s Title II rule adopts for state and local government websites, and holding ourselves to a lower one than we measure our customers against would be indefensible.
This is a statement of what we aim at and how we check, not a claim that we conform. We do not tell customers that an automated result proves conformance, and the same restraint applies to us.
How we check
Two ways, and neither is sufficient on its own:
- Automated. We run the same accessibility engine we run against customers’ websites against our own screens, at both a narrow and a wide viewport, and we check that content still reflows without a horizontal scrollbar. The screens covered include the public pages — the home page, how it works, pricing, sign-in and these policy pages — and the product screens behind sign-in.
- By hand. Keyboard-only operation, focus visibility, heading structure and table semantics are decided when a screen is built rather than tested afterwards. We use semantic HTML and reach for ARIA only where it is needed.
Automated testing finds a minority of real barriers. We say that to customers on every report and it is equally true here.
What we know falls short today
Listing these is the point of the page. A statement with no known issues on it is one nobody has looked at.
- The focus indicator on two calls to action on the “how it works” page does not meet the 3:1 contrast that WCAG 2.1 AA requires of a non-text indicator.
- After a scan is started from the home page, keyboard focus is not moved to the panel that replaces the form, and the change is not announced. A keyboard or screen reader user has to find the new content themselves.
- Progress on a running scan updates a polite live region every few seconds for the whole run, with no way to turn it off. On a long scan that is a lot of announcement.
- Pagination controls that are marked unavailable remain reachable by keyboard, and their contrast in that state is below 3:1.
Each of these is recorded and none of them is waiting on a decision. If one of them is blocking you, tell us and we will treat it as a defect rather than a backlog item.
The documents this product creates
A converted document is a new HTML document derived from a PDF. Every one carries a list of what a person still has to check, and that list is never empty — it says what was recovered, what a model wrote, and what could not be verified. We never state that a converted document meets a standard.
Where a PDF allows it, we write a structure tree into the copy — and we say what that was checked for and what it was not. It is checked for whether it reads down the page, which is the one thing no PDF validator can see; nothing checks whether each element carries the right type, and no automated check can. A scan with no text, an XFA form, a signed document and a protected one are each left alone, and the report says which. Adding a text layer to a scan, giving a form’s fields the names assistive technology announces, and setting a title and a language are real repairs too; none of them is tagging, and nothing here is worded as though they were.
Telling us about a barrier
If any part of this service is not usable for you, we want to hear about it — including if you are evaluating us and have not bought anything. Write to support@missionlayersystems.com.
Tell us the page, what you were trying to do, and what you use to browse if you are willing to. We will reply within one business day and we will tell you plainly if something is going to take a while.