Richt­li­ni­en-kon­form oder bar­rie­re­frei?

In Deutsch­land gilt die Bar­rie­re­freie In­for­ma­ti­ons­tech­no­lo­gie Ver­ord­nung (BITV). Aber be­deu­tet richtlinienkonform gleich bar­rie­re­frei? Lei­der nein. Ein In­ter­net­auf­tritt kann richtlinienkonform sein und trotz­dem mas­si­ve Bar­rie­ren auf­wei­sen – die Richt­li­nie

SCREENGUIDE - - Inneres - TEXT: Jörg Mors­bach

War­um WCAG und BITV nur Min­dest­an­for­de­run­gen dar­stel­len

Wer sich mit dem The­ma Bar­rie­re­frei­heit im In­ter­net be­schäf­tigt, kommt an den WCAG 2.0 (Web Con­tent Ac­ces­si­bi­li­ty Gui­de­li­nes) des W3C nicht vor­bei. In Deutsch­land gilt zwar die re­la­tiv kom­pakt for­mu­lier­te BITV 2.0, der grund­sätz­li­che Auf­bau der BITV wur­de aber von den WCAG über­nom­men [goo.gl/Aqm­wx6]. Der weit­aus grö­ße­re Teil der WCAG hin­ge­gen – Er­läu­te­run­gen, Emp­feh­lun­gen, Tech­ni­ken, Bei­spie­le, Glos­sar, wei­ter­füh­ren­de Quel­len und kon­kre­te Failu­res (Ver­stö­ße) – wur­de nicht über­nom­men. Wo­bei das auch gut ist, denn die­ser um­fang­rei­che­re Part der WCAG ent­wi­ckelt sich stän­dig wei­ter, wes­halb er auch (bis auf die ex­pli­zi­ten Richt­li­ni­en und Failu­res) keinen rechts­ver­bind­li­chen, nor­ma­ti­ven Cha­rak­ter hat. Al­ler­dings gibt es die er­wei­ter­ten In­for­ma­tio­nen nur auf Eng­lisch, was an sich schon ei­ne Bar­rie­re ist – und in der Rea­li­tät un­ter Ex­per­ten tat­säch­lich zu mas­si­ven Dis­kus­sio­nen führt, was im Ein­zel­fall genau ge­meint ist. Dass die ge­sam­mel­ten Do­ku­men­te der WCAG ein Mo­loch sind, ist üb­ri­gens schon seit Jah­ren be­kannt. Be­reits 2006 do­ku­men­tier­te Joe Clark in ei­nem Ar­ti­kel bei „A List Apart” den da­mals schon be­acht­li­chen Ge­samt­um­fang der WCAG von 450 US-Let­ter-Sei­ten [goo. gl/N2TeJ3]. Über zehn Jah­re spä­ter hat sich der Um­fang deut­lich er­wei­tert. Zu­mal ge­ra­de schon an der WCAG 2.1 ge­ar­bei­tet wird, die sich ak­tu­ell im – zur Kom­men­tie­rung frei­ge­ge­be­nen – Ent­wurfs­mo­dus be­fin­det.

WCAG A – AAA (TRIPLE-A)

Aber von vorne: Die WCAG kennt drei Kon­for­mi­täts­stu­fen. Die BITV kennt nur zwei Kon­for­mi­täts­stu­fen, weil die Stu­fen A und AA (Dou­ble-A) der WCAG in der BITV zu Prio­ri­tät 1 zu­sam­men­ge­fasst wur­den. Prio­ri­tät 2 ent­spricht hin­ge­gen im Prin­zip Triple-A der WCAG. Das ist ins­be­son­de­re wich­tig, weil die BITV zur Er­fül­lung

der Richt­li­ni­en eben auf die um­fas­sen­de Do­ku­men­ta­ti­on der WCAG ver­wei­sen. Die WCAG er­mög­li­chen ei­ne Kon­for­mi­tät auf drei Stu­fen, die auch un­ab­hän­gig von­ein­an­der er­reicht wer­den kön­nen. Die WCAG er­laubt al­so bei­spiels­wei­se auch die Kenn­zeich­nung ei­ner Web­sei­te als WCAG-A kon­form. Ei­ne der­ar­ti­ge Ab­stu­fung sieht die BITV nicht vor. Mehr noch, die BITV for­dert zu­sätz­lich für „zen­tra­le Na­vi­ga­ti­ons- und Ein­stiegs­sei­ten” die Er­fül­lung der Richt­li­ni­en der Prio­ri­tät 2 – sprich WCAG Tri­pleA. Das klingt streng, springt aber viel­fach trotz­dem zu kurz. Vor al­lem, wenn man mal ziel­grup­pen­spe­zi­fi­sche An­ge­bo­te, wie Ge­bär­den­sprach­vide­os und In­hal­te in „Leich­ter Spra­che” aus der Be­trach­tung raus­lässt. Kling al­les ver­wir­rend. Und wenn Sie die Be­grün­dung des Bun­des­mi­nis­te­ri­ums für Ar­beit und So­zia­les (BMAS) zur BITV zu­sätz­lich zu­ra­te zie­hen [goo.gl/jde­qwS], kön­nen ver­mut­lich nur noch Ju­ris­ten wei­ter­hel­fen: „Bei zen­tra­len Na­vi­ga­ti­ons- und Ein­stiegs­an­ge­bo­ten sol­len – vor­be­halt­lich ih­rer tech­ni­schen Rea­li­sier­bar­keit – zu­sätz­lich die Stan­dards mit der Prio­ri­tät 2 ein­ge­hal­ten wer­den. Zen­tra­le Na­vi­ga­ti­ons- und Ein­stiegs­an­ge­bo­te (so­ge­nann­te Por­ta­le) sind We­b­an­ge­bo­te, die in ers­ter Li­nie kei­ne ei­ge­nen In­hal­te an­bie­ten, son­dern zweck­ge­rich­tet auf frem­de In­hal­te ver­wei­sen bzw. wäh­rend der Nut­zung zu den ge­such­ten In­hal­ten füh­ren.” In der gän­gi­gen Pra­xis gel­ten als zen­tra­le Na­vi­ga­ti­ons­und Ein­stiegs­sei­ten vor al­lem Start­sei­ten und Sei­ten der ers­ten Na­vi­ga­ti­ons­ebe­ne. Das al­ler­dings vor al­lem in Be­zug auf die Fra­ge, für wel­che Sei­ten ei­gent­lich In­hal­te in Leich­ter Spra­che und In­hal­te in Ge­bär­den­spra­che be­reit­ge­stellt wer­den müs­sen. Ob das ei­ne kor­rek­te In­ter­pre­ta­ti­on der BITV ist, müss­ten im Zwei­fels­fall Ju­ris­ten klä­ren.

ES SIND NUR RICHT­LI­NI­EN

Klar ist, die WCAG (und die BITV) sind kein Al­ma­nach al­ler er­denk­li­chen di­gi­ta­len Bar­rie­ren und de­ren Be­he­bung. Da­zu sind die Bar­rie­ren im Web zu viel­fäl­tig: Das Feh­ler­po­ten­zi­al durch kör­per­li­che (geis­ti­ge und emo­tio­na­le) Nut­zer-Ein­schrän­kun­gen in Kom­bi­na­ti­on mit ver­al­te­ter oder nicht stan­dard­kon­for­mer Hard­und Soft­ware ist ein­fach zu groß. Trotz­dem hängt der WCAG Kri­tik an, Bar­rie­ren nicht in ers­ter Li­nie aus Nut­zer­sicht zu iden­ti­fi­zie­ren, son­dern aus tech­ni­scher Sicht. Auch wenn die WCAG an sich Tech­no­lo­gie-Un­ab­hän­gig­keit an­strebt. Es gibt Ex­per­ten, wie den be­reits ein­gangs er­wähn­ten Joe Clark, die be­haup­ten, dass die WCAG sich stark auf Aspek­te kon­zen­trie­ren, die durch tech­ni­sche Prüf­tools er­fass­bar und be­wert­bar sind. Ob dem so ist, sei da­hin­ge­stellt. Der Fach­be­reich Com­pu­ter Sci­ence der Uni­ver­si­ty of York hat zu­min­dest in ei­ner Stu­die mit 32 blin­den Pro­ban­den her­aus­ge­fun­den, dass fast 50 Pro­zent der Pro­ble­me, mit de­nen Pro­ban­den der Stu­die zu kämp­fen hat­ten, von den WCAG-Richt­li­ni­en über­haupt nicht ab­ge­deckt wer­den [goo.gl/KzAmKe]. So hat­ten die blin­den Pro­ban­den un­ter an­de­rem mas­si­ve Pro­ble­me mit: • In­hal­ten auf Sei­ten, wo er nicht er­war­tet wur­de • feh­len­dem In­halt auf Sei­ten, wo er er­war­tet wur­de • zu lan­gen La­de­zei­ten • In­halt in nicht zu­gäng­li­chen For­ma­ten (i.d.R. PDF) • zu kom­ple­xer In­for­ma­ti­ons­ar­chi­tek­tur • ka­put­ten Links Nun lässt sich ar­gu­men­tie­ren, dass in den meis­ten Fäl­len nicht nur be­hin­der­te Men­schen (hier blin­de Men­schen) durch die ge­nann­ten Pro­ble­me be­ein­träch­tigt wer­den. Nicht we­ni­ge Ex­per­ten ver­wei­sen bei der­ar­ti­gen Pro­ble­men auf die Dis­zi­pli­nen Usa­bi­li­ty, User Ex­pe­ri­ence und Web-Per­for­mance. Al­ler­dings wird da­bei au­ßer Acht ge­las­sen, dass die ge­nann­ten Pro­ble­me für Ot­to-Nor­mal-User in der Re­gel le­dig­lich läs­tig sind. Für man­che Men­schen mit Be­hin­de­rung füh­ren sol­che Pro­ble­me aber ge­ge­be­nen­falls zu Ver­zweif­lung und Ori­en­tie­rungs­lo­sig­keit. Die­ser Tat­sa­che ist sich die WCAG auch be­wusst [goo.gl/GTwyrf]. Trotz­dem ver­weist sie in ih­rer Ein­lei­tung zur Er­läu­te­rung der Tech­ni­ken auf ge­ne­rel­le Usa­bi­li­ty-Richt­li­ni­en: „Es gibt vie­le grund­sätz­li­che Usa­bi­li­ty­Richt­li­ni­en, die Con­tent für al­le Men­schen bes­ser nutz­bar ma­chen, in­klu­si­ve Men­schen mit Be­hin­de­rung. Wie dem auch sei, in den WCAG 2.0 wer­den nur sol­che Richt­li­ni­en auf­ge­nom­men, die ex­pli­zit Pro­ble­me von Men­schen mit Be­hin­de­rung adres­sie­ren” [goo.gl/63oZ8V]. Bar­rie­re­frei­heit ist al­so tat­säch­lich nicht gleich­zu­set­zen mit WCAG und BITV. Es gibt ein­fach Bar­rie­ren, für die es keinen äqui­va­len­ten Prüf­schritt in den bei­den ge­nann­ten Richt­li­ni­en gibt. So gibt es bei­spiels­wei­se auch kei­ne rechts­ver­bind­li­chen Vor­ga­ben in Be­zug auf Schrift­art, Schrifts­tär­ke, Ver­sal­schrift und der­glei­chen mehr. Das Bei­spiel in Ab­bil­dung 1 lässt sich nicht über die BITV oder WCAG ne­ga­tiv ab­wer­ten, ob­wohl die Bar­rie­re of­fen­sicht­lich ist.

BE­KANN­TE PRO­BLE­ME

Die WCAG sind ein le­ben­di­ger Stan­dard, der auf der ei­nen Sei­te ver­sucht Tech­no­lo­gie-un­ab­hän­gig zu sein, auf der an­de­ren Sei­te aber stets mit der neu­es­ten Tech­nik mit­hal­ten muss. Viel­leicht war der ur­sprüng­li­che Wunsch nach voll­stän­di­ger Tech­no­lo­gie­un­ab­hän­gig­keit ein Kon­zep­ti­ons­feh­ler. De­fi­nier­ba­re Bar­rie­ren ent­ste­hen im­mer an der Schnitt­stel­le zwi­schen Mensch und Ma­schi­ne. Auf der ei­nen Sei­te der Mensch in all sei­ner Viel­falt (mit und oh­ne Be­hin­de­rung, mit und oh­ne Er­fah­rung). Auf der an­de­ren Sei­te die Hard­ware (Bea­mer, Smart-TV, Desk­top-PC, Lap­top, Ta­blet, Smart­pho­ne, Smart­watch, Mou­se, Tas­ta­tur, Braille­zei­le etc.) und die Soft­ware (Be­triebs­sys­tem und Ein­stel­lun­gen, Brow­serVer­sio­nen, Browser-Ein­stel­lun­gen und Plug­ins so­wie As­sis­ti­ve Tech­no­lo­gi­en wie Screen­re­a­der, Sprach­ein­ga­be, Ver­grö­ße­rungs­soft­ware und der­glei­chen mehr). In die­ser Kon­stel­la­ti­on der ge­fühlt un­end­li­chen Viel­falt wä­re ei­ne Kon­zen­tra­ti­on auf rei­ne Web­tech­ni­ken mit ei­nem ein­deu­ti­gen Be­kennt­nis zu HTML als Grund­la­ge si­cher­lich ei­ne Er­leich­te­rung für die Richt­li­ni­en ge­we­sen. Es ist so schon schwer ge­nug, die Pro­ble­me ein­zu­gren­zen und dem rich­ti­gen Ver­ur­sa­cher zu­zu­ord­nen. Denn ei­ne De­tail­lö­sung kann in al­len Be­lan­gen WCAG-kon­form, aber in ei­ner be­stimm­ten Hard- und Soft­ware-Kon­stel­la­ti­on voll­kom­men un­zu­gäng­lich sein, wie bei­spiels­wei­se ei­ne ak­tu­el­le Un­ter­su­chung der

Screen­re­a­der-Un­ter­stüt­zung von emp­foh­le­nen WCAG-Tech­ni­ken zeigt [goo.gl/CgRfNW]. Bei­spiels­wei­se funk­tio­niert das At­tri­but aria-de­scri­bed­by auf ei­nem a-Link in der Kom­bi­na­ti­on In­ter­net Ex­plo­rer und Screen­re­a­der Win­dows-Eyes oder JAWS nicht (je­weils ak­tu­ells­te Ver­si­on und Stan­dard­ein­stel­lun­gen). Aber nicht im­mer sind nicht stan­dard­kon­for­me As­sis­ti­ve Tech­no­lo­gi­en schuld. Und wie schwie­rig es ist, Pro­ble­me zu­zu­ord­nen, zeigt das Wi­ki der Web-Ac­ces­si­bi­li­ty-Initia­ti­ve des W3C, in dem al­le The­men und Pro­ble­me ge­sam­melt, dis­ku­tiert und für zu­künf­ti­ge WCAG-Up­dates vor­be­rei­tet wer­den [goo.gl/jd­jshv]. Oft geht es da­bei um De­tails in der For­mu­lie­rung oder um die An­pas­sun­gen in Be­zug auf die Zu­ord­nung zu Kon­for­mi­täts­le­vels. Bei­spiels­wei­se wenn es um zeit­ver­zö­ger­te Pop-ups geht („3.2.5 Chan­ge on Re­quest” und „2.2.4 In­ter­rup­ti­ons”, bei­des nur WCAGAAA, was aber für Screen­re­a­der-Nut­zer so pro­ble­ma­tisch ist, dass es in WCAG-AA ge­hört). Und auch die fast 200 Ein­trä­ge um­fas­sen­de Is­sue-Lis­te der WCAG 2.1 Re­view auf Git­hub zeigt, wie kom­plex das The­ma ist [git­hub.com/w3c/wcag21] – vor al­lem, wel­che tech­ni­schen Lö­sun­gen der­zeit noch nicht von der WCAG er­fasst wer­den, aber un­um­strit­ten zu Pro­ble­men füh­ren kön­nen (bei­spiels­wei­se Icons-Fonts und CSS-Con­tent all­ge­mein). Aber auch ein Blick in die WCAG-Emp­feh­lun­gen zu ver­schie­de­nen Richt­li­ni­en of­fen­bart, dass es noch ei­ni­ge Bau­stel­len gibt, die de­fi­ni­tiv ge­schlos­sen sein soll­ten. Man­che Emp­feh­lun­gen sind ver­al­tet, wie: • 1.3.1 Ver­wen­den Sie CSS an­statt Ta­bel­len für das Sei­ten­lay­out • 1.4.0 Set­zen Sie gra­fi­schen Text min­des­tens auf 14pt Grö­ße • 2.1.1 Ver­wen­den Sie XHTML ro­le, sta­te und va­lue At­tri­but • 2.4.1 Stel­len Sie Ac­cess Keys be­reit • 2.4.2 Ver­wen­den Sie be­schrei­ben­de Na­men für Fra­mes An­de­re soll­ten ei­gent­lich kei­ne Emp­feh­lung dar­stel­len, son­dern min­des­tens ein Er­folgs­kri­te­ri­um: • 1.4.0 Ver­wen­den Sie les­ba­re Schrift­ar­ten • 1.4.0 Sor­gen Sie für ei­nen gut sicht­ba­ren Fo­kus • 2.4.0 Be­gren­zen Sie die An­zahl der Links pro Sei­te • 2.4.1 Stel­len Sie Skip-Links be­reit • 3.2.1 Neue Fens­ter und Tabs nur öff­nen, wenn not­wen­dig

VIER PRINZIPIEN

Ur­sprüng­lich hat­te die WCAG das Ziel, das The­ma Bar­rie­re­frei­heit so weit run­ter­zu­bre­chen, dass man je­des Pro­blem auf der Ba­sis von vier Prinzipien be­wer­ten kön­nen soll­te. Die vier Prinzipien, das ist die so­ge­nann­te POUR-Re­gel, lau­ten: • Per­ceiva­ble (wahr­nehm­bar) • Ope­ra­ble (be­dien­bar) • Un­der­stan­da­ble (ver­ständ­lich) • Ro­bust (Tech­no­lo­gie-un­ab­hän­gig) Un­ter der An­nah­me, dass sich die­se vier Prinzipien kon­kret auf Stan­dard-kon­for­mes und struk­tu­rier­tes HTML be­zie­hen, das mit CSS und Ja­vaS­cript ge­stal­tet und mo­du­liert wer­den kann, wä­re die Be­wer­tung der vier Prinzipien re­la­tiv ein­fach. Dann bräuch­te man sich kei­ne Ge­dan­ken dar­über zu ma­chen, ob nach­fol­gen­de An­for­de­run­gen Richt­li­ni­en, Emp­feh­lun­gen oder so­gar Failu­res im Sin­ne von ei­nem der drei Kon­for­mi­täts­le­vel der WCAG sind oder ob sie dort über­haupt noch kei­ne Er­wäh­nung fin­den.

BEST PRACTICE REICHT NICHT

Bei der nach­fol­gen­den Auf­lis­tung han­delt es sich um Aspek­te, die in der BITV 2.0 Prio­ri­ät 1 in der Form nicht bzw. erst in den An­for­de­run­gen der Prio­ri­tät 2 ent­hal­ten sind. Für man­che Aspek­te, wie Pro­gres­si­ve En­han­ce­ment, gibt es in der BITV und der WCAG kein Äqui­va­lent, das über ei­ne Emp­feh­lung im Sin­ne ei­nes „Best Practice” hin­aus­ge­hen wür­de. „Best Practice” ist aber nicht an über­prüf­ba­re Kon­for­mi­täts­stu­fen und Richt­li­ni­en ge­kop­pelt.

• Je­de bar­rie­re­freie We­b­an­wen­dung soll­te so­wohl an ei­nem Desk­top-PC mit Stan­dard­tas­ta­tur als auch an ei­nem mo­bi­len End­ge­rät (Smart­pho­ne, Ta­blet) mit ex­ter­ner Tas­ta­tur über Stan­dard-Tas­ta­tur­be­feh­le aus­nahms­los be­dien­bar sein. Tas­ta­tur­steue­rung ist nicht nur für blin­de Men­schen wich­tig, son­dern auch für Men­schen, die ei­ne Com­pu­ter­maus als Ein­ga­be­ge­rät nicht ver­wen­den kön­nen. • Je­de bar­rie­re­freie We­b­an­wen­dung soll­te ei­nen gut sicht­ba­ren und kon­trast­rei­chen Tas­ta­tur­fo­kus be­sit­zen, der über die Browser-De­fault­wer­te hin­aus­geht und den An­for­de­run­gen für Text­kon­trast der WCAG ent­spricht. Vor al­lem stark seh­be­hin­der­te Men­schen ha­ben gro­ße Pro­ble­me mit dem kaum sicht­ba­ren Fo­kus. Noch schlech­ter ist es üb­ri­gens, wenn der Browser-De­fault­wert un­ter­drückt wird, so­dass ge­ge­be­nen­falls über­haupt kein Tas­ta­tur­fo­kus mehr sicht­bar ist. Ein Phä­no­men, das häu­fig durch so­ge­nann­te Browser-Re­sets ver­ur­sacht wird. Ein Ne­ga­tiv-Bei­spiel da­für ist die Sei­te fo­cus.de (Abb. 3). • Ei­ne bar­rie­re­freie We­b­an­wen­dung be­inhal­tet die Be­reit­stel­lung von In­for­ma­tio­nen über den Stand­ort ei­nes Be­nut­zers in­ner­halb ei­ner Web­site (Brot­kru­men­pfad, Si­te­map, Kenn­zeich­nung des ak­ti­ven Na­vi­ga­ti­ons­punk­tes, ver­steck­te Hil­fe­tex­te für Screen­re­a­der). Das ist zwin­gend not­wen­dig, nicht nur für blin­de Men­schen, son­dern auch für Men­schen mit Ori­en­tie­rungs­schwie­rig­kei­ten. • Ei­ne bar­rie­re­freie We­b­an­wen­dung er­laubt Be­nut­zern die Kon­trol­le über das De­sign. Da­zu zählt auch die Mög­lich­keit, be­nut­zer­de­fi­nier­te Far­ben ein­zu­stel­len (zum Bei­spiel In­ver­tie­rungs­mo­dus im Browser). Ins­be­son­de­re durch CSS-Hin­ter­grund­bil­der und CSS-Con­tent kommt es hier in der Re­gel zu schwer­wie­gen­den Pro­ble­men. Das be­deu­tet letzt­end­lich auch, dass die Sei­te bei ab­ge­schal­te­tem CSS funk­ti­ons­fä­hig sein muss. • Die Ma­cro- und Mi­cro-Ty­po­gra­fie so­wie der struk­tu­rel­le Sei­ten­auf­bau soll­ten das Ver­ständ­nis ei­ner bar­rie­re­frei­en An­wen­dung un­ter­stüt­zen und vor al­lem auch Men­schen mit Dys­le­xie oder Au­tis­mus-Spek­trum stär­ker be­rück­sich­ti­gen. Da­von pro­fi­tie­ren auch al­le Nicht-Di­gi­tal-Na­ti­ves oder auch Men­schen, de­ren Mut­ter­spra­che nicht Deutsch ist – wie bei­spiels­wei­se Men­schen, die als ers­te Spra­che Ge­bär­den­spra­che ge­lernt ha­ben. • Für bar­rie­re­freie We­b­an­wen­dun­gen soll­te das selbst­ver­ständ­lich sein: Ziel und Zweck ei­nes funk­tio­na­len Links ist im­mer aus dem Link­text selbst bzw. er­wei­ter­ten At­tri­bu­ten her­aus er­kenn­bar, wenn of­fen­sicht­lich ist, dass es keinen Kon­text gibt. Da­bei gilt es zu be­rück­sich­ti­gen, dass bei­spiels­wei­se ein Tool­tipp als Hil­fe für se­hen­de Men­schen über ein Tit­le-At­tri­but nur für Desk­top-Nut­zer hilf­reich ist. • Ei­ne bar­rie­re­freie Sei­te soll­te für Screen­re­a­der-Nut­zer ver­steck­te Ab­schnitts­über­schrif­ten ver­wen­den, die den In­halt wei­ter struk­tu­rie­ren und zu­gäng­lich ma­chen. • Ab­kür­zun­gen und Sprach­wech­sel soll­ten im Qu­ell­code mit kor­rek­tem HTML aus­ge­zeich­net wer­den. • Ei­ne bar­rie­re­freie Sei­te setzt au­ßer zu De­ko­ra­ti­ons­zwe­cken kei­ne Schrift­gra­fi­ken mehr ein, weil es da­für bes­se­re Lö­sun­gen gibt. Vor al­lem für ei­ne Text­ver­grö­ße­rung spielt das ei­ne Rol­le. • Bar­rie­re­frei­heit soll­te, wenn kei­ne trif­ti­gen Grün­de da­ge­gen spre­chen, ei­ne Le­se­fä­hig­keit auf dem Ni­veau der nied­ri­gen, se­kun­dä­ren Schul­bil­dung vor­aus­set­zen. Das gilt nicht nur für re­dak­tio­nel­le In­hal­te, son­dern auch für fest­ste­hen­de Be­reichs­über­schrif­ten, Hil­fe­tex­te, Funk­ti­ons­la­bel, For­mu­larBe­schrif­tun­gen und er­wei­ter­te At­tri­bu­te. Vor al­lem Men­schen mit Dys­le­xie, aber auch Men­schen mit Lern­be­hin­de­rung so­wie Men­schen mit Mi­gra­ti­ons­hin­ter­grund wer­den das dan­ken. • Auf ei­ner bar­rie­re­frei­en Sei­te wer­den Än­de­run­gen des Kon­tex­tes nur durch Be­nut­zer­an­fra­ge aus­ge­löst oder es gibt ei­nen Mecha­nis­mus, um sol­che Än­de­run­gen ab­zu­schal­ten. Dort wo sich In­hal­te dy­na­misch (oh­ne Re­load) än­dern, wer­den vor al­lem Screen­re­a­der-Nut­zer über ent­spre­chen­de In­for­ma­tio­nen im Qu­ell­text dar­auf hin­ge­wie­sen. • In ei­ner bar­rie­re­frei­en An­wen­dung wird der Be­nut­zer be­reits bei der Ein­ga­be in For­mu­lar­fel­dern durch HTML5-For­mu­larVa­li­die­rung un­ter­stützt. Zur Feh­ler­ver­mei­dung wer­den, wo nö­tig, Hil­fen be­reit­ge­stellt bzw. plau­si­ble Feh­ler­mel­dun­gen aus­ge­ge­ben, die auch für Screen­re­a­der-Nut­zer nach­voll­zieh­bar For­mu­lar­fel­dern zu­ge­ord­net sind. • Gra­fi­sche Funk­ti­ons­ele­men­te wer­den oh­ne sicht­ba­ren Text nur dann ein­ge­setzt, wenn sie nicht für die zen­tra­le Be­die­nung der We­b­an­wen­dung not­wen­dig sind und wenn die Be­deu­tung der Gra­fik in Be­zug auf die Funk­ti­on all­ge­mein be­kannt ist. • Pro­gres­si­ve En­han­ce­ment: Ei­ne bar­rie­re­freie Sei­te ist auch dann funk­ti­ons­fä­hig, wenn Scrip­te aus­fal­len, Scrip­te nicht voll­stän­dig ge­la­den wer­den oder durch Be­nut­zer­ein­stel­lun­gen de­ak­ti­viert sind (Abb. 5). Da­bei geht es nicht um die Fra­ge, ob al­le Funk­tio­nen vor­han­den sind. Da­bei geht es auch nicht um die Fra­ge, ob die Sei­te nach gän­gi­gen Maß­stä­ben noch schön ist. Es geht dar­um, dass ei­ne Sei­te noch zu­gäng­lich und be­dien­bar ist. Das UK Go­vern­ment hat in ei­ner Stu­die her­aus­ge­fun­den, dass über 1 Pro­zent al­ler Nut­zer aus un­ter­schied­li­chen Grün­den kein Ja­vas­cript aus­ge­lie­fert be­kom­men [goo.gl/q80f­vc]. Und auch 2,4 Pro­zent al­ler Screen­re­a­der-Nut­zer sind be­trof­fen, wenn Ja­vaS­cript für die Funk­ti­ons­fä­hig­keit ei­ner Web­sei­te vor­aus­ge­setzt wird [goo.gl/eo­z7yA].

DER MENSCH IM FO­KUS

Das UK Go­vern­ment hat 2016 in ei­nem Blog­bei­trag ei­ne sechs­tei­li­ge Pla­kat­se­rie ver­öf­fent­licht, die auch für die BITV und die WCAG vor­bild­lich wä­ren [goo.gl/isLGXJ]. An­ders als bei den Tech­no­lo­gie-ori­en­tier­ten WCAG steht hier der Mensch mit sei­nen be­son­de­ren An­for­de­run­gen im Fo­kus. Auf Git­hub gibt es mitt­ler­wei­le auch deutsch über­setz­te Pos­ter [goo.gl/S87gYE]: • De­sign für Men­schen mit Au­tis­mus-Spek­trum (Abb. 6) • De­sign für Screen­re­a­der-Nut­zer • De­sign für Men­schen mit Seh­be­hin­de­rung • De­sign für Men­schen mit phy­si­scher bzw.

mo­to­ri­scher Be­hin­de­rung • De­sign für ge­hör­lo­se oder schwer­hö­ri­ge Men­schen • De­sign für Men­schen mit Dys­le­xie (Le­se­schwä­che) Vor al­lem Men­schen mit Au­tis­mus-Spek­trum, mit Lern­be­hin­de­rung, Le­se­schwä­che und ge­hör­lo­se Men­schen wer­den durch den ak­tu­el­len Stand der WCAG nur am Rand ver­tre­ten.

SONDERFÄLLE

Was pas­siert ei­gent­lich, wenn man bei­spiels­wei­se auf der ei­nen Sei­te An­for­de­run­gen an ge­schlech­ter­ge­rech­te For­mu­lie­run­gen und auf der an­de­ren Sei­te An­for­de­run­gen der BITV nach ei­ner mög­lichst ein­fa­chen Spra­che be­rück­sich­ti­gen soll? Gut ge­mein- te For­mu­lie­run­gen, wie bei­spiels­wei­se „die/der Stu­dent/in und die/der Uni­ver­si­täts­pro­fes­sor/in” oder in an­de­rer Schreib­wei­se „Die Stu­den­t_in­nen bzw. die Stu­dent*in­nen” sind nicht nur für Men­schen mit Le­se­schwä­che ein Graus, son­dern auch für je­den Screen­re­a­der-Nut­zer. Die BITV ist auf sol­che Sonderfälle kaum an­wend­bar. Wer hier „ge­winnt”, ent­schei­det am En­de wahr­schein­lich le­dig­lich die in­ter­ne Stel­lung des Gleich­stel­lungs­be­auf­trag­ten bzw. des Be­hin­der­ten­be­auf­trag­ten.

FA­ZIT

Die WCAG sind mitt­ler­wei­le zu ei­nem Rie­sen mu­tiert, der ei­gent­lich nur schwer mit dem „Das passt auf ei­nen Bier­de­ckel”An­satz der vier Prinzipien (POUR-Re­gel) ver­ein­bar ist. Die BITV ist schlan­ker, aber ver­wir­rend durch die Ab­wei­chun­gen von den WCAG, und sie kommt oh­ne die WCAG-Tech­ni­ken und Failu­res nicht aus. Die WCAG ist sys­tem­be­dingt lü­cken­haft und lässt un­nö­ti­ger­wei­se Raum für ab­sur­de Lö­sun­gen, die auf der ei­nen Sei­te richtlinienkonform und trotz­dem im höchs­ten Ma­ße mit Bar­rie­ren be­haf­tet sind. Ein Bei­spiel: Ei­ne Sei­te in 40 Me­ga­byte Down­load­grö­ße, oh­ne Ja­vaS­cript-Fall­back, mit Browser-Rück­wärts­kom­pa­ti­bi­li­tät bis IE10 (und oh­ne mo­bi­le Op­ti­mie­rung), mit Fra­me- und Ta­bel­lenLay­out, teil­wei­se ka­putt kom­pri­mier­ten, gra­fi­schen Textin­hal­ten ist selbst un­ter Ver­wen­dung ei­ner ge­ren­der­ten 5-Pi­xel-Ita­li­cVer­sal­schrift mit 5.000 gra­fi­schen Icon-Fonts-Links (zu Sei­ten oh­ne In­halt) und fast un­sicht­ba­rem De­fault-Tas­ta­tur­fo­kus nach BITV de fac­to bar­rie­re­frei, weil es da­für kei­ne Prüf­schrit­te gibt – wenn sonst al­les ein­ge­hal­ten wur­de. Auch für ver­ti­kal ge­stürz­ten Text in Süt­ter­lin­schrift gibt es kei­ne Richt­li­nie, die das ver­bie­ten wür­de. Was so­wie­so schon un­le­ser­lich wä­re, könn­te man durch rie­si­ge Schrift zu­sätz­lich ad ab­sur­dum füh­ren. Denn auch da­für gibt es kei­ne Richt­li­ni­en, weil das eben nicht nur be­hin­der­te Men­schen tan­gie­ren wür­de, son­dern al­le Men­schen. Da­durch wür­de die­se Kon­struk­ti­on fälsch­li­cher­wei­se in dem Be­reich Usa­bi­li­ty ver­or­tet und in Be­zug auf Ac­ces­si­bi­li­ty nach BITV und WCAG kei­ner­lei Ab­zü­ge be­kom­men. Sie se­hen al­so, Richt­li­ni­en sind ei­ne wich­ti­ge Hil­fe. Für rei­ne Kon­for­mi­tät rei­chen die Richt­li­ni­en aus, nicht aber für tat­säch­li­che Bar­rie­re­frei­heit. Wer sich auf das Aben­teu­er ein­lässt und die WCAG stu­diert, soll­te ei­nen nutz­er­zen­trier­ten An­satz im Hin­ter­kopf be­hal­ten und den Sta­tus quo im­mer hin­ter­fra­gen. Ein tie­fe­res Ver­ständ­nis von Be­hin­de­rungs­ar­ten und As­sis­ti­ven Tech­no­lo­gi­en so­wie der ver­schie­de­nen Nut­zungs­ge­wohn­hei­ten von Men­schen mit be­son­de­ren Be­dürf­nis­sen hilft im Zwei­fels­fall deut­lich mehr als der Ver­such, ein­fach Check­lis­ten ab­zu­ar­bei­ten.

Abb. 5: Die Sei­te at­ten­d­orn.de ist bei de­ak­ti­vier­tem oder nicht kor­rekt aus­ge­lie­fer­tem Ja­vaS­cript un­be­nutz­bar. Das ist für die BITV de fac­to kein Pro­blem.

Abb. 4: Schlecht sicht­ba­rer De­fault-Tas­ta­tur-Fo­kus im Fi­re­fox 54.0.1 (un­ten rechts). Kein Fall für die BITV.

Abb. 2: Zwei Bei­spie­le von Sei­ten, auf de­nen Icon­fonts nicht rich­tig aus­ge­lie­fert wur­den. Sie­he: „Se­rious­ly, Don’t Use Icon Fonts” [goo.gl/so­vBC9].

Abb. 3: Foo­ter der Sei­te fo­cus.de – ei­ne Link- und Funk­ti­ons­wüs­te. Aber das al­lei­ne reicht nicht für ei­ne Ab­wer­tung im Sin­ne der BITV.

Abb. 6: Ei­nes der sechs der auf Deutsch über­setz­ten Pla­ka­te un­ter Crea­ti­ve­Com­mons-Li­zenz auf Git­hub [goo.gl/S87gYE]. Gu­te Tipps für mehr Bar­rie­re­frei­heit, aber nicht voll­stän­dig von der BITV ab­ge­deckt. Leuch­ten­de Far­ben und kom­ple­xe Lay­outs sind zum...

Twit­ter: @ana­tom5 Kom­men­tie­ren: screen­gui.de/36/bar­rie­re­frei­heit

Jörg Mors­bach ist Ge­schäfts­füh­rer der Agen­tur ana­tom5, die seit 2003 auf Bar­rie­re­frei­heit im In­ter­net spe­zia­li­siert ist [ana­tom5.de]. Da­zu ge­hört seit ei­ni­gen Jah­ren auch die Er­stel­lung bar­rie­re­frei­er PDF-Do­ku­men­te. Sei­ne lan­ge ver­heim­lich­te Lie­be gilt...

Newspapers in German

Newspapers from Germany

© PressReader. All rights reserved.