Our commitment
We aim to meet or exceed the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA. Where practical, we adopt Level AAA criteria and follow related standards including the EU Web Accessibility Directive (EN 301 549), the UK Public Sector Bodies Accessibility Regulations 2018, and the US Section 508 Refresh.
Conformance status
This website is partially conformant with WCAG 2.2 AA. “Partially conformant” means some parts of the content do not yet fully conform — see “Known limitations” below.
What we’ve done
- Semantic landmarks (
header,nav,main,footer) on every page, with onemainper route. - A “Skip to main content” link available on first keyboard tab.
- Visible, high-contrast keyboard focus indicators on every interactive element (WCAG 2.4.7).
- Focus is never trapped or obscured by sticky elements; focusable items keep clear scroll margin under the sticky header (WCAG 2.4.11 / 2.4.12, new in 2.2).
- Decorative animation respects
prefers-reduced-motion(WCAG 2.3.3). - Icon-only buttons carry
aria-labeltext; form fields are programmatically associated with their labels. - Colour contrast meets AA: 4.5:1 for body text, 3:1 for large text and meaningful UI components.
- Built on Radix UI primitives (via shadcn/ui), giving accessible-by-default menus, dialogs, popovers, comboboxes and tooltips.
- Mobile tap targets meet the 24×24 minimum (WCAG 2.5.8, new in 2.2); primary actions exceed 44×44.
- Forms support paste, autofill and password-manager workflows — no “type your password twice from scratch” barriers (WCAG 3.3.7 Redundant Entry / 3.3.8 Accessible Authentication, new in 2.2).
- The signature HTML we generate uses real table semantics and inline styles that render predictably across screen readers and assistive technology in Gmail, Outlook, Apple Mail and iPhone Mail.
- The site is responsive from 320 px upward, supports 400% zoom, and uses dynamic viewport units (
dvh) so mobile chrome never clips content. - HTML
langis declared; page titles and headings follow a logical order (singleh1, no skipped levels). - Server-rendered metadata and Open Graph data on every shareable route — assistive tech and previews get accurate page descriptions.
Technologies we rely on
Accessibility depends on the following technologies being supported by your browser and any assistive technology you use: HTML, WAI-ARIA, CSS and JavaScript.
Assessment approach
- Automated linting on every change using axe-core rules.
- Manual keyboard-only walkthroughs of all primary flows.
- Screen reader spot-checks with VoiceOver (macOS, iOS) and NVDA (Windows).
- Colour-contrast verification against WCAG AA at design-token level.
Known limitations
Despite our best efforts, some content may not yet be fully accessible. We are actively working on:
- The live signature preview iframe inherits the styling of the host email client; some downstream clients may render with lower contrast than our preview.
- A small number of third-party embeds (e.g. analytics, marketing pixels) are outside our direct control.
- Older blog posts may pre-date our current heading and alt-text standards. We re-audit on edit.
Feedback & reporting a barrier
If you encounter any accessibility barrier on Email Art, please tell us. We aim to respond within 2 business days and resolve substantive issues within 10 business days.
- Email: accessibility@emailart.io
- Contact form: /contact — choose “Accessibility” from the reason dropdown if available, otherwise mention it in your message.
Please include the page URL, the browser and assistive technology you used, and a brief description of the barrier.
Formal complaints
If you are not satisfied with our response, you may escalate under your local regulator’s framework — for example the UK’s Equality and Human Rights Commission, the Australian Human Rights Commission, or the relevant body under the EU Web Accessibility Directive in your member state.
Date
This statement was prepared on 30 May 2026 and is reviewed at least annually, and whenever we ship a substantial change to the product.