Accessibility statement

Last updated: 6 October 2026

Anyone should be able to sign a document they've been sent, whatever device they use and however they use it. That includes people who use a screen reader, people who use only a keyboard, people who zoom the page or enlarge its text, and people who aren't confident with computers. This statement covers the SignSwifly website, the signing page your recipients use, and the SignSwifly web app you use to prepare and send documents.

Our commitment

Au Fait Solutions Pty Ltd, trading as SignSwifly, is working to make SignSwifly meet the Web Content Accessibility Guidelines (WCAG) 2.1 at level AA. The signing page comes first, because the people who use it didn't choose SignSwifly and may be using it for the first time. We check accessibility whenever we change the product, and we fix problems people report to us.

Conformance status

SignSwifly is partially conformant with WCAG 2.1 level AA. Partially conformant means that some parts of the content don't yet fully meet the standard. The known gaps are listed below. We haven't claimed full conformance because our own review isn't enough to confirm it: people who use assistive technology in their daily lives haven't tested the product yet, and no independent auditor has reviewed it yet.

What works today

  • Signing with a keyboard or screen reader. The signing page lists every field to fill in, in reading order. Each field is a button that says what kind of field it is, whether it's required, and which page it's on. Next field goes through the required fields one at a time. Each field opens in a dialog with labelled controls, and when the dialog closes, focus returns to the field.
  • The document's text. The signing page shows each page as a picture. Beside each picture, hidden from view, is the page's text, so a screen reader can read the document.
  • Signatures without drawing. You can type your signature instead of drawing it, or upload a picture of it. A typed signature is just as valid.
  • Errors. Errors are written out in words next to the field they belong to, and screen readers announce them. The page announces progress, such as attaching a file, completing signing, or a count of the required fields done.
  • Zoom and small screens. The signing page works at 320 pixels wide and at 200% zoom without scrolling sideways. The one exception is the document itself when you zoom in on it.
  • Colour and contrast. Text and controls meet WCAG AA contrast. A sender's brand colour is refused unless white text on it reaches 4.5:1. Required fields, errors and statuses are shown in words or symbols as well as colour.
  • Settings and the web app by keyboard. Menus that change something, such as a team member's role, act only once you choose an option: from the open list, or with Enter or Tab after the arrow keys. Escape puts the menu back as it was. Mistakes in what you type in Settings are written next to the field, and questions that need a typed answer, such as typing DELETE to confirm, open in a labelled dialog. When a plan limit makes a button unavailable, the reason is given in words linked to the button, not only in its tooltip.
  • Timeouts. An organisation can choose to sign people out of the web app after a period of inactivity. If it does, you get a warning two minutes beforehand and can choose to stay signed in. The signing page has no time limit of its own; the signing deadline is set in days: 90 on Free, or chosen by the sender on a paid plan.

Known limitations

  • The documents themselves are supplied by the sender. SignSwifly shows the PDF the sender uploaded, and we can't change what it says or how it was made. The text we give screen readers is taken from the PDF in the order the file stores it. That text has no headings or table structure, and for some layouts the order may be wrong. A scanned page has no text at all, and the signing page says so. If a document isn't accessible to you, ask the sender for an accessible copy or another way to sign.
  • Drawing a signature needs a mouse, finger or pen. Typing your signature or uploading a picture of it does the same job.
  • Placing fields and editing PDFs. In the envelope and template editors, pressing Enter on a field type adds it to the middle of the page you're viewing, and in the PDF editor, pressing Enter on a tool does the same with text, shapes and pictures. You can then move what you added with the arrow keys and set its exact position and size by number. Placing things precisely is still quicker with a mouse or touch, and we haven't tested this with screen reader users yet.
  • The document editor (used on the Solo plan and up to write documents and to edit the wording of Word templates) is built on a third-party component whose supplier rates it as partly meeting WCAG 2.2. It draws the page as a picture. With a screen reader it reads out text you select, not text as you move through it. Tab types a tab inside the document: press Escape and then Tab to move on, or Escape and then Shift+Tab to go back. It isn’t designed for phones. Its labels are in Australian English, and in Windows high-contrast mode it uses its own high-contrast colours. If it doesn’t work for you, write the document in Word or another program and upload it: it is converted and sent in the same way, and its wording can still be filled in from a template.
  • Built-in browser messages. Confirmations before something is deleted or changed, and some errors our servers report, still use the browser's own pop-up messages. So do some messages in the envelope and template editors. These are accessible, but they aren't linked to the field they're about.
  • Buttons that aren't available. When a plan limit makes a button unavailable, the reason is linked to the button, and is usually also written on the page. Screen readers skip unavailable buttons when you press Tab, so you may hear the reason only when you read the page.
  • Tables on small screens. On narrow screens, some tables in the web app are rearranged into lists, and some browsers then stop announcing them as tables. Others scroll sideways.
  • Text message codes When a sender asks for one, the code sent to your mobile expires after 10 minutes, and you can ask for a new code at any time.
  • Not yet reviewed. The emails SignSwifly sends haven't had a full accessibility review yet. The API reference for developers is drawn by a third-party viewer, and we've reviewed only the page around it.

How we assessed SignSwifly

This is a self-assessment. We reviewed the markup, styles and scripts of each page against the WCAG 2.1 level A and AA success criteria. We calculated the contrast of every colour in the design. On a test copy of the signing page, we ran automated checks with axe-core and walked through signing using only the keyboard, at 320 pixels wide and at desktop size. We did the same for test copies of the web app's Settings, envelope list, templates and PDF editor, and for this website. The document editor was reviewed from its supplier's own accessibility statement and by keyboard on a test copy; it hasn't been tested with a screen reader yet. Our automated test suite also checks that brand colours meet contrast, that every page declares its language and title, that each page of this website has one main heading with the others in order, and that no menu in Settings acts as you arrow through it. No independent third party has audited SignSwifly. Testing with the NVDA and VoiceOver screen readers, with people who use them every day, is planned.

Technical details

SignSwifly works in current versions of Safari, Chrome, Edge and Firefox, on computers, phones and tablets. It relies on HTML, CSS, JavaScript and WAI-ARIA, and it doesn't work with JavaScript turned off.

Feedback and help

If something on SignSwifly doesn't work for you, or you need a document in another format, please tell us. Email us or use our contact form. Tell us the page you were on and what happened, and we'll reply and help you finish what you were doing. If you were sent a document to sign, the sender can also give you another way to sign it.

If you aren't satisfied with our response, you can contact the Australian Human Rights Commission.

About this statement

We prepared this statement on 29 September 2026 from the self-assessment described above, and last updated it on 6 October 2026, when the document editor was added. We'll review it whenever SignSwifly changes significantly, and at least once a year.