What works,
and what doesn't yet.
We aim for WCAG 2.1 Level AA. That is a target we are working toward, not a conformance claim — no independent audit has been carried out, and we will not say otherwise until one has. What follows is what we have fixed, what we know is still wrong, and how to tell us about anything we have missed.
Tell us and we'll fix it.
If any part of Email Digit blocks you, email info@emaildigit.com with the page and what happened. A real person reads it. If you need information from this site in another format while we fix the underlying problem, ask and we'll send it directly — you should not have to wait for a release to get an answer.
What we know is still wrong.
Dated and specific, because a vague statement here is worth nothing to someone deciding whether they can use the product.
The desktop “Product” menu is not properly keyboard-operable
It opens on hover and focus rather than on activation, and it does not report an expanded or collapsed state. A keyboard or screen-reader user can reach it and can reach the links inside it, but the control does not behave like the menu button it appears to be. Rebuilding it as a real disclosure button is the next accessibility change we intend to make.
The dashboard has not been assessed at all
Everything on this page concerns the public site. The signed-in application — the builder, the campaign composer, the inbox and the contact record — has had no accessibility review. It contains drag-and-drop editing and a canvas-based automation editor, and we should assume both are unusable without a mouse until we have checked. We are not going to guess in your favour on this.
Colour contrast has not been systematically verified
The palette was designed for legibility and the body text is high-contrast, but we have not measured every foreground and background pair against the 4.5:1 threshold. Muted secondary text on tinted panels is the most likely place to fall short.
No automated accessibility checks run in CI
Nothing currently fails a build for an accessibility regression, which means fixes on this page can silently come undone. Adding automated checks is what will keep this list honest over time rather than accurate only on the day it was written.
Screen-reader testing has been limited
We have relied mainly on the accessibility tree and on keyboard navigation. That reliably catches missing names and unreachable controls; it does not catch awkward reading order or announcements that are technically correct but useless in practice. One specific open question: whether every navigation item in the signed-in sidebar announces its name correctly.
What changed in August 2026.
Kept here rather than deleted, so the list above can be read as a trajectory instead of a snapshot.
The public site was unusable on a phone
There was no mobile navigation anywhere in the codebase. The desktop navigation and the call-to-action row stayed side by side at every screen width, so a 375px viewport laid out a document roughly 840px wide — every marketing page scrolled sideways, with content pushed off screen. There is now a proper navigation menu below 900px.
The “skip to content” link went nowhere
The skip link targeted a main landmark that most pages did not have, so activating it did nothing on seventeen of them — including one page that had a main element but no matching id. Every public page now has the landmark, and the link works.
Verified by using it, not asserted.
Deliberately short. Everything listed here is something we have exercised ourselves; anything we have not exercised is in the gaps above instead.
Keyboard navigation on the public site
Every link, button and form control on the marketing pages, the free tools and the sign-in flow can be reached and operated with a keyboard, with a visible focus indicator, in a reading order that follows the page.
Semantic structure and landmarks
Pages use real headings in order, a main landmark, labelled navigation regions, and form fields tied to their labels rather than relying on placeholder text.
Right-to-left languages
Arabic, Urdu and Hebrew are supported in generated email, including correct direction handling for mixed content — a rendering problem most sending tools leave to the sender.
No reliance on colour alone
Status is carried by text or shape as well as colour, so a pass or a failure does not depend on distinguishing green from red.
What we're measuring against.
WCAG 2.1 Level AA, as published by the W3C. Where this site falls short of it today, that shortfall is listed above rather than described in general terms. We review this page when we ship accessibility work, and the date at the top of the “recently fixed” section is when it was last revised.