<\/p>\n<\/div>\n
Von WCAG to WTF<\/h2>\n
Die meisten meiner Kollegen sind der Meinung, dass wenn man einen Kontrastchecker benutzt, ausreichend gro\u00dfe Schriften verwendet und Funktionsbeschriftungen so gestaltet, dass sie unabh\u00e4ngig von ihrer Farbe erkannt werden, dann hat man zumindest aus Design-Perspektive gen\u00fcgend getan, um das Thema Barrierefreiheit ausreichend zu ber\u00fccksichtigen, um den Rest sollen sich dann die Developer k\u00fcmmern. Ja, der Grossteil der desgin-relevanten WCAG-Richtlinien sind den meisten meiner Kollegen tats\u00e4chlich bekannt und werden auch angewendet. Aber gen\u00fcgt das?<\/p>\n
F\u00fcr mich stellen die WCAG-Richtlinien das unterste Level der erforderlichen Massnahmen dar. Sie wurden in erster Linie mit dem Anspruch entwickelt, messbare und bewertbare Qualit\u00e4tskriterien bereitzustellen, nicht um \u00abBest-Practice-Empfehlungen\u00bb auszusprechen \u2013 das ist ein wesentlicher Unterschied. Ich behaupte, eine Website, die die Konformit\u00e4tsstufe AA der WCAG erf\u00fcllt, ist aus Sicht von Menschen mit Behinderungen noch lange keine gute Website. Gespr\u00e4che mit Betroffenen haben mir dies gezeigt und erkl\u00e4ren, warum es mir so schwerf\u00e4llt, eine Best-Practice-Sammlung zu erstellen.<\/p>\n
<\/p>\n<\/div>\n
Wenn die Richtlinien zur Barrierefreiheit selbst zur Barriere werden<\/h2>\n
Und das ist auch der Grund, warum die WCAG-Richtlinien so schwer verst\u00e4ndlich sind, denn sie sind juristischer Perspektive formuliert worden, was sie extrem schwer anwendbar macht. Ich kenne kaum ein Regelwerk, f\u00fcr das es so viele Hilfs- und Erkl\u00e4r-Websites gibt wie f\u00fcr die WCAG-Richtlinien.<\/p>\n
Anstatt sich nur zu fragen, was die gesetzlichen Mindestanforderungen sind, sollten wir uns fragen, was unseren Nutzern am meisten hilft. Als Accessibility-unerfahrener Designer ben\u00f6tige ich mehr Informationen als das, was gesetzlich vorgeschrieben ist. Die \u00abDeque Web Accessibility Checklist<\/a>\u00bb ist zum Beispiel dabei hilfreich, da sie \u00fcber die WCAG-Richtlinien hinausgeht und auch Best-Practice-Empfehlungen enth\u00e4lt \u2013 klasse!<\/p>\n <\/p>\n<\/div>\n Stellen wir uns vor, wir w\u00fcrden uns als Designer bei der Entwicklung eines Webdesigns ausschliesslich mit gesetzlichen Richtlinien herumschlagen, die wir einhalten m\u00fcssen. Wer glaubt, dass dabei ein gutes \u00abnutzerzentriertes\u00bb Design herauskommt? Ausserhalb der Accessilibty ist jedem Designer klar, dass man Nutzer befragen, Workshops und Nutzertests durchf\u00fchren muss, um eine wirklich gute L\u00f6sung zu entwickeln.<\/p>\n Ich frage nun, wie viele der Websites, die die Konformit\u00e4tsstufe AA der WCAG erreicht haben, tats\u00e4chlich an Menschen mit Behinderungen getestet wurden, wie oft Menschen mit Behinderungen in der Konzeptionsphase befragt oder eingeladen wurden, die L\u00f6sungsans\u00e4tze zu bewerten? Aus meiner pers\u00f6nlichen Erfahrung w\u00fcrde ich sagen, dass nicht einmal bei 5% der Webl\u00f6sungen der Konformit\u00e4tsstufe AA so vorgegangen wurde. In der Regel wurde nur der Fachliteratur oder Experten vertraut, die f\u00fcr Menschen mit Behinderungen sprachen. Ist das wirklich ein nutzerzentrierter Ansatz im Sinne der Gleichstellung oder der Teilhabe aller?<\/p>\n <\/p>\n<\/div>\n Selbst die WCAG-Richtlinien sind kein gutes Beispiel f\u00fcr barrierefreies Design. Sie erf\u00fcllen bestenfalls ihre eigenen formalen, aber unzureichenden Bedingungen.<\/p><\/div>\n <\/p>\n<\/div>\n Es w\u00e4re nicht nur fair, sondern sogar auch aus reinem Eigennutz viel sinnvoller, in der Konzeption alle Nutzer zu ber\u00fccksichtigen und nicht nur die h\u00e4ufigsten oder durchschnittlichen Nutzer, wie es h\u00e4ufig im UX-Research und in Testings gemacht wird.<\/p>\n Sich vorzustellen, wie jemand blind ist, oder besser noch, wie jemand, der blind ist, ein Smartphone benutzt, kann f\u00fcr Sehende eine unl\u00f6sbare Herausforderung darstellen. Menschen ohne Behinderungen k\u00f6nnen sich oft nicht vorstellen, mit welchen Herausforderungen Menschen mit Behinderungen tagt\u00e4glich konfrontiert sind und welche Hilfsmittel wirklich sinnvoll und welche eher \u00fcberfl\u00fcssig sind.<\/p>\n Oft erlebe ich, dass sich unsere Auftraggeber eine Vorlesefunktion (ReadSpeaker, Text-to-Speech, \u2026) auf ihrer Website w\u00fcnschen. Das liegt daran, dass die meisten barrierefreien Webl\u00f6sungen von Menschen OHNE Behinderungen geplant oder konzipiert werden, ohne die Betroffenen zu befragen, sonst w\u00fcrden sie wissen, dass sehbehinderte Menschen diese Funktion nicht mehr ben\u00f6tigen, (siehe beispielsweise hier<\/a>).<\/p>\n Daher ist es wichtig, dass die an einem Accessibility-Projekt beteiligten Designer und Entscheidungstr\u00e4ger wirklich \u00abverstehen\u00bb, was es bedeutet, motorisch behindert, blind oder geh\u00f6rlos zu sein, und welche Hilfestellungen wirklich sinnvoll sind und welche nicht. Andernfalls k\u00f6nnen sie keine nutzerzentrierten L\u00f6sungen entwickeln, die echte Mehrwerte f\u00fcr Menschen mit Behinderungen bieten.<\/p>\n Um dieses empathische Verst\u00e4ndnis zu erlangen, sind Kontakte und Gespr\u00e4che mit Betroffenen, also den eigentlichen Kernzielgruppen von Barrierefreiheitsmassnahmen, unabdingbar. Nur so k\u00f6nnen die Bed\u00fcrfnisse von Nutzern mit Einschr\u00e4nkungen umfassend ber\u00fccksichtigt werden.<\/p><\/blockquote>\nIm Bereich Accessibility folgen wir eher formalen Vorgaben statt Nutzerbed\u00fcrfnissen<\/h2>\n
![\"Website](\"https:\/\/thomas-sokolowski.com\/de\/wp-content\/uploads\/2024\/10\/WCAG.png\")
Ganzheitliche Nutzerperspektive einnehmen<\/h2>\n
![\"das](\"https:\/\/thomas-sokolowski.com\/de\/wp-content\/uploads\/2024\/10\/Logo-Accessibility-Switzerland.png\"){kind=logo}
![\"\"](\"https:\/\/thomas-sokolowski.com\/de\/wp-content\/uploads\/2024\/10\/Barrierefreiheit-Diagramm.png\")
<\/p>\n