Der Weg zur barrierefreien codecentric-Website – Insights und Learnings

Anna als eine unserer Expertinnen für Barrierefreiheit und Elke als Treiberin des Website Relaunch haben die Accessibility-Brille aufgesetzt und die Überarbeitung der eigenen Website beleuchtet:

Es wäre wirklich schön, wenn wir unsere Website als leuchtendes Beispiel für Barrierefreiheit herzeigen könnten. Leider ist das im Moment (noch) nicht der Fall, denn wir sind noch nicht so weit. Warum?  

Warum überhaupt barrierefrei? 

Bei Barrierefreiheit geht es darum, eine Website wirklich allen zugänglich zu machen:

Alle diese Menschen und noch viele andere können unsere User sein. Für uns Grund genug, uns mit dem Thema zu beschäftigen. Weitere Gründe dafür, eine Website barrierefrei zu machen, findet ihr in diesem Blogartikel.

Doch nun zu unserer Website:

Auftakt: Website Relaunch

Unsere alte Website war etwas in die Jahre gekommen und entsprach nicht mehr unseren Anforderungen an Sicherheit, Darstellung unseres Portfolios und dem aufzubringenden Pflegeaufwand. Etwas Frisches musste her. 

Also ging es ans Werk und wir vertieften uns in die verschiedenen Anforderungen an eine Website und führten Gespräche mit vielen Expert*innen innerhalb der codecentric. Neben der eigentlichen Darstellung des Content ging es vor allem um Architektur und Sicherheit, aber auch um Barrierefreiheit und Nachhaltigkeitsaspekte. Die Herausforderung: allen Anforderungen so weit wie möglich gerecht zu werden, gleichzeitig im Budget zu bleiben und das alles in einem überschaubaren Zeithorizont abzuwickeln.

Wie sind wir also in Hinblick auf Barrierefreiheit vorgegangen?

Der erste Schritt: Check der Barrierefreiheit am Prototypen

Die Website war auf einem guten Weg, die Sicherheitsaspekte soweit berücksichtigt, sodass wir uns den Barrierefreiheits-Anforderungen zuwenden konnten. Wir müssen vorausschicken, dass wir der Entwicklung vorab keine Vorgaben mitgegeben hatten. Und so kamen wir zum ersten Learning: Barrierefreiheit ist keineswegs ein Automatismus, der in der Entwicklung automatisch mitgedacht wird.

Entsprechend negativ fiel der erste Test des Prototypen aus. Hier ein Auszug aus unseren Findings:

• Semantik: Die semantische Struktur der Seite war ziemlich durcheinander und Formularfelder nicht beschriftet.
• Keyboard-Navigation: nicht alles war mit dem Keyboard zu erreichen oder zu bedienen. Vor allem die Ansteuerung der Formulare – der wichtigste funktionale Part der Website – klappte nicht einwandfrei.
• Auflösung: Bei größerer Auflösung war die Seite nicht nutzbar.
• Farben / Kontrast: Unsere Brand-Color ist eine große Herausforderung für uns. Das helle Grün liefert zu wenig Kontrast zu weiß, und so kann die Farbe nicht gut als inhaltstragendes Element eingesetzt werden. Es waren an einigen Designelementen Nacharbeiten notwendig. 

Wir hatten also eine Reihe neuer Tickets, die abgearbeitet werden mussten, gleichzeitig aber einen engen Zeitplan bis zum Livegang. Also was tun?

Letztendlich haben wir uns nach reiflicher Überlegung, Analyse und Check der jeweiligen Auswirkungen für einen Kompromiss entschieden: die relevantesten Tickets wurden direkt erledigt, einige andere in die Phase nach dem Livegang verschoben.  

Hier können wir direkt das zweite Learning anbringen: die Entwicklung einer neuen Website ist letztendlich ein Zusammenspiel verschiedener Gewerke, die in ihrer Priorisierung sehr differenziert zu betrachten sind. Wichtig ist, die eigenen Beweggründe und Entscheidungen transparent zu kommunizieren, damit die Akzeptanz trotzdem gegeben ist. 

Livegang

Wir gingen also live mit einer Seite, bei der wir wussten, dass hinsichtlich Barrierefreiheit noch nicht alle Anforderungen erfüllt waren. Warum? Wie schon erwähnt, mussten wir stetig abwägen zwischen den verschiedenen Anforderungen. Vor allem der Sicherheitsaspekt hat uns getrieben, möglichst zügig Wordpress abzuschalten und durch ein Headless CMS abzulösen.

Entsprechend sind wir bewusst mit einer – aus Accessibility-Perspektive – suboptimalen Seite gestartet. Dabei haben wir allerdings ein Thema falsch eingeschätzt. Uns war bewusst, dass der Zoom der Website noch nicht funktionierte, und wir wollten dies später beheben. Uns war aber nicht klar, wie viele unserer Kolleg*innen (und daraus lässt sich auch die entsprechende Ableitung für unsere User treffen) mit Setups arbeiten, bei denen sich dies negativ auf das Leseerlebnis auswirkt. Je nach Bildschirmauflösung war die Seite zu klein oder zu groß – und das konnte vom User nicht angepasst werden. Wir haben hier schnellstmöglich reagiert und konnten schon nach kurzer Zeit eine zoomfähige Variante einspielen.

Interessanterweise trat diese Erkenntnis nicht in unserer – vor dem Livegang durchgeführten – Beta-Phase mit verschiedenen Testusern auf. Können wir hieraus ein Learning ableiten? Klar: die Gruppe der Testuser sollte eine größere Bandbreite abdecken, bezogen auf die unterschiedlichsten Kriterien wie Ausstattung, Rolle im Unternehmen und damit unterschiedlichen Blickwinkeln auf die Website. Dabei sollten wir auch auf Bildschirmauflösungen und Einschränkungen achten.

Alle noch nicht erledigten Accessibility-Bugs wurden im Backlog priorisiert, um sie in den nächsten Wochen abzuarbeiten. Die Reihenfolge basierte dabei vor allem auf den Auswirkungen auf die Lesefähigkeit der Seiten. 

Kontinuierliche Verbesserung

“Erstens kommt es anders und zweitens als man denkt.”

Ihr kennt das vielleicht auch – bei einer Website ist man nie fertig. Neben eventuell nachträglich auftretenden Bugs kommen bereits neue Anforderungen von verschiedenen Seiten: Der Content muss angepasst und kulturelle und soziale Themen berücksichtigt werden. Außerdem fordert oder ermöglicht die technische Entwicklung weitere Verbesserungen. 

Also konkurrierten unsere Accessibility-Tickets mit vielen anderen Tickets. Und das tun sie zum Teil immer noch.

Eine Herausforderung war und ist das Zusammenspiel der verschiedenen Akteure und Systeme, was uns teilweise wieder zurückgeworfen hat. Beispiel Überschriften: Für die Inhalte sind Kolleg*innen aus unterschiedlichsten Abteilungen zuständig. Wenn da Überschriftenlevel nicht korrekt gesetzt werden, landen diese 1:1 so in der Website. Wird beispielsweise eine Überschrift Ebene 1 (<h1>) außer im Titel auch noch mitten im Text gesetzt, ist dies sowohl für SEO als auch für die Barrierefreiheit schädlich. Hier muss also noch mehr Aufklärung in Richtung der Content-Lieferanten betrieben werden.

Die Arbeit an unserer Website basiert auf kontinuierlich wiederkehrenden Ticketpriorisierungen. Dabei steigt aber das Thema Barrierefreiheit mittlerweile in der Priorisierung, denn der Bedarf wird immer größer. Also arbeiten wir stetig weiter und nähern uns langsam aber sicher einem Zustand, mit dem wir zufrieden sein können.

Da uns barrierefreie Seiten sehr wichtig sind, wird die Website auch in Zukunft wiederholt Checks unterzogen, bei denen es bestimmt wieder neue Erkenntnisse gibt. Dann gibt es neue Tickets, diese werden wieder priorisiert und so weiter – ihr kennt das ja ;-)

Fazit

Die verschiedenen Learnings haben wir ja schon erwähnt, aber die wichtigsten möchten wir hier noch einmal herausstellen:

• Barrierefreiheit muss von Beginn an mitgedacht werden.
  Wir hätten uns Arbeit und Kosten sparen können, wenn wir Barrierefreiheit von Anfang an noch besser mitgedacht und einen größeren Fokus darauf gelegt hätten. 
• Barrierefreiheit ist komplex und muss nachhaltig von allen mitgedacht werden. 
  Die Komplexität dieses Themas ist nicht zu unterschätzen. Es ist ein Zusammenspiel von Technik, Content und Design und erfordert entsprechend gute Abstimmungen.
• Barrierefreiheit ist nie fertig.
  Bei jeglicher Änderung an der Seite muss Barrierefreiheit wieder berücksichtigt werden. 

Wir bleiben auf jeden Fall an dem Thema dran. Sollte euch dazu etwas an unserer Website auffallen oder wollt ihr euch zum Thema generell mit uns austauschen, sprecht uns gerne an.