Das Arbei­ten mit Soft­ware ist in den letz­ten Jahr­zehn­ten für die meis­ten Men­schen zu einem ganz gewohn­ten und auch wich­ti­gen Teil ihres All­tags gewor­den. Egal ob wir im Inter­net sur­fen, Brie­fe oder E-Mails schrei­ben oder am Arbeits­platz mit fir­men­in­ter­nen Pro­gram­men kon­fron­tiert sind, der siche­re Umgang mit Soft­ware wird heut­zu­ta­ge erwar­tet und vor­aus­ge­setzt. Pro­ble­ma­tisch wird es erst, wenn eine Soft­ware für einen Men­schen eine Bar­rie­re dar­stellt. Far­ben wer­den schlecht oder gar nicht erkannt, Töne nicht gehört oder Tex­te kön­nen nicht gele­sen wer­den. Die bar­rie­re­freie Soft­ware­ent­wick­lung setzt genau dort an.

Was ist bar­rie­re­freie Soft­ware­ent­wick­lung?

Pro­gram­me, die für jeden Men­schen mit kör­per­li­cher oder geis­ti­ger Ein­schrän­kung geeig­net sind, wer­den bar­rie­re­freie Pro­gram­me genannt. Eine kör­per­li­che Ein­schrän­kung kann das limi­tier­te oder nicht vor­han­de­ne Seh­ver­mö­gen sein, hier müs­sen Alter­na­ti­ven für den regu­lä­ren Text gefun­den wer­den. Bei Men­schen ohne Hör­ver­mö­gen kön­nen akus­ti­sche Signa­le zum Bei­spiel beim E-Mail Ein­gang nicht genutzt wer­den. Men­schen mit einer Rot-Grün-Seh­schwä­che müs­sen ande­re Far­ben ange­bo­ten wer­den. Auch Senio­ren kom­men mit bar­rie­re­frei­er Soft­ware oft bes­ser zurecht, hier muss zum Bei­spiel auf die ver­min­der­te Reak­ti­ons­zeit und grö­ße­re Tex­te oder die Anwend­bar­keit einer Bild­schirm­lu­pe geach­tet wer­den. Fremd­spra­chi­ge Per­so­nen haben oft Pro­ble­me mit dem Text­ver­ständ­nis. Hier kön­nen auto­ma­ti­sche Über­set­zun­gen oder eine ver­ein­fach­te Seman­tik hel­fen.

Was ist wich­tig?

Bar­rie­re­freie Soft­ware­ent­wick­lung muss die ver­schie­dens­ten Aspek­te von Pro­gram­men berück­sich­ti­gen. Je nach Soft­ware und Ziel­grup­pe ist das zum Bei­spiel die Ori­en­tie­rung des Tex­tes oder eine Ersatz­be­schrei­bung für Mul­ti­me­diain­hal­te. Auch Far­ben und Kon­tras­te müs­sen über­prüft und even­tu­ell anpass­bar sein. Tex­te und das Lay­out müs­sen in den unter­schied­lichs­ten Grö­ßen ein­deu­tig erkenn­bar und erfass­bar sein. Beson­ders wich­tig ist auch die Dyna­mik des Pro­gramms: Ist die Soft­ware über die Maus und die Tas­ta­tur steu­er­bar? Kann man womög­lich eine Steue­rung über die Stim­me ermög­li­chen? Auch Ele­men­te zur Navi­ga­ti­on und Ori­en­tie­rung müs­sen kon­sis­tent umge­setzt wer­den, mög­li­cher­wei­se sind hier auch zusätz­li­che Ele­men­te nötig.

Wie wird Soft­ware auf Bar­rie­re­frei­heit über­prüft?

Für Ent­wick­ler ist es wesent­lich ein­fa­cher, die Bar­rie­re­frei­heit im Vorn­her­ein zu imple­men­tie­ren, als sie spä­ter ein­zu­fü­gen. Bereits ent­wi­ckel­te Pro­gram­me kön­nen mit Hil­fe von meh­re­ren Richt­li­ni­en über­prüft wer­den. Beson­ders drei Leit­fä­den haben sich hier in der Pra­xis bewährt:

    1. Die DIN EN ISO 9241–171 Leit­li­ni­en für die Zugäng­lich­keit von Soft­ware
    2. Die Ent­wick­ler-Richt­li­ni­en von IBM (Deve­lo­per Gui­de­li­nes)
    3. Die Richt­li­ni­en für bar­rie­re­freie Web­in­hal­te des World Wide Web Con­sor­ti­um

Die Über­prü­fung eines Pro­gramms ist aber immer noch „Hand­ar­beit“. Es gibt bis heu­te kei­ne eigen­stän­di­gen Pro­gram­me, die dies leis­ten könn­ten. Wäh­rend der Test auf die Kom­pa­ti­bi­li­tät mit der Tas­ta­tur rela­tiv ein­fach durch­zu­füh­ren ist, sind man­che Aspek­te von Soft­ware im Nach­hin­ein nur schwer auf bar­rie­re­frei­es Arbei­ten zu über­prü­fen. Dazu gehö­ren alle Anfor­de­run­gen, die im Quell­code der Pro­gram­mie­rung schwer oder gar nicht mehr zu fin­den sind, wie zum Bei­spiel das Ver­se­hen einer jeden Schnitt­stel­le oder Ele­ments mit einem spe­zi­fi­schen Namen.