Accessibility statement
Our target is WCAG 2.2 level AA. This page says what we have built, what we have not yet tested and how to tell us about a barrier.
We are building the MyDataHub by Emailmovers pages on emailmovers.com, and the app at mydatahub.emailmovers.com, to meet WCAG 2.2 level AA. The pages have not yet had an external accessibility audit, which is planned for the first quarter of 2027, before public launch.
So we do not claim conformance. We do list what we built in, the colour contrast we checked and what we will test next. If you find a barrier, call us on 01723 800030.
How accessible are these pages?
This statement covers the pages Emailmovers Ltd publishes on emailmovers.com: the MyDataHub pages, the pages for buying B2B data and email lists, the trust pages, the guides and this page. It also covers the app at mydatahub.emailmovers.com. The target for all of them is WCAG 2.2 level AA.
We have built in the following. Each is a fact about how the pages are made, not a test result.
- A "Skip to the content" link, one main landmark and a breadcrumb navigation with the current page marked.
- One H1 per page, headings in order and a contents list on long pages.
- Tables with captions and scoped header cells. Wide tables scroll inside a region you can reach with the keyboard.
- A visible focus ring on every link and control, in navy on light surfaces and mint on dark ones.
- Controls at least 24 pixels high, and most are 44 pixels, with text that resizes with the browser setting.
- No JavaScript on content pages except the count widget, and motion that stops when you ask your device to reduce it.
- The count widget announces its result in one polite live region, and it works without scripts as a link to the app.
How do you give feedback or ask for another format?
Call us on 01723 800030. Tell us the page, what you were trying to do and what got in the way. Say if you need the information in another format, such as large print, a plain text file or an audio recording.
A published email address and contact form for accessibility requests will be added to this page before launch.
What has been tested, and what has not?
We have checked the colour pairs the site uses against the WCAG 2.2 contrast thresholds, and the table below shows the ratios. The ratios are calculated from the colour values in the style sheet when this page is built.
| Where it is used | Foreground | Background | Ratio | Minimum |
|---|---|---|---|---|
| Body text on white | #2B284D | #FFFFFF | 13.9 to 1 | 4.5 to 1 |
| Headings on white | #1E1E2D | #FFFFFF | 16.4 to 1 | 4.5 to 1 |
| Secondary text on white | #5C5F72 | #FFFFFF | 6.3 to 1 | 4.5 to 1 |
| Secondary text on cloud sections | #5C5F72 | #F4F5F7 | 5.8 to 1 | 4.5 to 1 |
| Table header text on its tint | #5C5F72 | #FAFBFC | 6.1 to 1 | 4.5 to 1 |
| Mint text on light (12px overlines and small numbers) | #0F6B55 | #FFFFFF | 6.5 to 1 | 4.5 to 1 |
| Mint text on light (larger text) | #157A61 | #FFFFFF | 5.3 to 1 | 4.5 to 1 |
| Mint badge text | #0F6B55 | #D6FBF0 | 5.8 to 1 | 4.5 to 1 |
| Highlighted table row | #2B284D | #ECFEF9 | 13.3 to 1 | 4.5 to 1 |
| Primary button: ink on mint | #1E1E2D | #6EEDC9 | 11.4 to 1 | 4.5 to 1 |
| Secondary button: white on navy | #FFFFFF | #36325E | 11.8 to 1 | 4.5 to 1 |
| Hero headline on navy | #FFFFFF | #221F40 | 15.7 to 1 | 4.5 to 1 |
| Hero lead on navy | #C3C0DA | #221F40 | 8.9 to 1 | 4.5 to 1 |
| Count digits: mint on navy | #6EEDC9 | #221F40 | 10.9 to 1 | 4.5 to 1 |
| Footer text on navy | #E4E2EF | #36325E | 9.3 to 1 | 4.5 to 1 |
| Warning badge text | #8A5A0B | #FCF2E1 | 5.3 to 1 | 4.5 to 1 |
| Preview banner text | #4D3306 | #FCF2E1 | 10.6 to 1 | 4.5 to 1 |
| Information note text | #221F40 | #E9EDFB | 13.4 to 1 | 4.5 to 1 |
| Focus ring on white | #494579 | #FFFFFF | 8.7 to 1 | 3 to 1 |
| Select border on white | #797C8E | #FFFFFF | 4.1 to 1 | 3 to 1 |
The brand mint, #6EEDC9, is 1.4 to 1 against white and fails as text, so mint text on a light background uses #157A61 or #0F6B55 instead. Bright mint appears only as a button fill with dark text, and as text on dark navy surfaces.
We have not yet tested the pages with a screen reader, with speech recognition or with keyboard-only use across every template, and an external audit has not taken place.
What content may not be accessible?
We have not yet found specific failures, because we have not completed the testing above. These are the areas we will test first, because they carry the most risk.
- The count widget and its live region, with NVDA and VoiceOver.
- Data tables on narrow screens, where they scroll horizontally inside a region.
- Code samples on the API page, which scroll horizontally.
- In the app, the filter chips, the command palette and the breakdown charts.
What are we doing to improve accessibility?
We plan the following, and we will say here when each is in place.
- An external accessibility audit and a penetration test in the first quarter of 2027, before public launch.
- Automated checks on every pull request: axe-core in Playwright on ten core states, Pa11y CI at zero errors and Lighthouse accessibility at 100, as blocking checks.
- Screen reader walkthroughs with NVDA and VoiceOver each quarter, and an external audit each year.
- A review of this statement every six months.
Which patterns do we build to in the app?
| Component | Pattern |
|---|---|
| Filter chips | Each chip is a list item with a remove button labelled in full, such as "Remove filter: Job level Director", and focus moves to the next chip. |
| Live count | One hidden region with aria-live polite and aria-atomic true announces "12,480 matching contacts" after a 500 millisecond pause, and stays silent while you type. |
| Breakdown charts | Each chart has role img, a text summary and a data table you can switch on. |
| Command palette | A modal combobox with aria-activedescendant, opened by Ctrl+K or a button. |
| Targets and sign-in | Targets are at least 24 pixels, and 44 pixels on touch. Every slider has a numeric input beside it. Paste is allowed, sign-in uses magic links and passkeys, and there is no CAPTCHA. |
How was this statement prepared?
We prepared this statement on 3 October 2026 from our own review of how the pages are built. It follows the layout of the GOV.UK model accessibility statement, and we will review it every six months.