Build accessible forms

How published forms work with a keyboard, a screen reader and other assistive tools, what is not there yet, and how to write a form that is easier for everyone.

A form built with Tinyform is meant to be fillable by somebody who never touches a mouse and by somebody who cannot see the page. The published form is ordinary, semantic HTML rendered on the server, so the accessible foundation is the browser's own, and the pieces built on top of it are written to keep that foundation intact. This page says what that means in practice, where the gaps are, and what you can do on your side.

How accessibility is approached

The renderer draws every question with a real form element where one exists: an input, a textarea, a select-like button with a listbox, a group of radio buttons or checkboxes. Where a control has no native counterpart, the ranking list or the drawn signature, it is given the role, the name and the keyboard behaviour that the W3C's guidance for that pattern describes. The reference for new fields is the WAI tutorial on forms, linked at the bottom of this page.

Two things follow from the page being rendered on the server. It is complete before any script runs, so a screen reader that starts reading immediately is reading the real form. And the document's language and writing direction are set from the form's Language setting in Settings, so a form written in Arabic is announced in Arabic and laid out right to left rather than being read with an English voice.

What works today

Keyboard

Every field is a Tab stop, and the whole form, from the first question to the submit button, can be filled in and sent without a pointer.
The arrow keys move between the options of a multiple choice question, a rating and a linear scale, which are radio groups.
A dropdown and a multi-select open with the keyboard and are navigated with the arrows, Enter and Escape; the button carries the combobox role and the popup the listbox role, so a screen reader knows what opened.
The phone number field's country picker is a keyboard listbox in the same way.
The date picker's calendar is one Tab stop rather than one per day: the arrows move a day or a week, Home and End jump to the ends of the week, PageUp and PageDown change the month.
A ranking list is reordered without dragging: focus a handle, press Space to lift the item, move it with the arrows and press Space again to drop it.
Every focused control shows a visible focus ring.

Screen readers

Each field is labelled by its own question, and a required question is marked with the word Required rather than only an asterisk, in the form's language.
A refusal, an empty required field or an answer that failed a check, is drawn per field, attached to that field's control and announced as an alert the moment it appears; you do not have to hunt for it. The message is translated with the rest of the form.
A rating announces each option with its value, "3 of 5 stars", not a bare number.
A matrix cell names both its row and its column when read.
An option with a picture is announced by its text; the picture is marked decorative so it is not read twice.
Checkbox and multi-select questions are grouped and named, so a screen reader says which question the boxes belong to.
The progress bar on a multi-page form announces which page you are on and how many there are, rather than a percentage.
A button whose words are hidden at narrow widths to leave only its icon keeps its accessible name; a button with no icon keeps its words.

In the editor

The editor is for the form's author and is a richer surface than the published page, but the same rules apply to it: the handles that resize a picture or a video, the buttons that add and remove a matrix row or column, and the grips that reorder options all carry names, and the preview inside version history is inert so a screen reader does not wander into a form that cannot be edited.

Known limitations

Signature. The pad is a drawing surface. It has a name and reports whether it is required and whether it was refused, but there is no way to produce a signature from the keyboard. If a form must be fillable without a pointer, do not make the signature required, or offer another way to sign.
Embedded content. A video, a map or another site embedded in a form is drawn inside a frame, and how accessible that frame is depends on the site it comes from.

If you hit something that does not work with your keyboard or your screen reader, write through Contact support with the form and the tool you used. Accessibility work here is driven by reports.

Tips for creating accessible forms

The renderer can only do so much; what you write into the form matters as much.

Give every question a visible label. Placeholder text disappears when a respondent starts typing and is not reliably read out. See How to name question fields.
Add help text where a question needs explaining. A format, an example or a reason sits in plain words under the question, where every reader meets it before the control.
Do not let colour carry meaning alone. If a red option means one thing and a green one another, say so in the words too.
Fill it in with the keyboard before you publish. Tab through the whole form once. Anything you cannot reach, a respondent cannot either.
Keep it short. Fewer questions is less work for everyone, and most of all for somebody navigating one field at a time.
Split a long form into pages. Page breaks with clear titles give a respondent a place to rest, and the progress bar tells them where they are.
Pick the right language. The Language setting decides the voice a screen reader uses and the direction the page is laid out in, as well as the wording of every built-in message.