Fach­ar­ti­kel

Hindernisse überwinden mit barrierefreier Software

Bar­rie­re­freies Arbei­ten

Der Begriff „bar­rie­re­frei“ kommt ursprüng­lich aus dem Bau­we­sen und meint, dass bei­spiels­weise der Zutritt zu einem Gebäude oder die Nut­zung eines Gegen­stan­des kei­nem Men­schen durch Hin­der­nisse jeg­li­cher Art erschwert wer­den soll. An vie­len Stel­len im öffent­li­chen Raum begeg­nen uns Maß­nah­men zur Bar­rie­re­frei­heit. So wird etwa Roll­stuhl­fah­rern das Über­win­den von Höhen­un­ter­schie­den durch Ram­pen erleich­tert, wäh­rend Ton­si­gnale an Ampeln blin­den und seh­be­hin­der­ten Men­schen das Signal zum Über­que­ren der Straße „über­set­zen“.

Ana­log dazu soll bar­rie­re­freie Soft­ware allen Mit­ar­bei­tern eines Unter­neh­mens oder einer Behörde ermög­li­chen, die­selbe Arbeit zu erle­di­gen. Typi­sche Bar­rie­ren ent­ste­hen dabei durch kör­per­li­che Behin­de­run­gen, etwa einem feh­len­den Seh– oder Hör­sinn oder moto­ri­schen Ein­schrän­kun­gen.

Doch wel­che Vor­aus­set­zun­gen muss eine Soft­ware erfül­len, um allen Mit­ar­bei­tern das Ver­rich­ten der glei­chen Arbeit zu ermög­li­chen? Und wie kann die jewei­lige Ein­schrän­kung durch Soft­ware kom­pen­siert wer­den?

Wie wird Soft­ware bar­rie­re­frei?

Durch ver­schie­dene Nor­men, wie die ISO 9241 für die „Ergo­no­mie der Mensch-​System-​Interaktion“, die „Web Con­tent Acces­si­bi­lity Gui­de­lines (WCAG)“ des World Wide Web Con­sor­ti­ums und die „Bar­rie­re­freie Infor­ma­ti­ons­tech­nik Ver­ord­nung (BITV 2.0)“, sind Kri­te­rien für bar­rie­re­freie Soft­ware defi­niert:

  • Tren­nung von Text und Lay­out, damit Text von Screen­re­a­dern aus­ge­le­sen und auf einer Braille-​Zeile aus­ge­ge­ben wer­den kann (Aus­gabe in Blin­den­schrift).
  • Für nicht text­li­che Inhalte müs­sen Alter­na­ti­ven ange­bo­ten wer­den. Zum Bei­spiel soge­nannte Alt-​Tags für Bil­der und Gra­fi­ken.
  • Inhalte sind so auf­zu­be­rei­ten, dass sie ohne Infor­ma­ti­ons­ver­lust aus­ge­le­sen wer­den kön­nen.
  • Farbe darf nicht das ein­zige Mit­tel sein, um Infor­ma­tio­nen zu über­mit­teln oder eine Reak­tion zu ver­an­las­sen – etwa die Farbe Rot bei But­tons und Warn­hin­wei­sen.
  • Alle Funk­tio­nen sol­len über eine Tas­ta­tur aus­ge­führt wer­den kön­nen, um bewe­gungs­ein­ge­schränk­ten Men­schen die Steue­rung zu erleich­tern.
  • Offen­heit in Bezug auf Betriebs­sys­teme und End­ge­räte, um die Anbin­dung von Screen­re­a­dern, Vor­le­se­hil­fen und ande­ren assis­ti­ven Tech­no­lo­gien zu gewähr­leis­ten.
  • Offen­heit in Bezug auf die Ska­lie­rung und Dar­stel­lung, um Ver­grö­ße­run­gen, Inver­tie­run­gen oder beson­ders kon­trast­rei­che Dar­stel­lun­gen zu ermög­li­chen.

Open from scratch

Diese Kri­te­rien erschei­nen logisch, defi­nie­ren sie doch moderne Software-​Architekturen mit einem „sau­be­ren“, uni­ver­sa­len Code. In guten Software-​Applikationen soll­ten alle Funk­tio­nen für alle Anwen­der nutz­bar sein. Die Pra­xis sieht jedoch anders aus. Häu­fig ist der Code nicht bar­rie­re­frei. Screen­re­a­der erhal­ten kei­nen Zugang zu den Infor­ma­tio­nen oder schlim­mer noch: Infor­ma­tio­nen wer­den feh­ler– oder lücken­haft aus­ge­le­sen. Genau das darf bei bar­rie­re­freien Anwen­dungs­sze­na­rien nicht pas­sie­ren, schließ­lich müs­sen sich blinde Men­schen auf assis­tive Tech­no­lo­gien ver­las­sen kön­nen.

Nicht nur durch den Code, auch durch die Benut­zer­ober­flä­che wer­den häu­fig Bar­rie­ren geschaf­fen. Ana­log zum Trend im Netz ist moderne Soft­ware stark visu­ell geprägt. Appli­ka­tio­nen arbei­ten mit Bil­dern, Gra­fi­ken, farb­li­chen oder ani­mier­ten Ele­men­ten, schwe­ben­den Menüs, Drag and Drop oder Over­lays. Screen­re­a­der und andere assis­tive Tech­no­lo­gien kön­nen mit sol­chen Benut­zer­ober­flä­chen nur schwer umge­hen. Für Business-​Software gilt daher: Weni­ger ist mehr.

Ein­fach zu erschlie­ßende, klar struk­tu­rierte Benut­zer­ober­flä­chen sind, auch wenn sie viel­leicht lang­wei­lig erschei­nen, mit hoher Wahr­schein­lich­keit bar­rie­re­frei – und meist auch für Nut­zer ohne Ein­schrän­kun­gen effek­ti­ver zu bedie­nen.

Gute Vor­aus­set­zung: Ein detail­lier­ter Anfor­de­rungs­ka­ta­log

In zahl­rei­chen Pro­jek­ten für bar­rie­re­freie Software-​Anwendungen ent­hal­ten die Anfor­de­rungs­ka­ta­loge nur sehr wenige Vor­ga­ben. Einer­seits, da es den Auf­trag­ge­bern häu­fig an ein­schlä­gi­ger Erfah­rung man­gelt, ande­rer­seits, weil es an fach­spe­zi­fi­schem Wis­sen fehlt. Die Fra­gen lau­ten: Was muss und was kann umge­setzt wer­den? Und auf wel­che Art und Weise?

Neh­men wir das Bei­spiel eines Call­cen­ters: Der Pro­zess Anruf – Annahme – Bear­bei­tung – Auf­le­gen – Nach­be­ar­bei­tung soll für blinde Mit­ar­bei­ter und Kol­le­gen mit moto­ri­schen Ein­schrän­kun­gen bar­rie­re­frei gestal­tet wer­den.

Für blinde Anwen­der muss die kom­plette Steue­rung per Maus in Short­cuts, Tabu­la­tor­steue­rung sowie Ein– und Aus­gabe auf die Braille-​Tastatur über­tra­gen wer­den. Eine Alter­na­tive zur Maus­steue­rung hilft zugleich auch Anwen­dern mit moto­ri­schen Ein­schrän­kun­gen, weil diese mit Tabu­la­to­ren und Short­cuts oft schnel­ler sind als mit der Maus. Für seh­be­hin­derte Men­schen müs­sen zudem Mög­lich­kei­ten zur extre­men Ver­grö­ße­rung und star­ken Kon­trast­set­zung geschaf­fen wer­den. Fer­ner gilt es zu über­le­gen, wie der Pro­zess und Teil­pro­zesse abge­bil­det wer­den:

  • Wie sol­len blinde Mit­ar­bei­ter bei­spiels­weise über einen ein­ge­hen­den Anruf benach­rich­tigt wer­den und wie neh­men sie ihn an?
  • Wie doku­men­tie­ren moto­risch behin­derte Nut­zer, die nur lang­sam oder ein­ge­schränkt tip­pen kön­nen, Geschäfts­vor­fälle?
  • Wie wer­den zusätz­li­che Doku­mente – z.B. Gesprächs­leit­fä­den – zugäng­lich gemacht?

Abschlie­ßend müs­sen die „über­setz­ten“ Funk­tio­nen in Skill­sets und Anwen­der­pro­fi­len hin­ter­legt wer­den, die bestimmte Fähig­kei­ten und Fach­wis­sen vor­aus­set­zen. Für die erfolg­rei­che Umset­zung die­ses hoch­kom­ple­xen Pro­zes­ses soll­ten von Beginn an gute Grund­la­gen geschaf­fen wer­den. Ein kla­rer und detail­liert for­mu­lier­ter Anfor­de­rungs­ka­ta­log spart am Ende viele Ite­ra­tio­nen und Test­zy­klen.

Erfah­rene Part­ner

In der Ent­wick­lung von Business-​Applikationen haben sich gemischte Teams aus IT-​Leuten, Ent­wick­lern, Fach­ver­ant­wort­li­chen und Anwen­dern bewährt. Auch in Barrierefrei-​Projekten kann es sinn­voll sein, die eigent­li­chen Nut­zer, ein­ge­schränkt und nicht, in den Ent­wick­lungs­pro­zess ein­zu­be­zie­hen. Gerade behin­derte Anwen­der kön­nen auf­grund ihrer All­tags­er­fah­run­gen wich­tige Ideen ein­brin­gen.

Wenn es Ihnen an detail­lier­ten tech­no­lo­gi­schen Kennt­nis­sen oder Erfah­run­gen mit bar­rie­re­freier Soft­ware fehlt, soll­ten Sie nicht davor zurück­schre­cken, Exper­ten hin­zu­zu­zie­hen. Ein seriö­ser Part­ner kann Ihnen bei­spiels­weise Kon­takte zu den Ver­ant­wort­li­chen in Refe­renz­pro­jek­ten ver­mit­teln. So kön­nen Sie mit den Kol­le­gen spre­chen und von deren Erfah­run­gen pro­fi­tie­ren. Denn selbst bei guten Vor­aus­set­zun­gen dau­ert es viele Tests und Ite­ra­tio­nen, bis eine bar­rie­re­freie Bedie­nung steht.

Neh­men Sie gerne Kon­takt zu uns auf, wenn Sie Fra­gen zum Thema bar­rie­re­freie Soft­ware haben oder auf der Suche nach einem erfah­re­nen und ver­läss­li­chen Part­ner sind, der Ihnen bei der Rea­li­sie­rung eines sol­chen Pro­jekt­vor­ha­bens hel­fen kann.