Das machte das Formular messenswert. Also machten wir uns auf die Suche nach echten Exemplaren.
Wie selten ein echtes, ausfüllbares PDF-Formular im öffentlichen Sektor tatsächlich ist
Wir begannen mit einer Stichprobe von 111 PDFs aus dem öffentlichen Sektor, die von ungarischen kommunalen Websites stammten. Nicht eines davon enthielt ein ausfüllbares Formularfeld. Neun der 111 enthalten zwar einen /AcroForm-Eintrag mit Widget-Anmerkungen – aber jedes Widget in jedem dieser Dokumente ist ein /Sig-Feld, ein Platzhalter für eine digitale Signatur, nichts, worin eine Person tippen könnte.
Also weiteten wir unsere Suche auf den Crawl aus, aus dem diese 111 stammten: 1.682 ungarische kommunale Websites, 8.469 PDFs. Wir durchsuchten die Dateinamen nach den Wörtern, die eine ungarische Behörde für ein Formular verwendet – kérelem, nyomtatvány, adatlap, bejelentő, űrlap, igénylő – und erhielten 259 verschiedene Dateien, von denen wir 248 herunterluden, eine Anfrage pro Sekunde, wobei wir uns ehrlich identifizierten.
Von diesen 259 Dateinamen waren 74 von unserem Crawler bereits als gescannte Bilder statt als Text markiert worden. Wir konnten 70 davon herunterladen und öffnen: keine davon enthält ein /AcroForm. Ein gescanntes „Formular“ ist ein Foto eines Formulars – es gibt nirgendwo in der Datei ein Feldobjekt, das ein Screenreader oder irgendetwas anderes erreichen könnte. Man druckt es aus, füllt es von Hand aus und schickt es per Post oder scannt es wieder ein. Das ist gut zu wissen, denn das bedeutet, dass sich die Frage der Barrierefreiheit bei fast einem Drittel der Dokumente, deren Dateinamen ein ausfüllbares Formular versprechen, gar nicht erst stellt.
Von den 248 Dateien, die wir tatsächlich öffnen konnten, enthielten vier echte /AcroForm-Widgets, die eine Person ausfüllen kann: insgesamt 272 Felder. Auf diesen vier basiert der Rest dieses Artikels.
Trichter aus dem Crawl ungarischer Kommunal-Websites von 2026. 8.469 PDFs wurden erfasst. Bei 259 Dateinamen deutete der Name auf ein Formular hin. 248 davon ließen sich herunterladen und öffnen. Nur 4 enthielten echte ausfüllbare AcroForm-Widgets mit insgesamt 272 Feldern. Keines der 4 erfüllt PDF/UA-1.
python3 -c "import pikepdf; pdf = pikepdf.open('file.pdf'); print('/AcroForm' in pdf.Root)"
Was ein Screenreader liest und was er niemals lesen wird
Jedes Formularfeld hat einen internen Namen, den /T-Schlüssel – Acrobat benötigt einen, um das Feld im Code anzusprechen, also erfindet es einen, falls der Autor dies nicht tut. Dieser Name ist kein Label, sondern ein Bezeichner, und einige der von uns gefundenen Felder tragen immer noch die Namen, die Acrobats Formularerkennungs-Assistent standardmäßig zugewiesen hat: Check Box1, Check Box3 oder ein bloßes 0 und 1 für ein Paar benachbarter Felder.
Das Feld, das ein Screenreader tatsächlich ansagt, ist ein separater Schlüssel, /TU – der Tooltip. Die eigene Anleitung des W3C dazu ist unverblümt:
"The TU entry (which is the tooltip) of the field dictionary is the programmatically associated label. Therefore, add a tooltip to each field to provide a label that assistive technology can interpret." – PDF10: Bereitstellung von Beschriftungen für interaktive Formularsteuerelemente in PDF-Dokumenten, W3C WAI
Der deutlichste Kontrast in unseren vier Dateien besteht zwischen einer sorgfältig erstellten und einer, die es nicht war. Ein Paar nahezu identischer Anträge für einen geschützten Strom- und Gastarif für Verbraucher – gleiche Vorlage, gleiche Gemeinde, ein Feld für Strom und eines für Gas – tragen einen Tooltip auf 15 ihrer 17 Felder:
/T (interner Name) |
/TU (was angesagt wird) |
|---|---|
fill_2 |
„b) Anschrift (Postleitzahl, Ort, Straße/Weg/Platz, Hausnummer, Treppenhaus, Etage, Tür)“ |
a családi és utóneve |
„a) Familien- und Vorname“ |
(Die ursprünglichen Tooltips sind auf Ungarisch; hier zur besseren Lesbarkeit übersetzt.)
Ein Formular zur Offenlegung von Kommunalsteuerdaten einer anderen Gemeinde hat 123 Widget-Felder – 74 Textfelder und 49 Kontrollkästchen – und keines davon trägt ein /TU. Ein Screenreader landet auf einem Textfeld und kann nur sagen, dass es ein Textfeld ist.
Die Tab-Reihenfolge ist eine separate Einstellung zur visuellen Reihenfolge
Eine Seite in einem PDF hat ihren eigenen /Tabs-Eintrag, und dieser wird nicht daraus abgeleitet, wo sich etwas auf der Seite befindet. Wenn er auf /S gesetzt ist, geht der Reader die Felder in der Reihenfolge durch, in der sie im Strukturbaum erscheinen – die Reihenfolge, in der ein sehender Benutzer die Seite lesen würde. Wenn er nicht gesetzt oder auf /W gesetzt ist, geht er sie in der Reihenfolge durch, in der die Anmerkungen zur Seite hinzugefügt wurden: die Reihenfolge, in der jemand die Kästchen im Formular-Design-Tool gezeichnet hat, nicht die Reihenfolge, in der eine Person von oben nach unten liest.
Zwei unserer vier Dateien setzen /Tabs auf /S auf jeder Seite, die ein Feld enthält. Das Anfrageformular für Erfassungsbögen – 115 Felder auf fünf Seiten – setzt es durchgehend auf /W. veraPDF 1.30.2 (Build 2026-06-03) erkennt genau dies auf allen drei Seiten dieses Formulars, die ein Feld enthalten, gemäß ISO 14289-1 Klausel 7.18.3:
"errorMessage": "A page with annotation(s) contains Tabs key with value W
instead of S"
~/.local/share/verapdf/verapdf -f ua1 --format json Ajanloiv-igenylese.pdf
Der praktische Effekt: Ein Mausbenutzer liest das Formular so, wie es angelegt ist. Ein Tastatur- oder Screenreader-Benutzer auf derselben Seite kann auf Feld vierzehn landen, dann auf Feld drei, dann auf Feld neun, ohne – außer durch Ausprobieren – sagen zu können, ob er das Ende erreicht hat.
Das eine, das fast alles richtig gemacht hat und trotzdem scheiterte
Das Strom- und Gasantragspaar ist das am besten erstellte Formular in unserer Stichprobe: 88 % seiner Felder haben einen brauchbaren Tooltip und seine Tab-Reihenfolge folgt der Struktur. Es wurde außerdem mit Microsoft Word erstellt, und der Export von Word markiert das Dokument als getaggt – StructTreeRoot vorhanden, MarkInfo/Marked wahr, die Markierungen, die ein Validator zuerst prüft.
Wenn man es trotzdem durch veraPDF laufen lässt, schlägt es fehl. Jedes seiner 17 Felder verstößt gegen Klausel 7.18.4: Eine Widget-Anmerkung muss innerhalb eines Strukturelements vom Typ Form verschachtelt sein, und in dieser Datei ist keines davon so angelegt. Wir haben dies unabhängig von veraPDF mit pikepdf direkt am Strukturbaum überprüft: In allen vier Dateien trägt keines der 272 Widgets einen /StructParent-Schlüssel, und der Baum enthält null Objektverweise auf irgendeines von ihnen. Die Tooltips und die Tab-Reihenfolge wurden eindeutig mit Sorgfalt erstellt. Sie stehen neben einer strukturellen Lücke, für die der Formularexport von Word keine Einstellung bietet und die das gewissenhafte Ausfüllen jedes Tooltips nicht schließen kann.
Die anderen beiden Formulare verstoßen bei allen 123 bzw. 115 ihrer Felder ebenfalls gegen dieselbe Klausel. Es ist also nicht so, dass dies passiert, wenn ein Formular nachlässig erstellt wird. Es passiert jedem Formular in unserer Stichprobe – das am besten beschriftete eingeschlossen.
Pflichtfelder und die Fehlermeldung, die niemals kommt
Keines der 272 Felder in den vier Formularen verwendet das required-Flag des Formularfelds – das /Ff-Bit, das ein Validator oder eine assistive Technologie tatsächlich erkennen könnte. Wenn ein Feld obligatorisch ist, ist das einzige Signal das, was das Formular daneben gedruckt hat, normalerweise ein Sternchen, was genau das ist, was das W3C empfiehlt, wenn nichts Besseres verfügbar ist:
"Required fields are implemented using the /Ff entry in the form field's dictionary. ... If errors are found, an alert dialog describes the nature of the error in text. This may be accomplished through scripting created by the author." – PDF5: Kennzeichnung erforderlicher Formularsteuerelemente in PDF-Formularen, W3C WAI
Keines unserer vier Formulare enthält auch dieses Skripting – kein eingebettetes JavaScript, keine Validierungsaktion auf Feldebene in irgendeinem von ihnen. Es gibt also keine Fehlermeldung. Ein Pflichtfeld, das leer gelassen wird, wird nicht markiert; das Formular wird einfach eingereicht oder nicht, und der Antragsteller findet es auf andere Weise heraus, falls er es überhaupt herausfindet.
Der ehrliche Teil: Ein PDF-Formular ist ein schlechtes Medium dafür
Wir verkaufen PDF-Sanierung, daher ist dies nicht das Einfachste zu sagen, aber es ist wahr: Für einen Antragsprozess ist ein HTML-Formular sehr oft das bessere Werkzeug. Ein Browser erzwingt die Tab-Reihenfolge aus dem eigenen DOM der Seite – es gibt keine separate Einstellung, die man falsch machen könnte. required auf einem <input> ist nativ, und der Browser kündigt es an. Ein Label, das mit <label for> gebunden ist, ist kein diskretionärer Tooltip, den ein Autor vor Ablauf der Frist überspringen könnte; lässt man es weg, markieren es die meisten Autorentools vor der Veröffentlichung. Nichts von dem, was wir oben gemessen haben, ist eine Kompetenzlücke, die spezifisch für diese Autoren ist – es ist das Medium, das ihnen mehr Möglichkeiten gibt, es falsch zu machen, ohne ein Äquivalent zu den integrierten Prüfungen eines Browsers, um es zuerst abzufangen.
Das bedeutet nicht, dass jedes PDF-Formular morgen ein HTML-Formular werden sollte. Einige benötigen tatsächlich eine handschriftliche oder qualifizierte Signatur, einen druckbaren Pfad oder eine bestehende Fallmanagement-Pipeline, die auf dem Format aufbaut. Für diese ist ein korrekt erstelltes PDF-Formular – /TU auf jedem Feld, /Tabs auf /S gesetzt, Widgets tatsächlich dort verschachtelt, wo PDF/UA-1 es erfordert – ein echter, erreichbarer Mindeststandard. Es ist nur ein Standard, unter dem alle vier von uns gefundenen Formulare, einschließlich des besten von ihnen, derzeit liegen.
So überprüfen Sie Ihr eigenes PDF-Formular ohne Validator
Adobe Acrobat (Pro und Reader bei einigen Abonnements)
Werkzeuge → Formular vorbereiten. Jedes Feld auf der Seite erhält ein kleines Tag mit seinem internen Namen. Doppelklicken Sie auf ein Feld und öffnen Sie die Registerkarte Allgemein – das Feld Tooltip ist der /TU-Wert. Wenn es leer ist, ist das alles, womit ein Screenreader arbeiten muss: nichts weiter als „Textfeld“ oder „Kontrollkästchen“.
Tab-Reihenfolge, im selben Werkzeug
Rechtsklick auf eine Seitenvorschau → Seiteneigenschaften → Tab-Reihenfolge → Dokumentstruktur verwenden. Wenn diese Option nicht bereits ausgewählt ist, ist die Lesereihenfolge, die ein Screenreader erhält, die Reihenfolge, in der die Felder gezeichnet wurden, nicht die Reihenfolge, in der sie gelesen werden sollen.
Ohne Acrobat
Unser PDF-Barrierefreiheits-Checker meldet dieselben PDF/UA-1-Klauseln wie veraPDF, Feld für Feld, ohne dass etwas installiert werden muss.
Wenn Sie trotzdem ein PDF-Formular veröffentlichen
Überprüfen Sie die Felder, die am häufigsten eingereicht werden, nicht den neuesten Upload – eine Gebührenordnung oder ein Leistungsantrag wird weitaus häufiger geöffnet als das Protokoll der letzten Sitzung. Geben Sie jedem Feld einen echten Tooltip, nicht den internen Namen, den das Formular-Tool ihm zugewiesen hat. Aktivieren Sie die Tab-Reihenfolge der Dokumentstruktur. Und wenn das Formular danach jemals durch einen Komprimierungs- oder „Verkleinern Sie mein PDF“-Schritt gelaufen ist – das allein kann jede dieser Einstellungen in einem einzigen Durchgang löschen, genau wie es alles andere im Strukturbaum löscht.
Wenn Sie die klauselweise Liste für eines Ihrer eigenen Formulare wünschen, geht unser Checker denselben Weg wie veraPDF, und die PDF/UA-Fehlerreferenz erklärt, was jeder Fehler bedeutet und ob er automatisch behebbar ist. Fehlende Titel und nicht eingebettete Schriftarten werden im begleitenden Artikel darüber behandelt, was der Checker von Word übersieht – es lohnt sich, ihn zu lesen, da alle vier unserer Formulare in Word entstanden sind. Für den Standard selbst deckt unser PDF/UA-Leitfaden ab, was Konformität erfordert und warum.
