Barrierefreie Formulare in PDFs

Was ein PDF-Formular ist – und was nicht

Im Sprachgebrauch wird vieles „PDF-Formular" genannt – die folgende Unterscheidung lohnt sich. Ein interaktives PDF-Formular enthält ausfüllbare Felder, die direkt im PDF-Reader bedient werden können. Reine Druckvorlagen, in die Personen handschriftlich oder am ausgedruckten Bogen Text eintragen, sind keine PDF-Formulare im hier behandelten Sinn.

Technisch entsteht ein interaktives Formular durch Form-Felder(PDF-Spec: Form Fields ) und ihre Darstellung als Widget-Annotationen auf den Seiten. Diese Konstruktion ist in ISO 32000-2 Abschnitt 12.7 definiert. Sie ist nicht zu verwechseln mit dem Inhalt der Seite selbst – Form-Felder leben in einer eigenen Schicht über dem Content Stream.

AcroForm vs. XFA

Historisch existieren zwei Formular-Technologien parallel:

• AcroForm – das klassische, PDF-eigene Formular-Modell. Wird von praktisch allen PDF-Readern unterstützt und ist der Standard für barrierefreie Formulare.
• XFA(XML Forms Architecture) – eine XML-basierte Formular-Sprache, von Adobe entwickelt. Mit PDF 2.0 (ISO 32000-2:2020) als deprecated markiert; viele moderne Reader öffnen XFA-PDFs nur eingeschränkt oder gar nicht.

Für barrierefreie PDFs ist deshalb klar: AcroForm. PDF/UA-1( ISO 14289-1) lässt XFA-Formulare schon im technischen Anhang weitgehend außen vor; ein vollständig konformes PDF/UA-Dokument verwendet sie nicht.

Die wichtigsten Feldtypen

AcroForm kennt vier Grundtypen. Aus Sicht der Barrierefreiheit ist der gewählte Typ wichtig, weil Reader und Screenreader die Felder entsprechend ankündigen – „Eingabefeld", „Kontrollkästchen", „Auswahl" und so weiter:

AcroForm-Feldtypen nach ISO 32000-2

Feldtyp	Konkrete Untertypen	Wofür
Button	Pushbutton, Checkbox, Radio-Button	Aktionen auslösen, einzelne Ja/Nein-Werte, Auswahl aus Gruppen.
Text	Einzeilig, mehrzeilig, Passwort, Datei-Pfad	Freitext-Eingabe; mehrzeilig für längere Antworten.
Choice	Listbox, Combobox	Auswahl aus vorgegebenen Optionen.
Signature	–	Digitale Signatur – meist nicht für Eingabe, sondern für Bestätigung.

Kontrollkästchen und Radio-Buttons verhalten sich semantisch unterschiedlich: Mehrere Kontrollkästchen sind voneinander unabhängig (Mehrfach-Auswahl), Radio-Buttons innerhalb einer Gruppe schließen sich gegenseitig aus (Einfach-Auswahl). Dass ein Feld in derselben Gruppe ist, wird über den geteilten Field Name gesteuert – das ist der häufigste Stolperstein in nicht-konformen Formularen.

Beschriftungen: T, TU und der sichtbare Label-Text

Ein Feld kann mehrere Bezeichner haben. Drei sind für Barrierefreiheit relevant:

• /T – der partielle Field-Name. Wird vor allem programmatisch genutzt (Adressierung in Formularverarbeitung, XML-Submission). Für Endnutzer:innen meist nicht sichtbar.
• /TU – der Tooltip bzw. alternate field name. Wird von Reader und assistiver Technologie als barrierefreier Name ausgelesen, wenn das Feld den Fokus bekommt. Bei PDF/UA ist eine sinnvolle /TU -Angabe in der Regel die maßgebliche Beschriftung.
• Sichtbarer Label-Text auf der Seite – die Beschriftung neben dem Feld. Im Idealfall stimmt er mit /TU überein.

Tab-Reihenfolge: die wichtigste Einstellung

Ein Formular wird üblicherweise mit der Tab-Taste bedient. Die Reihenfolge, in der die Felder den Fokus bekommen, muss zur visuellen Anordnung passen – sonst springt der Fokus zwischen unzusammenhängenden Feldern hin und her.

Im PDF wird diese Reihenfolge über das Seiten-Attribut /Tabs gesteuert. Drei Werte sind möglich:

• /R – Row order : Reihenfolge basiert auf Zeilen-Layout (links nach rechts, oben nach unten).
• /C – Column order : spalten-orientiert.
• /S – Structure order : Reihenfolge folgt dem Struktur-Baum. Dieser Wert ist für PDF/UA Pflicht.

Mit /Tabs /S übernimmt der Reader die Reihenfolge aus dem Tag-Baum. Damit das funktioniert, müssen Formularfelder im Struktur-Baum überhaupt verankert sein – sonst greift der Reader auf Fallback-Heuristiken zurück, deren Ergebnis nicht steuerbar ist.

Pflichtfelder, Validierung, Fehlermeldungen

Drei WCAG-Erfolgskriterien sind hier besonders relevant:

• 3.3.1 Fehlererkennung: Wird ein Eingabefehler festgestellt, muss er benannt werden – nicht nur farblich markiert.
• 3.3.2 Beschriftungen oder Anweisungen: Pflichtfelder müssen erkennbar sein, bevor das Feld ausgefüllt wird. Allein das Sternchen reicht nicht; eine erklärte Konvention oder die explizite Kennzeichnung „(Pflichtfeld)" im sichtbaren Label sind belastbar.
• 3.3.3 Fehlerempfehlung: Wenn der Fehler textlich beschreibbar ist, muss die Beschreibung kommen – „Bitte das Datum im Format TT.MM.JJJJ eingeben", nicht nur „Fehlerhafte Eingabe".

Auf PDF-Ebene unterstützt die Spezifikation Pflichtfelder über /Ff mit dem Required-Flag (Bit 2 im Field-Flag). Validierung (Format, Wertebereich, Skript) ist in AcroForm möglich, aber Reader-spezifisch in der Unterstützung. Für barrierefreie Formulare ist es deshalb sinnvoll, Fehlermeldungen nicht ausschließlich über Reader-Pop-ups zu transportieren, sondern zusätzlich über sichtbar gestaltete Hinweis-Texte direkt im Layout.

Formulare im Struktur-Baum

PDF/UA verlangt, dass jedes interaktive Element im Struktur-Baum verankert ist. Für Formulare bedeutet das: jedes Form-Widget hat ein entsprechendes /Form -Strukturelement im Tag-Baum, das über eine Object-Referenz mit der Widget-Annotation verbunden ist.

Praxis-Checkliste

Eine schlanke Liste für die Praxis – sie ersetzt kein vollständiges PDF/UA-Audit, schließt aber die häufigsten Lücken:

1. AcroForm verwenden, kein XFA.
2. Pro Feld ein sinnvoller /TU -Eintrag, der mit der sichtbaren Beschriftung übereinstimmt.
3. Radio-Buttons mit geteiltem /T innerhalb einer logischen Gruppe – sonst sind sie unabhängige Felder.
4. /Tabs /S pro Seite: Tab-Reihenfolge aus dem Struktur-Baum übernehmen.
5. Pflichtfelder sichtbar UND semantisch kennzeichnen – die Sternchen-Konvention nur als Zusatz, nicht als alleiniges Mittel.
6. Fehler-Beschreibungen als Text, nicht nur als Farbänderung.
7. Form-Elemente im Struktur-Baum mit Verweis auf die Widget-Annotation; bei Pflichtfeldern Erklärung im /Alt oder direkt in der Feldbeschreibung ( /Contents der Widget-Annotation).
8. Mit echtem Screenreader testen(NVDA + Adobe Reader oder Acrobat) – nicht nur mit Validator-Software. Tools wie PAC oder veraPDF finden viele technische Lücken, aber nicht alle inhaltlichen.

Wer diese acht Punkte konsequent umsetzt, hat den Großteil der typischen Formular-Probleme bereits ausgeräumt – und einen Stand, auf dem ein vollständiges PDF/UA-Audit ohne große Überraschungen durchgeführt werden kann.