tl;dr
Benutze WAVE und mach' bei
"reduced motion: reduce"
aufwändige Animationen weg.
Wenn bei einem Software-Projekt von "Accessibility" gesprochen wird, meint das meistens folgendes:
Zusätzlich ist es wichtig, bei Webseiten mit aufwändigen Animationen "reduced motion" abzufragen und die Animationen gegebenenfalls abzustellen oder deutlich zu reduzieren.
Einerseits möchte man sich im Chaosumfeld gerne dem "All Creatures Welcome" verschreiben, und bei einem Online-Event schließt das ein, Web-Accessibility mit zu bedenken. Andererseits ist es bei all den selbst entwickelten Projekten oft der Fall, dass ein Admin plötzlich Frontend machen soll und einfach nicht weiß wie Web-Accessibility geht. Um das zu überbrücken gibt es diese, mit Absicht knapp gehaltene, Einführung in Web-Accessibility mit weiterführenden Links am Ende.
Je mehr das, was Du baust, öffentliche Infrastruktur ist, desto mehr
Bedeutung solltest Du Accessibility zumessen. Wenn Deine Webseite nur für
Deine drei Bezugspersonen ist, und diese keine besonderen Bedürfnisse
haben, ist es erstmal nachrangig. Wenn es für alle sein soll, sollten sich
auch alle eingeladen fühlen.
Accessibility nachträglich herzustellen ist aufwändig. Normalerweise ist
es einfacher von Anfang an semantischen Code zu schreiben als
unsemantischen Code später zu refaktorieren.
Natürlich gibt es keine absolute Barrierefreiheit und das erwartet auch
niemand von Dir. Uns ist es wichtig, Dich darüber zu informieren, was
Barrieren sind und, wie Du sie vermeiden kannst.
Wenn Du weißt, dass auf Deiner Webseite etwas stattfindet, das für manche Menschen mit Behinderungen nicht (gut) funktioniert, ist es nicht unbedingt schlimm, aber du solltest es ausweisen. Zum Beispiel könnte an einem Link zu einem Disko-BBB mit Blinklicht dran stehen "Achtung Blinklicht, dieser BBB ist für Epileptiker*innen ungeeignet." So kannst Du mit Deinem Hackerspace Blinklicht-Spaß haben, ohne anderen zu schaden.
"Blinklicht" kann auf dem rC3 auch als Tag gesetzt werden, der zum einen Menschen die Möglichkeit bietet, Inhalte nach diesem Kriterium rauszufiltern. Es freuen sich aber natürlich auch Menschen, die voll auf Blinklicht stehen, weil sie Deine Disko leichter finden können: Viele Optionen für Barrierefreiheit sind unterm Strich praktisch für alle Menschen.
Dein Angebot sollte gut verständlich sein.
Vermeide übermäßig komplizierte Sätze und schwammige Formulierungen, und
strukturiere Deine Informationen optisch passend zum Inhalt, so dass man
das Gesuchte schnell finden kann. Für lange Fließtexte solltest Du ein
tl;dr schreiben.
Menschen ohne Behinderungen sei folgendes Bild mitgegeben: Deine Webseite
oder App sollte auch benutzbar sein, wenn man betrunken ist, oder einen
Unfall hatte. Davon profitieren besonders Menschen, die schlecht lesen
können oder die gerade überfordert sind.
Für verschiedene besondere Bedürfnisse kann Text auf verschiedene Weise
zugänglich gemacht werden, zum Beispiel mit einer
Braillezeile. Das
funktioniert aber nur wenn die Information auch als Text vorliegt.
Achte darauf dass Grafiken
einen beschreibenden Alt-Text
enthalten. Codebeispiel:
<img src="koelner-dom.jpg" alt="Der Kölner Dom im Abendlicht.">Wenn es möglich ist, mache Untertitel zu Deinen Videos und veröffentliche Podcast-Scripte. Das verbessert auch die Durchsuchbarkeit.
Damit ein Screenreader die Webseite gut verständlich vorlesen kann, ist es bei Links wichtig, dass der Teil des Satzes, der den Link trägt, wörtlich das sagt, wohin gelinkt werden soll. Zum Beispiel:
ist gut und
ist nicht gut.
Es gibt Menschen die sich aus den verschiedensten Gründen mit etwas nicht auseinandersetzen können oder wollen. Die rC3-Plattform bietet diesen Menschen daher die Möglichkeit, bestimmte Tags zu filtern, damit sie mit diesen auf dem Event nicht unerwartet konfrontiert werden. Bitte sei also fleißig beim Taggen und erwähne Themen, die für manche potentiell schwierig sein könnten.
Am Anfang eines Beitrags den Inhalt durch Content Notes zu beschreiben,
ist eine gute Möglichkeit.
Beispiel für eine blinkende Disko, die vom C3WOC ausgerichtet wird:
Für viele Menschen ist es wichtig, dass der Kontrast zwischen Schrift und Hintergrund groß genug ist. 100% schwarz auf 100% weiß ist aber auch nicht die ideale Lösung. Für optimale Lesbarkeit wird ein Mindest-Farbkontrast von 7:1 empfohlen, wie er auf dieser Webseite verwendet ist. Sprich: der Text, den Du jetzt liest, hat den Mindestkontrast, der für Web-Accessibility empfohlen wird.
Der Kontrast zwischen Schrift und Hintergrund muss durch die Helligkeit realisiert werden, nicht durch den Farbton. Zu Beginn der Farbplanung solltest Du dir überlegen: was soll es werden, hell auf dunkel oder dunkel auf hell? Und: nein, rot auf blau geht wirklich nicht.
Hervorragend wäre es, ein Dark-Theme und ein Light-Theme anzubieten, verschiedene Menschen haben da verschiedene Bedürfnisse und Vorlieben. Hierfür gibt es auch Browserflags, die zum automatischen selektieren genutzt werden können.
Codebeispiel:
body {
line-height: 1.5;
font-family: "Open Sans", "Roboto", Helvetica, sans-serif;
background: white;
color: #595959;
}
a {
text-decoration: none;
color: #0059b3;
}
a:hover,
a:focus {
text-decoration: underline;
}
@media (prefers-color-scheme: dark) {
body {
background: #353535;
color: #c3c3c3;
}
a {
color: #7accff;
}
}Im frühen Planungsstadium einer Webseite oder App möchte man für gewöhnlich Farben festlegen. Damit Du sicher gehen kannst dass der Farbkontrast passt, bietet sich ein Farbkontraste-Tester zum Ausprobieren an.
Bei Farbverläufen und Hintergrundbildern ist Vorsicht geboten. Es ist da
generell schwierig zu gewährleisten, dass wirklich die komplette Schrift
auf allen Geräten mit hinreichend Kontrast dargestellt wird. Das heißt
nicht, dass Accessibility und Hintergrundbilder generell unverträglich
sind, man sollte es "nur" besonders penibel testen. Und da das bei dem
durchschnittlichen Open-Source-Project niemand tut, bist du in der Regel
besser damit bedient, den Text auf einfarbigen Hintergrund zu setzen.
Auf bewegliche Darstellungen hinter einem Text solltest Du generell
verzichten, außer bei dem Text handelt es sich um Untertitel.
Die Schriftgröße sollte nicht zu klein sein. Außerdem ist es wichtig, dass die Schriftgröße im Browser verstellbar ist bzw. dass man in der Webseite zoomen kann.
"Semantischer Code" bedeutet, dass die Elemente entsprechend ihrer inhaltlichen Bedeutung ausgezeichnet sind.
Folgender Code:
<form>
<p>Was ist Dein Lieblingssaal?</p>
<fieldset>
<input type="radio" id="mc" name="Saal" value="Ada" />
<label for="mc"> Ada</label>
<input type="radio" id="vi" name="Saal" value="Borg" />
<label for="vi"> Borg</label>
<input type="radio" id="ae" name="Saal" value="Clarke" />
<label for="ae"> Clarke</label>
<input type="radio" id="dj" name="Saal" value="Dijkstra" />
<label for="dj"> Dijkstra</label>
<input type="radio" id="el" name="Saal" value="Eliza" />
<label for="el"> Eliza</label>
</fieldset>
</form>
resultiert in:
und folgender Code:
<form>
<fieldset>
<legend>Was ist Dein Lieblingssaal?</legend>
<input type="radio" id="mc" name="Saal" value="Ada" />
<label for="mc"> Ada</label>
<input type="radio" id="vi" name="Saal" value="Borg" />
<label for="vi"> Borg</label>
<input type="radio" id="ae" name="Saal" value="Clarke" />
<label for="ae">Clarke</label>
<input type="radio" id="dj" name="Saal" value="Dijkstra" />
<label for="dj"> Dijkstra</label>
<input type="radio" id="el" name="Saal" value="Eliza" />
<label for="el"> Eliza</label>
</fieldset>
</form>
resultiert in:
Optisch ist der Unterschied gering (und kann selbstverständlich mit CSS
gestylt werden). Semantisch jedoch ist es unterschiedlich. Die Frage "Was
ist Dein Lieblingssaal?" ist kein eigener Absatz (<p>)
sondern direkt zum Fieldset gehörig und sollte als Legende
(<legend>) ausgezeichnet sein, weil Screenreader das
dann als zusammengehörig interpretieren.
HTML5 ist wunderbar dafür
geeignet, viele dieser Dinge "ganz von selbst" richtig zu machen.
Im richtigen Leben hat aber kaum jemand alle HTML-Tags im Kopf. Glücklicherweise ist das kein Problem, denn wenn man die Grundlagen verstanden hat, kann man sich sehr gut mit Accessibility-Audit-Tools behelfen, zum Beispiel WAVE. Es weist auf die meisten der Probleme hin und diese sind dann auch meist schnell zu beheben.
Wenn Deine Webseite mit deaktiviertem CSS immer noch verständlich ist, hast du viele Sachen richtig gemacht.
Es gibt eine Systemeinstellung "weniger Bewegung", die je nach Betriebssystem unterschiedlich heißt aber betriebssystem-übergreifend mit einem Media-Query abgefragt werden kann. Dieser nennt sich "prefers-reduced-motion" und ist hier gut beschrieben. Vermeide oder reduziere Animationen in dem Fall, dass jemand "weniger Bewegung" aktiviert hat.
Codebeispiel:
.myDiv {
transition: all ease 0.6s;
}
.myDiv:hover {
transform: scale(1.05)
rotate(0.5deg);
}
@media (prefers-reduced-motion: reduce) {
.myDiv:hover {
transform: scale(1)
rotate(0deg);
}
}