# Accessibility statement

> Otto's accessibility statement: we are working to WCAG 2.2 AA and do not claim to have reached it. The known gaps, each with the success criterion it implicates.

- Source: https://ottoforfirms.com/accessibility/
- Publisher: Otto — https://ottoforfirms.com
- Updated: 2026-09-01

Last updated 29 July 2026.

## The claim, plainly

We are working towards WCAG 2.2 Level AA. We have not reached it, and nothing in
this statement claims that we have.

Below is a list of what we know is wrong, what we have not looked at yet, and
what we have checked and found working. It is longer and less flattering than
most statements of this kind, and that is deliberate. A procurement or diligence
team can do something useful with an honest list — decide whether the gaps affect
their people, ask when they close, hold us to the answer. Nobody can do anything
useful with a claim of full conformance except find out later that it was wrong.

If something here is stopping you from getting what you came for, skip to
[Reaching us](#reaching-us). We will get you the information another way while
the defect is open.

## Two different sites, assessed separately

What we publish comes in two forms, and they fail in different ways, so they are
listed apart.

**The reference layer** — the statute-of-limitations tables and the other
research pages — is plain HTML. It needs no JavaScript, so it cannot break
because a script did.

**The product site and the application** are built as a single-page app that
draws itself in the browser. Almost every problem below is on this side.

## How we assessed it

By reading our own code and by testing what the live site actually sends back.

**No screen-reader pass has been run.** Nobody has sat down with NVDA or
VoiceOver and worked through these pages. That pass is scheduled, and when it
happens its findings will be added here rather than quietly fixed.

Our build does check a few things automatically on every release — that headings
run in order, that colour contrast in the design system clears its threshold,
that no accessibility overlay has been added. **Those checks passing is not
conformance and we will not present it as such.** Automated tooling catches
something like 30–40% of accessibility problems at best, and what it misses is
disproportionately what actually stops somebody: a button with no name, focus
that lands nowhere, a dialog a screen reader never enters. Treat the list below
as a floor rather than an inventory.

## What we know is wrong

Entries keep their number for as long as this document exists, including after
they are fixed — an entry that has been closed says so in its own heading and
describes what was measured. Nothing is quietly deleted, so a reader who was sent
this list once can check what happened to the item they cared about.

### On the reference pages

**1. The skip link: fixed, with one nuance named.** *WCAG 2.4.1 Bypass Blocks
(A), 2.4.7 Focus Visible (AA)*

Every page opens with a "Skip to content" link, positioned off-screen until it
receives focus. It used to be revealed by a small inline script — the only
executable JavaScript on the reference pages — and the content security policy we
serve refuses inline script, so the link took focus and stayed invisible. Your
first press of Tab went somewhere you could not see, and the bypass we offered
did nothing.

The reveal is now an ordinary stylesheet rule that applies when the link holds
focus, which that policy has always allowed, on both the reference pages and the
product site. What we checked, by
sending real Tab and Enter keypresses to a browser and reading which element
actually held focus after each one: the link is the first thing focus reaches, it
is on screen and not covered by anything at both 1440px and 390px wide, and
activating it moves focus into the page's main landmark, past the navigation.
Confirmed that way on 37 pages of the product site, on reference pages served
with the live security headers, and inside the signed-in application.

One nuance, because it is true and someone will hit it: on the reference pages
activating the link scrolls to the content and moves the point your next Tab
continues from, but it does not place focus on an element — that page's main
landmark is not itself focusable. Keyboard navigation carries on from the right
place; a screen reader's cursor does not follow the jump. On the product site
focus does move.

**2. Some small text does not have enough contrast.** *WCAG 1.4.3 Contrast
(Minimum) (AA)*

Our greys are black at a reduced opacity. Four of them are too light at the sizes
we use them, measured against the stylesheet we actually ship:

| Where | Size | Contrast | AA (needs 4.5:1) |
|---|---|---|---|
| Eyebrow labels and breadcrumbs | 11px | 3.35:1, and 3.10:1 inside a grey panel | fails |
| Table column headers | 11px | 3.35:1 | fails |
| The legal disclaimer at the foot of the page | 13px | 3.98:1 | fails |
| Footer links | 14px | 3.98:1 | fails |
| "In review" cells | 16px | 4.76:1 | passes |
| Table captions | 14px | 4.76:1 | passes |

None of this counts as large text, so the 4.5:1 threshold applies to all of it.
The disclaimer is the worst of the four, because it is the text most likely to
matter to somebody and the hardest to read. Darkening these four values fixes it
without changing how the pages look. **These four are still open.** All four come
from a small set of shared colour values rather than from scattered choices, so
closing them is one contained change — and it is first in the plan at the end of
this page.

The same criterion also failed, in far more places, on the product side — so
this entry covers both surfaces rather than pretending the problem is only here.

**The shared application kit is now fixed.** Its greys were measured in rendered
pixels on the two public pages that embed real application screens: micro-labels,
counts, sublabels, table headers and empty states were 2.33:1 on the app
background, 2.50:1 on a card and 2.57:1 in a table header, all at 9.75px. They
are now 7.0:1 or better. Four other values in the same pass: the inline "Confirm"
style action, 2.90:1 → 6.43:1; the red status pill on its own tinted ground,
4.36:1 → 5.87:1; the mail-source badge, whose glyph was additionally dimmed to
70% opacity, 3.37:1 → 4.92:1 with the dimming removed; the email and phone
sign-up placeholders and the message-rates disclosure, 4.45:1 → 5.14:1. Every
status pill now clears the threshold on its own tint — the lowest is 4.72:1.

**What remains on the product side is in the individual screens, not the kit.**
Counting runs of failing text on the two pages that embed the app, the same
measurement went from 224 to 174 and from 43 to 39. The rest are page-level
colours — a lighter grey used directly in a screen, a green metric, a page
breadcrumb, two ink opacities on the marketing pages — and they need the same
treatment one file at a time.

One honest note about tooling: our automated checker returns "incomplete" rather
than "fail" for most of this, because the application's background is a gradient
and the rule declines to judge text over one. Every ratio above was measured by
compositing the actual painted colours instead. It is the clearest example on
this page of why we do not present a clean automated run as conformance.

### On the product site and the application

**3. Buttons with an icon and no name — re-counted, and now none.** *WCAG 1.1.1
(A), 4.1.2 (A), 2.4.4 (A)*

An earlier version of this entry said "around nine controls" and admitted the
figure had never been re-counted control by control. It has been now, from the
browser's own accessibility tree rather than by reading the code: **463 controls
across nine public pages, none of them without a name.** The last ones were the
row-selection checkboxes in our shared table — 26 on a single page, each
announced as "checkbox" and nothing else — and the column they sit in, which had
no heading text at all. Both now say what they do.

Two limits on that count, because it is a measurement and not a guarantee. It
covers what those pages render when they load: a control that only exists once a
dialog, popover or menu is opened was not enumerated, though the shared shells
those are built from — the dialog close, the "search users" popover, the small
action menus — were each checked by hand. And it covers the public site; the
screens behind the login are only partly represented, by the two pages that embed
real application screens as product shots.

**4. Two switches do not say whether they are on or off — fixed.** *WCAG 4.1.2
Name, Role, Value (A)*

They were ordinary buttons with nothing marking them as switches and nothing
exposing their state; on and off were conveyed by colour and knob position alone.
There turned out to be nine of them, not two: seven on the public Knowledge page
that choose which sources an answer may draw on, one in account settings, and one
in the bank rules table. Each is now a switch that reports whether it is on, and
each says which thing it governs.

The seven public ones were verified by driving them rather than by reading the
markup: the state a screen reader would be given was read back before and after a
real click, and it changed. The two behind the login were confirmed in the code
against the same pattern. The same defect in a different shape — a choice conveyed only by which
segment is filled — was fixed at the same time on the segmented controls and the
filter pills, which now report which one is chosen.

**5. The panels that open over a page: now built as dialogs — fixed.** *WCAG
4.1.2 (A), 2.4.3 Focus Order (A)*

None of them announced itself as a dialog, none kept keyboard focus inside
itself, none stopped the page behind it scrolling, and none returned focus to the
button you opened it with. Opened by keyboard, your focus stayed in the page
underneath, and a screen reader read straight past the panel into the content it
was covering.

The demo panel this entry was named after is gone entirely, for a separate
reason: it was a scheduler offering dates that had already passed, and it told
you your demo was booked without sending anything. "Book a demo" now goes to the
contact form, which sends a real message. Two panels still open over a page — the
homepage's product tour and the Voice demo call — and both had exactly the defect
described above.

Both are now dialogs. They identify themselves as such, they take their name from
the heading you can already see in them, focus moves into the panel when it opens
and cannot Tab or Shift-Tab out of it, Escape closes them, the page behind stops
scrolling while they are open, and focus returns to the control you opened them
with. Checked by sending real Tab, Shift-Tab and Escape keypresses and reading
which element actually held focus at each step, rather than by reading the markup.

One thing that came out of testing it that way and would not have come out of
reading it: the tour panel's video used the browser's own control bar, and once
Tab had walked focus into that bar an Escape keypress never reached the page at
all — so a reader who tabbed as far as the volume slider could not close the
dialog from the keyboard. The panel now carries our own pause control instead,
which keeps every stop inside it ours.

**6. Background video: three of four now have a pause control, and reduce motion
is honoured.** *WCAG 2.2.2 Pause, Stop, Hide (A)*

Four videos started on their own and looped indefinitely with no pause control.
They are silent and purely decorative, which does not exempt them — this criterion
applies to anything that moves by itself for more than five seconds. They also
kept playing when the operating system is set to reduce motion.

Three now carry a visible control, reachable by keyboard, whose name says which
way it will go — "Pause the hero film" and then "Play the hero film" once it is
stopped. Those three are the film behind the homepage headline, the film beside
the sign-in form, and the tour panel's video. Under the reduce-motion setting none
of them starts on its own and the control offers to play instead; you can still
start it by hand. Checked by pressing the control with a keyboard and reading both
the video's own paused state and the control's accessible name, rather than
assuming the click did what it looked like it did.

The name is read from the video element itself rather than from what we intended,
which matters when a browser refuses autoplay: a control that says "Pause" over a
still frame reports the opposite of what is in front of you.

**The fourth video, on the Knowledge page, still autoplays and still loops with
no control.** It is named rather than left out of the count, and it is the next
one to close.

**7. Focus indicators: fixed, including the dropdown; two gaps named.** *WCAG
2.4.7 Focus Visible (AA), 1.4.11 Non-text Contrast (AA)*

An earlier version of this entry reported focus outlines "removed without a
replacement in an unknown number of places". Auditing it control by control found
the opposite problem: a site-wide rule gives every text field a visible focus
outline that individual pages cannot accidentally switch off — but on controls
drawn as a rounded pill around a borderless input, that outline painted a hard
black rectangle inside the rounded shape. Visible, and visibly broken.

Those controls now place a two-colour focus ring around the whole pill — an
accent stroke plus a white band, so that one or the other always clears the 3:1
contrast floor whether the control sits on paper or on a photograph. This was
verified with real keyboard and mouse input on the email and phone sign-ups, the
contact form, the calculator's sixteen fields, and the three search fields.

**The worst of the three gaps — the open dropdown — is now closed.** The
highlight marking the active row in an open list was a 4% ink wash: measured in
rendered pixels, 1.09:1 against the panel behind it, where the floor is 3:1. It
was also the only thing on screen telling a keyboard user which row they were on,
which made it the most serious defect left on the site.

It is fixed by making the control aware of how it is being driven, because the
mouse and the keyboard genuinely want different marks. Arrow keys now draw a 2px
accent stroke around the whole active row — measured 6.28:1 against the panel and
5.76:1 against the row's own wash, so it clears the floor against everything it
touches — while a hovering mouse still gets only the quiet wash, since the cursor
is already saying where it is and an indicator chasing it is noise. Verified by
opening the list from the keyboard and stepping through it, measuring the painted
pixels at every step, then repeating it with the mouse and confirming the accent
stroke does not appear. The list's own structure was re-checked at the same time
and was already correct: it reports itself as a list of choices, exactly one row
is marked as chosen, and the row the arrow keys are on is named to assistive
technology without focus ever leaving the list.

Two gaps remain, named so they stay visible: one visual variant of the email
sign-up has no live usage to verify against, and the sign-up that opens inside
the navigation panel could not be exercised by our tooling and has not been
confirmed.

**8. Form fields lose their label as soon as you type — fixed on the sign-ups,
one pattern still open.** *WCAG 3.3.2 Labels or Instructions (A)*

The email and phone sign-ups were named for assistive technology by an attribute,
which is the weaker half of the job: the only label a sighted visitor could see
was the placeholder inside the field, and that disappears on the first keystroke.
Each of those fields now carries a real label element, associated with the field
and positioned off-screen, so the name is a label rather than a string — read on
entering the field, listed when a screen reader enumerates the form, and no longer
dependent on the placeholder being visible.

It is hidden rather than shown because these pills are built to a measured
reference — 47px tall, an 18px radius, a 35×35 submit — with no room above them in
the navigation capsule or the footer. The hidden label is out of the layout flow,
and the geometry was measured before and after to confirm nothing moved: still
47px, still an 18px radius, still 35×35, through both steps of the phone flow.
Verified by typing into each field and reading the name back afterwards.

Two more fields in the application had no name at all, only a placeholder — the
case search inside a workflow and the "search users" popover — and both now have
one. So does every control inside a labelled field block, which previously drew a
label above the control and connected the two only visually.

**Still open:** the small upper-case field label used in 18 places in the
application is a visible label with no programmatic association, so the field
beside it is described on screen and unnamed to assistive technology. Fixing it
means touching each of those call sites, which is a separate pass; it is recorded
here rather than papered over with an invisible name that repeats the placeholder.

**9. Our base text size is smaller than your browser's default.** *related to WCAG
1.4.4 Resize Text (AA)*

We set a 13px base where browsers use 16px, and everything scales from that. If
you have deliberately raised your browser's default text size, we override it.
Browser zoom still works, so we do not record this as a formal failure of 1.4.4 —
but our smallest text lands under 10px, and someone who set a 20px default gets
13px. We are naming it because it is a real barrier whichever criterion it belongs
under.

## What we have not looked at

Listed one by one so the gap is visible rather than implied. None of this has been
tested, and any of it could be failing:

- **Focus not obscured** (2.4.11, AA) — new in WCAG 2.2. Our sticky header and the
  slide-over panel are the likely risks.
- **Target size** (2.5.8, AA) — new in 2.2. Our icon buttons are the likely risks
  at the density we use. Not audited, but one measurement fell out of the contrast
  work above and is worth recording: the segments of our segmented controls are
  13.5–16.1px tall against a 24px floor, and an automated pass flags 52 controls
  on a single application page. Several icon buttons already carry a helper that
  widens the target without moving the layout; these do not.
- **Consistent help** (3.2.6, A) and **redundant entry** (3.3.7, A) — new in 2.2.
- **Accessible authentication** (3.3.8, AA) — new in 2.2. Signing in goes through
  Microsoft, so this turns on what that flow asks of you.
- **Reflow** (1.4.10), **text spacing** (1.4.12) and **orientation** (1.3.4) — no
  audit has been run at small window sizes, with custom text spacing, or in
  landscape on a phone.
- The plain-text version of each reference page, as read by assistive technology.
- Any PDF we serve.
- Whether the charts are legible to colour-blind readers.

## What does work

Checked, not assumed:

- **There is no accessibility overlay on this site, and there never will be.** We
  checked for the common ones and found none, and our build now fails
  automatically if anybody adds one. Overlays paint a layer of accessibility
  information over a page as it loads without fixing what is underneath; they are
  widely reported to break screen-reader behaviour that worked before, and they
  account for a large share of US web-accessibility complaints. Everything here
  gets fixed in the code or not at all.
- The "reduce motion" setting in your operating system is honoured across our
  animation work, in 33 places, and now by three of the four background videos as
  well — under that setting they do not start. The fourth is named in item 6.
- The reference pages are semantic HTML: one main heading per page, no skipped
  heading levels, proper page landmarks, captions and column scopes on the data
  tables, and a visible focus style. The heading structure is verified on every
  build.
- Both sites declare their language, so a screen reader knows to read them in
  English.
- The reference pages need no JavaScript.
- Every reference page has a plain-text twin at the same address with `.md` on the
  end — often the easiest way to read this content with any tool at all.

## What we are fixing, and in what order

Done, with what was measured written into the entries above: the skip link (1),
the unnamed icon buttons (3), the switch states (4), the dialog behaviour on both
panels that open over a page (5), the pause control and reduce-motion handling on
three of the four videos (6), the dropdown highlight that was the worst remaining
focus gap (7), the sign-up labels (8), and the application kit's half of the
small-text contrast (2).

Next: the four contrast values on the reference pages, because they are one
stylesheet and small and contained. Then the last autoplaying video, on the
Knowledge page. Then the remaining contrast values, which are now a
screen-by-screen job rather than a shared one, and the 18 field labels that need
associating one call site at a time. Then whatever the manual NVDA and VoiceOver
pass turns up.

These are intentions, not dated commitments. This statement will be updated with
what actually happened rather than with what was planned.

## Reaching us

Email **accessibility@** the domain of the site you are reading, or use the
contact form. Tell us the page, what you were trying to do, and — if you know it —
your browser and assistive technology.

- We reply within **five business days**.
- **If something here is blocking you, we will get you the information another
  way** — by email, by phone, or as a plain text file — while the defect is open.
  You should not have to wait for a fix to get an answer.
- What you report goes into the same list as the findings above, and appears in
  this document once we have confirmed it.

## Standing

This statement is **self-assessed**. No third party has audited it, and we have
not published a VPAT or Accessibility Conformance Report. If you need a formal
report for a procurement or diligence process, ask — we would rather commission a
real one than issue a self-certified document that says what the form wants to
hear.

Nothing here is a warranty, and nothing here promises a compliance outcome under
the ADA, Section 508, EN 301 549 or any other regime. It is a description of what
we have checked, what we found, and what we have not looked at yet.

## Related

- [Editorial policy](https://ottoforfirms.com/editorial-policy/) — What we publish, how it is sourced, who reviews it, and what happens when it is wrong.
- [Statute of limitations on consumer debt, by state](https://ottoforfirms.com/statute-of-limitations/) — Limitations periods for all fifty states and DC, each cited to the state's own code.

## About Otto

Otto publishes this reference and builds collections software for US law firms. Corrections to this page are welcome, and so are questions about either — the contact form reaches us.

- [Get in touch](https://ottoforfirms.com/contact/)
- [See what it costs](https://ottoforfirms.com/pricing/)

---

This is a statement of our own practice, published so it can be checked against what we actually do. It is not legal advice and asserts nothing about anyone else's obligations. Where it is wrong or out of date, it is a defect in this document — tell us and it gets corrected here rather than quietly fixed.