♿️Das "Regelwerk PDF/UA"

In dieser Artikelreihe (hier gehts zu Teil 1) möchten wir von einem konkreten Projekt berichten. Wir durften dabei helfen, die Backlist eines Verlages barrierefrei zu machen. Vielleicht interessiert dich ein solches Projekt. Wir haben definitiv viel gelernt und teilen das Gelernte gerne hier im Blog mit dir - zumindest einen Teil davon! ☺️

Regeln helfen

Natürlich gibt es bereits Regeln zu dem Thema "Barrierefreiheit". Was ein "PDF/UA" ist, ist genauso beschrieben wie die Anforderungen des "BFSG". Es gibt das "Matterhorn Protokoll" und der "PAC" gibt dir auch Rückmeldungen, was an deinem PDF nicht passt.

Warum brauch es dann noch ein eigenes Regelwerk für ein Projekt?

Über diese oben genannten "allgemeinen" Regeln, gibt es noch so viele Details in einzelnen Projekten zu regeln.

Viele davon sind natürlich prozessualer Art: "Wer ist für was verantwortlich?", "Woher kommen Metadaten?", und so weiter.

Es gibt aber auch spezifische Details, wie z.B. die Metadaten der PDF/UAs, gerade im Verlagsumfeld. Schreibt der Verlag in das Metadatum <dc:title> den Titel des Buches oder den Kurztitel? Schreibt man in <dc:creator> den Verlagsnamen oder den oder die Autoren? Wo steht der Text, der in das Metadatum <dc:subject> , also "Beschreibung", geschrieben werden soll? Auf welche genaue Formulierung legen die Verlagsjuristen wert im Metadatum <dc:rights>?

Wenn Daten barrierefrei gemacht werden sollen, müssen Lesereihenfolgen festgelegt werden. In großen Projekten wie diesem sind das gerne mehrere Menschen. Da ist es von Vorteil, wenn es Regeln gibt, wie diese Reihenfolge erstellt wird. Zum Beispiel steht auf dem Cover der "Untertitel" aus gestalterischen Gründen auch mal über dem Titel. Wenn der einheitlich aber immer nach dem Titel gelesen werden soll, dann schreibt man das besser in ein Regelwerk.

Welche Objekte sollen unter welchen Umständen zu Artefakten werden? Ein Beispiel wären Barcodes, wenn die entsprechende URL ebenfalls vorhanden ist. Barcodes ohne explizit gezeigte URL bekommen besser die URL als Alternativtext oder ähnliches.

Dann gibt es natürlich wiederkehrende "exotische" Elemente auf Seiten, für die man sich im Vorfeld der Produktion Gedanken machen muss in Bezug auf die barrierefreiheitliche Bearbeitung, damit man nicht immer wieder "das Rad neu erfinden" muss, sondern die Daten einheitlich verarbeitet werden.

Auch die Alternativtexte sollten geregelt sein. Wer erstellt diese, wie werden sie erstellt? Wie lang sollen sie sein; immer ungefähr gleich lang? In einfacher Sprache?

Wenn es wiederholende Symbole oder ähnliches gibt, sollten diese im Regelwerk tabellarisch aufgeführt werden, damit sie immer einheitlichen Alternativtext bekommen.

Dokumentation

Wir haben das Regelwerk in einem Wiki dokumentiert. Dadurch konnte wir alle gemeinsam daran arbeiten; alle Satzkisten-Mitarbeiterinnen und Kunde und Dienstleister. Der Gedanke an ein Word-Dokument, dass per E-Mail verschickt wird und in x Versionen auf 20 Festplatten liegt, lässt mich erschaudern!

Entwicklung

Natürlich startete der Prozess mit einem gemeinsamen Workshop mit dem Kunden. Die Detailarbeit fand dann, unterstützt von umfangreicher Recherchearbeit und Tests in der Satzkiste statt. Dabei wurden Testdaten des Kunden eingehend analysiert. Unterstützung fanden wir beim Dienstleister, der umfangreiche Erfahrungen in solchen Projekten hatte.