Diese Frage wird in einem englischsprachigen Weblog gestellt. Darauf gibt es eine recht eindeutige Antwort. Nein, es sei denn, die Website wird prim\u00e4r von Blinden und Screenreader-Nutzern aufgesucht.
\nBis heute verwechseln viele Webdesigner und Frontend-Entwickler Barrierefreiheit mit blindenfreundlich. Das ist teilweise berechtigt: Menschen mit motorischen Einschr\u00e4nkungen verwenden oft die Tastatur statt der Maus, so dass sie \u00e4hnlich wie Blinde durch eine Website tabben. Andererseits: wenn jemand aus motorischen Gr\u00fcnden keine Maus benutzen kann, wird er wohl auch Schwierigkeiten haben, eine Tastatur zu bedienen.
\nDas wird vor allem dann relevant, wenn man wie bei Access-Keys \u00fcblich zwei oder drei Tasten gleichzeitig dr\u00fccken muss, um eine Aktion auszul\u00f6sen oder einen seiteninternen Bereich anzuspringen. \u00dcbrigens k\u00e4me wohl kein webdesigner auf die Idee, einem sehenden Nutzer so eine Akrobatik aufs Auge zu dr\u00fccken.
\nBei dem Thema Barrierefreiheit bleiben vor allem Menschen mit Lernschwierigkeiten und geringen Internet-Erfahrungen komplett au\u00dfen vor. Sie werden von der Vielzahl an Elementen gest\u00f6rt, sie wissen oft nicht, was anklickbar ist und was nicht und h\u00e4ufig genug ist die Navigation von Marketing- statt von Usability-Aspekten gepr\u00e4gt.
\nAn dieser Stelle laufen Usability- und Accessibility eindeutig zusammen. Allerdings haben sich Usability-Tests – mehr oder weniger – fest etabliert, w\u00e4hrend man Zug\u00e4nglichkeitstests mit Nutzern bisher kaum findet.
\nIch frage mich allerdings auch, was einen Webdesigner oder Frontend-Entwickler zum Zug\u00e4nglichkeits-Guru qualifiziert. Die Lekt\u00fcre der BIT-V und der WCAG ist zwar langatmig, aber sicher nicht ausreichend. Und hier kommen wir zum Ausgangspunkt zur\u00fcck: Nicht jede Website sollte mit einem Screenreader getestet werden, aber der Webworker sollte zumindest einmal intensiver mit einem Screenreader (und anderen Zug\u00e4nglichkeitstechniken) gearbeitet haben.
\nWir m\u00fcssen es zugeben: die WCAG ist sch\u00f6n und gut, aber f\u00fcr den arglosen Leser total unverst\u00e4ndlich. Er versteht nicht, warum \u00dcberschriften als HTML-Headline umgesetzt werden sollen, warum Formularlemente Labels brauchen und warum jeder Winkel der Seite mit der Tastatur erreichbar sein soll. Und wenn der Webworker nicht praktische Erfahrungen mit Hilfstechniken sammelt (und frisch h\u00e4lt), wird er vermutlich sein Pflichtprogramm abspulen, aber ohne Phantasie und Interesse. Denn er wei\u00df, dass er etwas Bestimmtes tun muss, er kann aber nicht nachvollziehen, warum er es tun soll. So kommen Webseiten mit einem Dutzend Sprungankern am Anfang der Seite zustande, deshalb werden unsinnige Access-Keys generiert und deshalb sehen viele – vorgeblich – barrierefreie Websites so aus, als ob sie auf einem 14-Zoll-Schwarzwei\u00df-Monitor kreiert wurden. <\/p>\n","protected":false},"excerpt":{"rendered":"
Diese Frage wird in einem englischsprachigen Weblog gestellt. Darauf gibt es eine recht eindeutige Antwort. Nein, es sei denn, die Website wird prim\u00e4r von Blinden…<\/p>\n