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:
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:
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,
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.
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).
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.
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.
Zuletzt geändert am 21.08.2022.
© 2023 Joachim Lindenberg. Diese Seite spiegelt meine persönliche Meinung wieder. Sie stellt keine Rechtsberatung dar. Fragen Sie doch einen Anwalt der sich damit auskennt.