Document type

Making forms accessible

Application, claim, registration and consent forms published as PDF: why their fields fail screen readers, which public sector rules reach them, and the fixes.

A public sector form is often the only way into a service: an application for a permit or a grant, a claim for a refund, a registration, a consent to share information. Forms published as PDF come in two shapes. A fillable form carries interactive fields added in design or form software, and a print and post form is a flat page, sometimes a scan of an older paper original, that the person prints, completes by hand and sends back. Each shape fails a disabled person in its own way, and a form that cannot be completed is a service that cannot be used. The Web Accessibility Directive (EU) 2016/2102 applies to the websites and mobile applications of public sector bodies, and its recitals state that their content includes downloadable documents and forms and the processing of digital forms. Office files such as PDF published before 23 September 2018 are excluded, unless the content is needed for active administrative processes relating to the tasks of the body concerned. Regulation 4 of the UK Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 contains the same exclusion and the same exception, and UK government guidance illustrates it with a form that lets you request school meal preferences: an older document is still covered when users need it to use a service. Under regulation 8, a body's accessibility statement must explain which parts of its content are not accessible and why, describe any accessible alternatives, and link to a contact form through which a person can report a failure or request excluded information. In Great Britain, section 29 of the Equality Act 2010 applies the duty to make reasonable adjustments to service providers and to people exercising public functions; Schedule 2 says that for this duty the disabled person concerned is to be read as disabled persons generally, and section 20(6) says the steps include making sure information is provided in an accessible format. Normfluss checks each PDF against PDF/UA-1 and the WCAG AA success criteria that apply to PDF, remediates it, and issues a signed evidence record stating which checks ran and what they found, with documents processed in the EU. The record documents conformance within a stated scope; it does not show that a form works with every assistive technology, and whether a body meets its legal duties is for the body and its advisors to decide.

Where forms typically fail accessibility

• Fields have no tooltip or accessible name, or only the internal name the form software gave them, so a screen reader announces 'edit text' or 'Text17' instead of 'Surname'; the visible label is just text printed near the box and nothing ties the two together.
• The tab order follows the order in which the fields were drawn rather than the order of the form, so pressing Tab jumps from the applicant's name to the declaration and back to the address.
• Required fields are marked only with an asterisk or a colour, with no text and no required setting on the field, so a person finds out a field was mandatory only when the claim is returned (WCAG 1.4.1 and 3.3.2).
• Date, postcode and reference number fields reject input with a red border or by silently clearing the box, without saying in text what was wrong or what format is expected (WCAG 3.3.1 and 3.3.3).
• Tick boxes and radio buttons are not grouped under the question they answer, so a person hears 'check box, not checked' several times with no idea which question or which option each one is.
• The declaration sits above the signature field but outside the reading order, and the signature field itself has no name, so a person can reach the place to sign without having heard what they are declaring or who is meant to sign.
• Forms are flattened when saved or printed to PDF, turning every field into a drawn box, or are scans of a paper original with no text layer, which leaves nothing to type into and nothing for a screen reader to read.
• Section headings, numbered questions and the guidance notes that explain how to answer are styled text with no tags, and notes printed on the last page are never connected to the questions they explain.

Remediation checklist

• Give every field an accessible name, set as its tooltip, that matches the visible label and states any format expected, such as a date as day, month and year (WCAG 3.3.2 and 4.1.2).
• Set a tab order that follows the structure of the form, section by section, and matches the reading order of the page (WCAG 2.4.3).
• Say that a field is required in its label text and set the field as required, rather than relying on an asterisk or a colour.
• Where a field checks its input, make the message say in text what is wrong and how to correct it (WCAG 3.3.1 and 3.3.3).
• Group each set of tick boxes or radio buttons under the question it answers, and give each option a name that makes sense on its own.
• Keep the declaration in the reading order immediately before the signature field, name the signature field for the person who signs, and state in the form how else a person can sign or confirm.
• Replace flattened and scanned forms with a fillable version produced from the source file; where a print version must stay, OCR it, check the recognised text, and tag its headings, questions and guidance notes.
• Check each form against PDF/UA-1 and the WCAG AA success criteria that apply to PDF, keep the signed record with that version of the form, and list any form not yet accessible, with its alternative, in the accessibility statement.