Inklusion betrifft insbesondere die digitale Welt und die Nutzung digitaler Angebote. Wer heutzutage Websites programmiert, tut dies deshalb in der Regel barrierefrei, könnte man meinen. Leider nein. Dabei wäre Barrierefreiheit mit etwas Programmieraufwand und gutem Willen einfach umsetzbar.
In der Schweiz leben rund 1,7 Millionen Menschen mit einer Beeinträchtigung. 377 000 von ihnen sind sehbehindert, 50 000 von ihnen sind blind. Sie und andere Menschen mit sensorischer oder motorischer Behinderung können aber – je nach Schwere der Beeinträchtigung – digitale Onlineangebote (oder andere Software) nur nutzen, wenn diese barrierefrei programmiert wurden. Barrierefreiheit beziehungsweise Accessibility ist jedoch längst nicht flächendeckend in der Web- und Softwareentwicklung angekommen. Als Gründe dafür gelten höhere Entwicklungskosten und -dauer. Das ist skandalös, denn das bedeutet, dass entsprechend beeinträchtigte Menschen Onlineangebote nur begrenzt oder schlimmstenfalls gar nicht nutzen können. Diese Benachteiligung behindert Behinderte ein weiteres Mal und erschwert deren Teilhabe an verschiedenen Lebensbereichen. Barrierefreies Internet, also dessen vollständige Nutzung unabhängig von Einschränkungen, wäre aber möglich. Doch dafür braucht es das Bewusstsein und den Willen, in einem Webprojekt die Barrierefreiheit von Anfang an zu integrieren.
Barrierefreiheit ist übrigens auch in entsprechenden Vorgaben der Vereinten Nationen, im EU-Recht und auch in der Schweizerischen Gesetzgebung vorgesehen sowie im Behindertengleichstellungsgesetz BehiG vorgeschrieben. Der Bundesstandard P028 etwa präzisiert die Anforderungen mit Angabe der «Richtlinien für barrierefreie Webinhalte, WCAG 2.1» Konformitätsstufe AA für die Onlineangebote der öffentlichen Hand. AA umschreibt die Kriterien, dass sensorisch oder motorisch Beeinträchtige eine Website nutzen können und basiert auf den Web Content Accessibility Guidelines (WCAG) 2.1 – W3C, einem internationalen Standard. Auch für E-Commerce-Angebote empfiehlt sich AA. Ausser AA beinhalten die WCAG die weiteren Stufen A und AAA. Die entsprechenden Vorgaben reichen von grundlegender Barrierefreiheit (A) bis zu einem vollständig barrierefreien Webauftritt (AAA), der eingeschränkten Menschen eine gleichwertige Nutzungsqualität bietet (AAA) wie uneingeschränkten.
Aber wann ist eine Website konkret «barrierefrei»? Die Antwort ist einfach: Wenn Menschen mit Behinderungen auf alle darauf enthaltenen Informationen zugreifen und alle Funktionen nutzen können. Dies bedingt auch, dass spezielle Eingabe- und Zeigegeräte, Bildschirm-Vorleseprogramme, Braillezeilen und Vergrösserungsprogramme für Bildschirminhalte von beeinträchtigen Menschen die angezeigten Informationen und Funktionen erkennen und umsetzen können. Zudem muss eine Website vollständig mit der Tastatur bedient werden können, etwa wenn User nicht in der Lage sind, eine Maus zu verwenden.
Aber auch wenn die Antwort einfach ist, müssen sich Entwickler mit den entsprechenden Vorgaben auseinandersetzen. Dabei gilt es für sie, sich auf die vier Prinzipien Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit zu konzentrieren.
Wenn eines dieser vier Prinzipien bei der Entwicklung verletzt wurde, können User mit Beeinträchtigungen das Web nicht nutzen. Das hat auch psychologische Folgen für die Betroffenen. Denn jeder Mensch hat psychologische Grundbedürfnisse, zu denen auch das Bedürfnis nach Kontrolle und Selbstbestimmung gehört. Es ist einfach nachvollziehbar, dass eine nicht barrierefreie Website dieses Bedürfnis verletzt, Frust bei den Betroffenen auslöst und das Gefühl, ausgeschlossen zu sein, noch verstärkt.
Zudem haben Applikationsbetreiber angesichts der zunehmenden Digital-only-Strategie vieler Unternehmen – insbesondere auch bei Behördengängen – eine besondere Verantwortung, Dienste für alle nutzbar zu machen. Kommt hinzu, dass Barriere-UN-Freiheit bei Websites beziehungsweise Softwareanwendungen im Allgemeinen auch betriebswirtschaftlich ein Unsinn ist.
Dazu ein Rechenbeispiel: Angenommen, ein Unternehmen beschäftigt eine beeinträchtigte Mitarbeiterin oder einen beeinträchtigen Mitarbeiter, die beziehungsweise der im Arbeitsalltag Unterstützung benötigt, etwa beim Bedienen eines CMS, das nicht barrierefrei programmiert wurde. Weiter nehmen wir an, diese Unterstützung kostet pro Arbeitstag total eine Arbeitsstunde anderer Mitarbeitenden. Dies ergibt 235 Arbeitsstunden pro Jahr (Basis Jahresarbeitszeit 260 Arbeitstage, abzüglich 25 Ferientage). 235 Arbeitsstunden entsprechen rund 28 Arbeitstagen (Basis 42-Stundenwoche) oder einem Arbeitspensum von rund 11 Prozent. In 9 Jahren verliert ein Unternehmen, das ein nicht barrierefrei programmiertes CMS einsetzt, also ein ganzes Personenjahr.
Entwickler beziehungsweise deren Auftraggeber, die hier sparen, tun dies auf dem Rücken von Menschen mit Beeinträchtigungen und deren Arbeitgebern. Im E-Commerce behindern nicht barrierefreie Onlineshops ausserdem die Conversion. Lohnt es sich also bei der Web- oder Softwareentwicklung, an der Barrierefreiheit zu sparen? Für Entwickler vielleicht, für professionelle Anwender beziehungsweise Unternehmen auf keinen Fall.
Zudem ist es moralisch nicht vertretbar, beeinträchtigte Menschen von der Teilhabe am digitalen Leben auszuschliessen. Denn sie verbringen online nachweislich mehr Zeit als nicht Beeinträchtigte. Dies sind gute Gründe, die Barrierefreiheit in der Webentwicklung von Anfang an mitzudenken
Entwicklerinnen und Entwickler, die unsicher sind, wie barrierefrei die von ihnen programmierte Website beziehungsweise Software ist, holen sich Unterstützung von Fachexperten aus den Bereichen Usability und Front-End-Entwicklung. Diese führen Accessibility-Reviews durch, die überprüfen, ob
bei der Entwicklung eingehalten wurden.
In einer Vorabversion liegt die WCAG-Accessibility-Checkliste 2.1 unter diesem Link vor: https://a11y.digitaldialog.swiss
Zum Testing helfen Tools während und nach der Implementation sowie im Rahmen des Designprozesses. Es sind dies etwa:
Bild: Accessibility von Dave Braunschweig
Wir freuen uns, von Ihnen zu hören.
Owner, Expert Consultant
Dr. Christopher H. Müller, founder and owner of Ergonomen Usability AG, earned his PhD from the Institute for Hygiene and Applied Physiology at ETH Zurich. With over 22 years of experience, he is an expert in usability and user experience. His strong sense of empathy allows him to quickly understand the needs and perspectives of his clients. With creativity and courage, he supports his clients in their digitalization projects and the optimization of products, services, and processes. He takes a practical approach, developing tailored solutions that can be effectively implemented. Dr. Christopher H. Müller is a columnist for Netzwoche. He also serves as a board member for the Zugang für alle Foundation, and is a member of two Swico advisory boards and co-president of the Regional Conference Nördlich Lägern.
Consultant
People-Oriented Computing specialist with the aim to make the digital world inclusive and barrier-free. Being responsible for usability and prototyping, Lina brings along an intertwined comprehension of design and coding – as well as a dog.
