Wird barrierefreie Web-Entwicklung zum Mainstream?

Hand-gecodete Webseiten erinnern an eine etwas verklärte Zeit. Irgendwie muss ich immer an die Großmutter denken, die am Kamin sitzt und Jäckchen für die kleinen Enkel strickt. Wobei meine Großmutter im tropischen Goa sicher nie an einem Kamin gesessen hat.
Heutzutage kommt man allerdings an Frameworks kaum vorbei. Klar kann man die Website auf dem Desktop betreuen und dann über FTP hochladen. Oder minimalistische Redaktionssysteme verwenden. Doch für moderne Interfaces, die schick, aber auch funktional sein sollen ist das wohl nicht mehr der beste Weg. Wer hat heute noch Ressourcen, ein Akkordeon, eine Flyout-Navigation oder eine Slideshow zu programmieren und sie auf allen möglichen Endgeräten und Browsern zu testen? Die öffentliche IT ganz sicher nicht, eben so wenig wie deren externe Dienstleister.
Nun haben sich die Entwickler:Innen dieser Bibliotheken und vieler Redaktionssysteme bisher kaum um Barrierefreiheit gekümmert. Auch für sie war es so anstrengend. Doch der Wind wird sich sehr bald drehen.

Härtere Richtlinien, mehr Betroffene

Ab und zu muss man daran erinnern, dass die BITV nicht erst seit der EU-Direktive 2102 gilt. Die erste BITV wird gerade 20 Jahre alt. Wer sich jetzt erst darum kümmert, hat bisher seine Pflichten sträflich vernachlässigt.
However, die Entwicklung um 2102 hat jetzt einen hohen Grad an Nervosität ausgelöst. Webseiten wirden immer stärker monitort und Barrierefreiheits-Bugs werden nach und nach ausgebügelt. Ein Grund, ungeeignete Frameworks zu entsorgen und durch solche zu ersetzen, die Barrierefreiheit unterstützen.
Nun macht die öffentliche IT einen guten Teil der digitalen Infrastruktur aus. Allein das wäre ein Grund, stärker auf Barrierefreiheit zu achten, um diesen Markt nicht zu verlieren. Aber auch ein Gutteil des Nonprofit-Sektors ist zur Barrierefreiheit verpflichtet. Dies dürfte doch einen guten Teil des Internets betreffen.
Ein aktuelles Beispiel: Der neue BITV-Test fordert die barrierefreie Transformation von Inhalten, heißt, wenn über die Website ein PDF aus einer HTML-Seite erstellt werden kann, muss das resultierende PDF die Barrierefreiheits-Infos aus dem HTML übernehmen. Das kann kaum eine der aktuell angebotenen Bibliotheken zur PDF-Konvertierung.
Natürlich stammen die meisten dieser Frameworks aus dem anglo-amerikanischen Bereich. Dort gibt es auch einen starken Druck vor allem in den USA oder Kanada durch härtere Gesetze und Klagewellen.
Natürlich ist das vor allem für kommerziell vertriebene Frameworks interessant. Doch auch die kostenlosen Anbieter sind sicherlich an einer weiten Verbreitung ihrer Frameworks interessant. Wozu soll man eine Bibliothek weiter entwickeln, die keiner nutzt?

Es wird einfacher, aber nicht einfach

Allerdings wird den Entwickler:Innen zwar Arbeit abgenommen. Doch müssen sie sich trotzdem mit Barrierefreiheit beschäftigen. Die Bibliotheken bieten ja schon heute teilweise die Möglichkeit, ARIA oder andere relevante Eigenschaften hinzuzufügen, den Kontrast zu ändern oder den Fokus zu korrigieren.
Oder anders gesagt: Man kann mit einem guten Framework Mist produzieren und mit einem schlechten Framework gute Ergebnisse erzielen.
Doch die Arbeit wird durch gute Frameworks deutlich erleichtert. Tastatur-Bedienung, Fokus-Management, Mindest-Kontraste, ARIA States und so weiter sind wesentlich besser umsetzbar, wenn sie einmal zentral integriert wurden.
Vielleicht sollten wir uns in Zukunft nicht mehr auf einzelne Organisationen stürzen, sondern uns gezielt an die Entwickler:Innen der Frameworks wenden. Das dürfte einen wesentlich größeren Impact haben.
Web Accessible Code Libraries and Design Patterns

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.