Start free
Accessibility

Accessibility statement

We want anyone to be able to send and sign documents with AiresDocs, whatever device or assistive technology they use. This statement explains what we have done, where we fall short, and how to tell us about problems.

Last reviewed 9 October 2026

Our standard

We aim for the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA across airesdocs.com, the app at app.airesdocs.com and, most importantly, the public signing page that recipients use without an account. The signing page is the part most people will meet, often on a phone, so it is where we test hardest.

What we have done

  • Keyboard. Controls on the website, the editor and the signing page are built to be reached and operated with a keyboard, including placing fields (with the arrow keys), opening the signature pad, choosing a signature method, ticking consent and finishing. Our browser tests tick consent and open signing fields using only the keyboard; the rest has not yet been tested end to end with a keyboard. Focus is visible with a high-contrast ring.
  • Labels and structure. Form fields have programmatic labels; pages use proper headings, landmarks, lists and tables; breadcrumbs and navigation are labelled; buttons say what they do.
  • Contrast. Text and interactive elements meet a 4.5:1 contrast ratio (3:1 for large text and UI components) in both light and dark themes. The theme follows your system preference and can be switched.
  • Motion. Animations (the hero, scroll reveals, the finch mark) are reduced or removed when your system sets "reduce motion". Nothing flashes.
  • Reflow. Pages are built to reflow without horizontal scrolling. Our tests check this at 390, 1440, 1920 and 2560 pixels wide; 320 px and 200% zoom have not yet been tested.
  • Signing without drawing. People who cannot draw a signature can type one or upload an image. Required fields are counted so progress is clear.
  • Status messages. Errors are described next to the field, and errors and results such as "contract sent" are marked up as status messages so that screen readers can announce them. We have not yet confirmed this with screen readers (see Testing).
  • Documents. The completion certificate page we add to PDFs uses real text, not images of text, so it can be read by assistive technology.

Known limitations

  • The PDFs you upload are rendered as page images in the editor and on the signing page. If the PDF is not tagged, a screen reader will not read its contents on screen; the signer can download the original PDF, which keeps whatever accessibility it had. We encourage senders to use tagged, text-based PDFs.
  • Drawing a signature requires a pointer or touch; the typed and uploaded alternatives are provided for everyone.
  • Placing fields precisely with the keyboard uses arrow keys and is slower than dragging. We are improving this.
  • Small tick boxes and option buttons on the signing page can be smaller than the 24 by 24 pixel target WCAG 2.2 asks for (2.5.8 Target Size) at phone width. Our automated checks currently leave this one rule out on that page while we fix it.
  • Third-party pages (Stripe checkout and billing portal) are governed by Stripe's own accessibility work.

Testing

Our test suites run automated checks with axe-core against the WCAG 2.0, 2.1 and 2.2 level A and AA rules on the website, the app pages and the signing page (including a signing page that shows every field type), on a phone-width and a desktop screen, in light and dark themes, and any serious or critical problem fails the test run, with one exception: the target-size rule on the signing page with every field type, described under Known limitations. Our browser tests also tick consent and open signing fields using only the keyboard, and check layout at 390, 1440, 1920 and 2560 pixels in both themes without horizontal scrolling.

Automated checks find only part of what WCAG asks for. We have not yet had an independent accessibility audit, and we have not yet completed structured testing with screen readers. Both are planned, and this statement will say when they are done and what they found.

Section 508 and WCAG 2.1 AA

US public-sector buyers often ask for a Section 508 conformance report (a VPAT or Accessibility Conformance Report). Section 508 refers to WCAG 2.0 level AA, and our target, WCAG 2.2 AA, builds on WCAG 2.0 and 2.1 AA (it adds criteria and retires one that browsers made obsolete). We will publish a conformance report once the independent audit is done; until then we can share our automated test results on request.

Report a problem

If you find something you cannot use, email support@airesdocs.com with the page, what you were trying to do, and your browser and assistive technology. We aim to reply within two working days and to fix accessibility problems ahead of other work. If you are a signer who cannot complete a document, tell the sender as well: they can resend it or arrange another way to sign.

Enforcement

In the UK, the Equality and Human Rights Commission enforces the Equality Act 2010 and the accessibility requirements that apply to service providers. If you are not satisfied with our response, you can contact the Equality Advisory and Support Service (EASS).