Dozens of unnamed boxes for the IBAN, checkboxes without names, a missing tick font: how a public authority’s fillable forms automatically became PDF/UA-1 compliant – and what still remains manual work.
Anonymised case study from a real processing run; the name of the organisation and the document title have been changed.
The fillable PDF forms of a local authority – including a SEPA direct debit mandate – were practically impossible for screen reader users to fill in: for the IBAN, a long series of fields without names was announced, and checkboxes had no label. After the automatic repair, the forms scored 100 out of 100 points, and the PAC report also showed no errors for them. What remained open were questions no standards check answers: does the tab order match the visible order, and are required fields and labels understandable?
Starting point
With a SEPA direct debit mandate, citizens allow the authority to collect recurring amounts from their bank account. The form is short but dense: name and address, IBAN and BIC in boxes, checkboxes, signature. Other e-forms of the same authority had a similar structure. All of them were already fillable – visually clean, with one box per IBAN character. Because such forms are needed for ongoing administrative procedures, the exemption for older files generally does not apply (see Accessible PDF forms).
What the check found
- Box fields without labels: each IBAN character was a separate field without a tooltip. A screen reader announced dozens of unnamed input fields in a row – with no indication of what they were for. PDF/UA-1 requires a tooltip or an alternative description in the structure for every form field (veraPDF rule 7.18.1-3).
- Checkboxes without an accessible name: all that was announced was ‘checkbox, not checked’ – but not what for.
- Several fields in one Form element: under PDF/UA-1, a Form element without a Role attribute may contain only a single field (veraPDF rule 7.18.4-2).
- Tick font not embedded: the tick in the checkboxes comes from the ZapfDingbats font, which was not embedded in the document. PDF/UA-1 requires embedded fonts (veraPDF rule 7.21.4.1-1).
- Field fonts with gaps: the fonts of the field contents had missing or inconsistent glyph widths and incomplete encoding (veraPDF rules 7.21.5-1 and 7.21.7-1).
None of this was noticeable to sighted users: the boxes were in the right place, the tick appeared when clicked, and the labels were easy to read. However, they were only text on the page and not connected to the fields. Anyone going through the form with the Tab key and a screen reader therefore does not learn which field currently has focus – and with an IBAN of 22 characters can hardly tell whether a character has been skipped.
What DokAudit did automatically
- Tooltips for box fields: each character position was given a unique name following the pattern ‘IBAN, character 5 of 22’ – derived from the label of the field group and the position.
- Names for checkboxes: taken from the label text directly next to the box.
- One Form element per field: each form field now sits in its own Form element in the structure.
- Tick font embedded: ZapfDingbats was replaced by the free, metrically identical font URW D050000L – embedded, with glyph widths and Unicode mapping.
- Field fonts repaired: glyph widths taken from the font program, encoding and Unicode mapping added.
- Re-check: again with veraPDF and its own checks of the logical structure.
Result
Key figures of the SEPA forms case study| Feature | Before | After |
|---|
| IBAN boxes | fields without names | tooltip per character, e.g. ‘IBAN, character 5 of 22’ |
|---|
| Checkboxes | without an accessible name | name from the label next to them |
|---|
| Form elements | several fields in one element | one Form element per field |
|---|
| Tick font | ZapfDingbats, not embedded | URW D050000L, embedded |
|---|
| Field fonts | widths and encoding incomplete | corrected |
|---|
| Overall result | PDF/UA-1 failed | 100 out of 100 points; PAC report without errors |
|---|
What a person should still do
- Check the tab order: go through the form once using only the Tab key. The order now follows the structure; whether it matches the visible order, for example in two-column sections, has to be judged by a person.
- Required fields and error messages: these lie outside what PDF/UA checks, but are part of the WCAG criteria (3.3.2 Labels or Instructions). Mark required fields technically and visibly, not only by colour. Script-based error messages do not work reliably in many viewers.
- Understandable labels: explain terms such as ‘creditor identifier’ (Gläubiger-Identifikationsnummer) or ‘mandate reference’ (Mandatsreferenz) in a short sentence; the tooltips can include the explanation.
- Rebuild at the next revision: for the IBAN, a single field with character boxes (comb field) is better than 22 individual fields – one field, one tooltip, faster to fill in.
- Consider an online alternative: where an online application exists, it is more accessible for many people than any PDF.
Lessons learned
- Forms are particularly critical. Anyone filling in a form does not just have to read, but has to act. Here, a field without a name is not a blemish but a dead end.
- Tooltips are mandatory. PDF/UA-1 requires them for every field; WCAG 4.1.2 (Name, Role, Value) requires that assistive technologies can name every field.
- Invisible technology counts. Nobody sees a tick font that is not embedded – it still prevents conformance.
- Automatically compliant does not mean automatically easy to use. The tab test and a short trial with a screen reader belong to every form (Test it yourself).
Sources:
As of: 10/2026. This article gives a general overview and is not legal advice. The legal and standards texts in force are authoritative; in individual cases, the law of the German states (Länder) may differ.