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.
Inhaber, Expert Consultant
Dr. Christopher H. Müller, Gründer und Inhaber der Ergonomen Usability AG, promovierte am Institut für Hygiene und Arbeitsphysiologie der ETH Zürich. Er ist seit mehr als 22 Jahren Experte für Usability und User Experience. Sein ausgeprägtes Einfühlungsvermögen ermöglicht es ihm, rasch die Bedürfnisse und Perspektiven der Kunden zu verstehen. Mit viel Kreativität und Mut unterstützt er seine Kunden in Digitalisierungsvorhaben und bei der Optimierung von Produkten, Dienstleistungen oder Prozessen. Er verfolgt einen praxisorientierten Ansatz und entwickelt massgeschneiderte Lösungen, die effektiv umgesetzt werden können. Dr. Christopher H. Müller ist Kolumnist in der Netzwoche. Weitere Engagements sind unter anderem Stiftungsrat bei der Stiftung Zugang für alle, Mitglied in zwei Swico-Beiräten und Co-Präsident der Regionalkonferenz Nördlich Lägern.
Consultant
People-Oriented Computing-Spezialistin, die sich für eine inklusive und barrierefreie digitale Welt einsetzt. Lina bringt ihr übergreifendes Verständnis von Design und Programmierung in Usability und Prototyping ein – und einen Hund ins Team.
