What a fillable PDF form needs for screen readers and keyboard users – from tooltips and boxed fields such as the IBAN to required fields and error messages. And what can be solved automatically.
A PDF form is accessible when every input field is a real, fillable form field, has an understandable accessible name, can be reached with the Tab key in a logical order and sits in the right place in the document structure. Application forms deserve particular attention: they are needed for active administrative processes. The exemption for files published before 23 September 2018 therefore generally does not apply – the old form that is still in use must be accessible too.
Flat, fillable, accessible
- Flat form: lines and boxes for printing out. Anyone who cannot see or cannot hold a pen cannot fill it in.
- Fillable: there are form fields (AcroForm), but often with names such as ‘Text Field 12’ or ‘Check Box7’ – a guessing game for screen reader users.
- Accessible: in addition, every field has a description, sits in the structure, can be reached in a sensible order, and required fields and formats are recognisable.
Dynamic XFA forms (for example from older LiveCycle workflows) are not permitted under PDF/UA-1 and are not displayed at all by many viewers. They should be converted into AcroForm forms.
Labels: visible and accessible
- Visible label: every field needs a visible label or instruction (WCAG 3.3.2), right next to the field.
- Accessible name: the screen reader reads the field’s tooltip (the TU entry in the PDF, ‘Tooltip’ in Acrobat). PDF/UA-1 requires such a tooltip or an alternative description in the structure for every form field (WCAG techniques PDF10 and PDF12).
- Tooltip and label match: the tooltip takes over the visible label and adds any necessary hints – ‘Date of birth (DD.MM.YYYY)’ instead of just ‘Date’.
- Radio buttons and check boxes: the group needs a question (‘Marital status’), each option its own label (‘single’, ‘married’ …).
Tab order and structure
PDF/UA-1 requires that on every page with form fields the tab order follows the document structure (page entry Tabs with the value S) and that every field sits in a Form tag in the tag tree. Then the reading order and the tab order match (WCAG technique PDF3). With two-column forms you have to decide: row by row or column by column – what matters is what belongs together in terms of content, such as street and house number.
Boxed fields: IBAN, postcode, date
Many forms provide a separate box for each character. Technically there are two ways:
- One field with character boxes (comb field): a single field with a fixed number of characters that spreads the input evenly across the boxes. Ideal for screen readers – one field, one tooltip: ‘IBAN (22 characters, no spaces)’.
- Many individual fields: each box is a separate field. Then each needs its own tooltip such as ‘IBAN, character 3 of 22’, and filling it in is tedious. If an existing form cannot be rebuilt, this is still better than 22 nameless fields.
Required fields, formats, error messages
- Required fields should be marked as required technically (WCAG technique PDF5) and also visibly – not just by red colour or an unexplained asterisk. The hint ‘required field’ also belongs in the tooltip.
- State formats in advance: expected formats are given in the label and tooltip before anyone enters anything.
- Error messages via script are possible and should name the error in text form (WCAG technique PDF22). But do not rely on them: many viewers, especially in the browser, do not run form scripts, or only partly.
- Buttons such as ‘Print’ or ‘Submit’ need a label that says what they do.
What can be automated – and what cannot
- Easy to automate: tab order following the structure, Form tags for every field, tooltips from the adjacent label, ‘character n of m’ tooltips for box groups, labels for check boxes from the text next to them.
- Automation with a suggestion: in flat forms, fields can be detected; but the suggestion has to be corrected by a person – software cannot always tell a box from a decorative line.
- People only: whether labels are understandable, which fields belong together, which hints are missing and whether the form is needed at all. Where an online application is available, it is more accessible for many people than any PDF.
Common mistakes
- Field names such as ‘Text Field 12’ are the only description.
- The tooltip contradicts the visible label.
- Fields are not in the structure, and tab focus jumps across the page.
- Required fields are marked only by colour.
- The form is a scan that can only be filled in with a pen.
- A dynamic XFA form that stays blank in the browser.
How DokAudit helps
During repair, DokAudit gives form fields understandable tooltips – including boxed fields such as IBAN characters –, places each field in the structure and aligns the tab order with the structure; veraPDF then checks the result. For flat application forms there is the Make form fillable tool: it suggests fields, you correct them, and the result is fillable fields with tooltips, tab order and, if you wish, character boxes. Whether the labels are understandable for your target audience is best checked yourself – with the Tab key and a screen reader (Test it yourself).
Sources:
As of: 09/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.