Barrierefreiheit

Barrierefreiheit ist ein wichtiges Thema. Ich nutze selbst wegen meiner zunehmenden Altersweitsicht gerne 200% Vergrößerung, und ärgere mich, wenn sich Software nicht automatisch anpasst – aber solche Seiten gibt es leider auch (noch) bei mir. Ich arbeite daran. Wenn Ihnen Probleme auffallen die unten nicht genannt sind, dann schicken Sie bitte eine Email an blog@lindenberg.one, und ich werde versuchen zu helfen, indem ich nachbessere oder die Information auf anderem Wege zur Verfügung stelle.

Bereits konsequent auf blog.lindenberg.one umgesetzt sind:

• korrekte Überschriftebenen und Tabellenüberschriften,
• bessere Kontraste, insbesondere bei den Tabellen der verschiedenen Emailsicherheitstests,
• Links zu PDFs sind in den Artikeln und den allermeisten Emails markiert,
• Schwärzungen in den vielen Emails haben aria-descriptions,
• auf jeder Seite gibt es einen Skip-Link.

Korrekt natürlich nur insoweit als ich oder ein Tool das feststellen kann. Der Blog hat den Vorteil, dass er keine Formulare und auch keine Videos enthält, und damit viele Anforderungen gar nicht relevant sind.

Aber natürlich ist nicht alles perfekt. Die folgenden Einschränkungen kenne ich schon:

• Redundante Links sind nicht einheitlich beschriftet. Das ist teilweise technisch bedingt und dafür werde ich eine Lösung finden, zum anderen aber auch durch die Grammatik der deutschen Sprache,
• PDFs sind in aller Regel nicht barrierefrei,
• das zu PDFs gesagte gilt auch für manche Bild-Zitate, z.B. auf Aufsicht – ohne Orientierung? Fehlende alternative Texte werden ergänzt, aber sind noch nicht vollständig. Und wieviel da hinein muss – Feedback willkommen,
• in Tabellen werden aria-describedby und aria-description anscheinend ignoriert,
• die Tastaturnavigation ist nicht auf allen Seiten getestet,
• Youtube links auf Security By Obscurity sind nicht markiert und obendrein sind die Videos nicht mehr öffentlich,
• meine anderen Domänen sind noch nicht barrierefrei.

Zum Testen verwende ich Chrome mit der Erweiterung WAVE und den Screenreader NonVisual Desktop Access (NVDA), sowie diverse Online-Testangebote, die aber nicht alle Seiten erfassen. Das Deutsch des Screenreaders NDVA ist nicht wirklich überzeugend, und warum er immer wieder abbricht ist mir auch unklar – kennt sich jemand damit aus? Und ganz offen, ich sehe was ich tue, bin also abgesehen von der Tastaturnavigation kein guter Tester der Lösung. Selbst wenn die Tools nichts beanstanden – ein echter Nutzer findet wahrscheinlich doch noch Probleme.

Barriere(un)freie PDFs

Grundsätzlich können PDFs natürlich barrierefrei sein, je nachdem mit welchen Tools sie erzeugt werden. Aber die vorhandenen – insbesondere dann, wenn sie geschwärzte Informationen enthalten, sind es nicht, denn die einzig wirklich praktikable und zuverlässige Methode zu schwärzen ist, dass Text in Bilder verwandelt wird. Auch sind viele PDFs nicht von mir, was meine Bearbeitungsmöglichkeiten einschränkt. Mehr dazu weiter unten. PDFs sind daher immer markiert, visuell für die einen, via aria-description für andere (oder strenggenommen noch nicht, denn das Attribut ist noch nicht endgültig standardisiert).

Lebenslauf

Entsteht bisher in Excel. Leider kann man weder in Excel noch in einem anderen Tool die Reihenfolge steuern, in der die Links per Keyboard angesprochen werden. Irgendwann muss der dann wohl mal nach html konvertiert werden.

Briefe

Briefe scanne ich mit einem Epson Flachbettscanner, der dann eine (uralte) Version von Abby Finereader ansteuert, der dann OCR macht, und in den dann erzeugten PDFs gibt es auf jeder Seite ein Image und den erkannten Text. Der erkannte Text ist natürlich prima für die Volltextsuche. Der Rest dann wie bei anderen Dokumenten.

Dokumente

Beim Schwärzen muss man dann sowohl das Image manipulieren als auch die geschwärzten Buchstaben löschen oder ersetzen. Bei größeren Dokumenten nicht praktikabel, da bietet es sich eher an, den gesamten Text zu entfernen und nur die Images zu lassen.

Emails und Protokollauszüge

Zum Schwärzen der Emails habe ich ein eigenes Tool geschrieben, das die Emaildatei (.eml) in Html konvertiert, und dabei einzelne Stellen schwärzen kann. Das Markup der geschwärzten Stellen sieht dann etwa so aus:

Sieht dann so aus: ***** . Die Anzahl der Sterne hängt von der Anzahl der geschwärzten Buchstaben ab. Gelesen wird dann geschwärzter Inhalt – 5 Sterne, und das schwer verständlich. Leider kann man die Sterne nicht weglassen, denn wenn ein Text leer oder unsichtbar ("visibility:hidden") ist, wird leider gar keine Information gelesen. Das Clip macht den Text unsichtbar, ohne dass der Screenreader es versteht, und daher darf der Text dann auch weiß sein um keine Warnung wegen Kontrast zu bekommen. In Protokollauszügen analog, allerdings mit geeigneten CSS-Klassen statt style. Vielleicht bekommen die Emails auch noch ein geeigneteres Stylesheet.

Tabellen und aria-describedby

Ich habe versucht, die Bedeutung der Farben in meinen Tabellen auch vorgelesen zu bekommen, und wollte dazu aria-describedby auf <tr> angeben. Das ignoriert NVDA leider. Und andere Screenreader anscheinend auch, siehe What happens with aria-labelledby, aria-label and aria-describedby on static HTML elements? Auch aria-description funktioniert auf <tr> nicht, es wäre aber auch sehr redundant den Text auf jeder Zelle wiederholen zu müssen. Da bin ich noch etwas ratlos. Dass die Tabellen ohne diese Information nicht barrierefrei sind, kann man gar nicht sagen, denn die Tabelle enthält alle Informationen, die in den Farbcode eingehen. Ich könnte eine extra Spalte damit füllen, aber die verbraucht Platz auch wenn sie nicht gebraucht.

Gelesen wird aria-description zumindest auf <span role="presentation" aria-description="..">. Ich könnte da welche hineingenerieren, nur an welcher Stelle am besten?