Barrierefreiheit richtig bauen: Technische Lehren aus „Web Accessibility“ von Jeremy Chinquist (drunomics GmbH)

Warum dieses Thema jetzt zählt

„Web Accessibility“ ist kein nachträglicher Lack, sondern eine fundamentale Produkteigenschaft. Genau so haben wir die Session „Web Accessibility“ von Jeremy Chinquist (drunomics GmbH) erlebt. Der Zeitpunkt ist brisant: Der European Accessibility Act tritt „später in diesem Monat“ in Kraft, die Durchsetzung durch EU-Mitgliedstaaten soll „im Juni 2025“ beginnen. Jeremy machte deutlich, dass Websites sowie Produkte und Services barrierefrei sein müssen – nicht nur aus rechtlicher Perspektive, sondern aus Respekt gegenüber allen Nutzerinnen und Nutzern.

Er verwies auf eine präzise Definition aus dem Cambridge Dictionary: Barrierefreiheit ist „die Qualität, von allen genutzt werden zu können – einschließlich Menschen mit Behinderungen“. Die Konsequenz ist anspruchsvoll: Ein Produkt muss für Personen ohne Behinderung und Personen mit Behinderung „in gleicher Qualität oder Weise“ nutzbar sein. Ein einfacher Satz – aber, wie Jeremy betonte, mit erheblichem Umsetzungsaufwand verbunden.

Aus unserer DevJobs.at-Perspektive ist das die Kernbotschaft: Barrierefreiheit ist eine Qualitätsdimension. Wer sie früh plant, spart Kosten, reduziert Risiken und liefert bessere Produkte. Genau dieses „früh planen“ zog sich als roter Faden durch die Session.

Das Problemfeld: Qualität für alle, nicht nur Compliance

Jeremy skizzierte Barrierefreiheit nicht als Checkliste zur Gesetzeserfüllung, sondern als Zusammenspiel vieler „kleiner Dinge“, die in Summe die User Experience bestimmen. Diese „kleinen Dinge“ sind konkret messbar – etwa über die Web Content Accessibility Guidelines (WCAG), die in verschiedenen Levels organisiert sind. Wichtiger Hinweis von Jeremy: Er ist „kein Anwalt“; bei rechtlichen Fragen sollte ein Rechtsbeistand konsultiert werden. Als CISO müsse er jedoch wissen, welches WCAG-Niveau für die eigenen Produkte zu unterstützen ist.

Aus dieser Haltung – Verantwortung kennen, Anforderungen identifizieren, Umsetzung priorisieren – leitete Jeremy einen sehr praktischen Blick ab: Es reicht nicht, einzelne Barrieren zu beheben; die Produktarchitektur, das Frontend und der laufende Entwicklungsprozess müssen Barrierefreiheit tragen.

Die technischen Pfeiler: Was Websites laut Session unterstützen müssen

Jeremy nannte mehrere Anforderungen, die zusammen die Grundlage einer barrierefreien Website bilden:

• Screenreader-Unterstützung: Inhalte müssen so strukturiert sein, dass Screenreader die Seite zuverlässig vorlesen können.
• Skip-Links: Es braucht Möglichkeiten, schnell zu zentralen Bereichen zu springen – also „skip links“, um durch den Inhalt zu navigieren.
• Gut strukturierte H-Tags: Überschriftenhierarchien („h-tags“) sollen die Seitenstruktur klar ersichtlich machen und die Navigation erleichtern.
• Fokus-Reihenfolge: Interaktive Elemente müssen in einer logischen Reihenfolge fokussierbar sein.
• Alt-Tags für Bilder: Bilder benötigen Alternativtexte, die ihre Bedeutung vermitteln, wenn das Bild nicht gesehen werden kann.
• Farbkontrast: Inhalte müssen sich klar vom Hintergrund abheben; insbesondere für Menschen mit eingeschränktem Sehvermögen ist ein ausreichender Kontrast entscheidend.

Diese Punkte sind nicht optional; sie „spielen zusammen“. Die Erfahrung zeigt: Wer hier an einem Ende spart, erzeugt an einem anderen Ende neue Hürden. Jeremy betonte, dass all diese Aspekte messbar sind – mit WCAG als Referenzrahmen.

Architektur und Werkzeuge: Früh planen, klug wählen

Eine zentrale Lektion aus der Session: Der kosteneffizienteste Weg zu Barrierefreiheit ist, sie einzuplanen. Jeremy schilderte das Vorgehen am Beispiel des Produkts „Mossball“: Es basiert auf dem Open-Source-CMS Drupal und einem individuellen Frontend auf Basis von Nuxt. Zwei relevante Beobachtungen:

1) Drupal hat Barrierefreiheit eingeplant. Laut Jeremy ist das System in seiner Basis „accessible“ und hat von Anfang an entsprechende Schritte vorgesehen.

2) Dronomics (so sprach Jeremy über sein Umfeld) plante diese Aspekte auch im Frontend. Die Kombination aus einem zugänglichen Fundament (Drupal) und einem bewusst gestalteten Frontend (Nuxt) schafft produktseitig die Voraussetzungen.

Für uns als Redaktion ist das ein klares Architekturmuster: Wähle ein Fundament, das Barrierefreiheit ernst nimmt; gestalte das Frontend so, dass diese Stärken nicht verloren gehen; und plane Barrierefreiheit als Nichtfunktionale Anforderung von Stunde null an.

Interne Audits und kontinuierliche Verbesserung: Ein Prozess, kein Projekt

Jeremy berichtete von einem internen Audit durch Wolfgang Leitner, der bereits Barrierefreiheitsaudits für andere Unternehmen durchgeführt hat. In diesem Audit wurden Stellen identifiziert, an denen Mossball besser werden kann – und Wege, wie diese Verbesserungen über einen längeren Zeitraum gepflegt werden.

Die Wirkung ist unmittelbar: Durch die Änderungen wurde Mossball „besser“. Als das Produkt anschließend für mehrere Kundinnen und Kunden ausgerollt wurde, profitierten diese direkt von den eingebauten Barrierefreiheitsverbesserungen. Und: Wenn neue Verbesserungen entwickelt werden, fließen sie in bestehende Installationen zurück. Das macht Barrierefreiheit nicht nur zum Liefermerkmal, sondern zu einem Wartungsversprechen.

Diese Prozesssicht ist essenziell. Barrierefreiheit „einmalig“ herzustellen, reicht nicht. Content ändert sich, Frontends werden weiterentwickelt, Komponenten kommen hinzu – ohne fortlaufende Pflege entstehen schnell Regressionen. Jeremies Formulierung „wie wir diese Verbesserungen über eine längere Zeitspanne erhalten“ beschreibt genau diese Daueraufgabe.

Externe Validierung und Zertifizierung: Der nächste Schritt

Auf das interne Audit soll ein externer Blick folgen: Jeremy skizzierte die nächsten Schritte als „externes Auditing“ bzw. eine Zertifizierung als barrierefreies Produkt, inklusive der Möglichkeit, das „Logo des WCAG-Standards“ auf dem Produkt zu führen. Dieser Schritt ist mehr als ein Gütesiegel; er ist auch ein Mechanismus zur Vertrauensbildung und zur kontinuierlichen Qualitätssicherung.

Rechtlicher Rahmen: Zuständigkeiten, Fristen, Risiken

Die Session gab eine klar umrissene Orientierung zu Zuständigkeiten und Fristen – ohne die Rolle der Rechtsberatung zu ersetzen:

• In der EU sind die Mitgliedstaaten zuständig für die Durchsetzung des European Accessibility Act.
• Die Durchsetzung „soll im Juni 2025 beginnen“ – also „in den nächsten Wochen“, wie Jeremy formulierte.
• In Österreich können – „abhängig davon, wie Ihr Produkt die Standards erfüllt oder nicht“ – Strafen „von bis zu etwa 80.000 €“ drohen.
• Bestehende Websites haben „etwa fünf Jahre“, bis sie tatsächlich konform sein müssen.
• Websites, die jetzt neu live gehen oder neu gelauncht werden, „sollten von Tag eins an barrierefrei sein“.

Die Botschaft ist klar: Früh starten. Nicht erst, wenn die Frist ausläuft. Besonders bei Relaunches ist Barrierefreiheit kein „Add-on“; sie muss in sämtliche Produktentscheidungen integriert sein.

Eine Produktstrategie in der Praxis: Mossball

Jeremy führte aus, dass Mossball die Barrierefreiheit von Beginn an eingeplant hat – basierend auf Drupal mit einem Nuxt-Frontend. Das interne Audit (Wolfgang Leitner) fungierte als Katalysator: Es zeigte Handlungsfelder auf und legte den Grundstein für ein nachhaltiges Vorgehen. Die bereits gelaunchten Kundinnen und Kunden profitierten unmittelbar von den Verbesserungen; zukünftige Kundinnen und Kunden erhalten die jeweils neuesten Änderungen; besonders wichtig: Verbesserungen werden auch in bestehende Installationen übernommen.

Dieser Kreislauf – planen, auditieren, verbessern, ausrollen, pflegen – ist die Blaupause, die wir aus der Session mitnehmen.

Praktischer Leitfaden für Engineering-Teams (basierend auf der Session)

Die Session von Jeremy liefert – ohne zusätzliche Annahmen – einen soliden Fahrplan, der sich direkt in Engineering-Workflows übersetzen lässt:

1) Verbindlichkeit herstellen

• Barrierefreiheit als Qualitätsziel definieren: „gleiche Qualität oder Weise“ der Nutzung für alle.
• Rechtlichen Rahmen prüfen: European Accessibility Act, nationale Durchsetzung, Fristen. (Jeremys Hinweis: Bei Fragen eine Rechtsberatung einbeziehen.)

2) Architektur passend wählen

• Fundament: Ein System verwenden, das Barrierefreiheit in der Basis berücksichtigt. In der Session wurde Drupal genannt.
• Frontend bewusst gestalten: Ein Custom-Frontend – im Beispiel Nuxt – so aufbauen, dass zentrale Anforderungen (Screenreader-Unterstützung, Skip-Links, H-Tags, Fokus-Reihenfolge, Alt-Texte, Farbkontrast) eingehalten werden.

3) Frühe Planung als Kostenhebel nutzen

• Barrierefreiheit nicht nachträglich „hinzufügen“. Jeremys Erfahrung: Der kosteneffizienteste Weg ist, sie zu Beginn einzuplanen.

4) Audit durchführen

• Internes Audit: Personen mit Erfahrung – wie im Beispiel Wolfgang Leitner – einbinden, um Verbesserungsbereiche zu identifizieren.
• Fokus auf Nachhaltigkeit: Maßnahmen so anlegen, dass Verbesserungen über längere Zeit erhalten bleiben.

5) Kontinuierliche Auslieferung von Verbesserungen

• Neue Kundinnen und Kunden erhalten jeweils den aktuellen Stand.
• Verbesserungen zurück in bestehende Installationen spielen.

6) Externe Validierung vorbereiten

• Externes Auditing oder Zertifizierung anstreben, um die Erfüllung der Standards sichtbar zu machen (inklusive der Option, das WCAG-Logo zu führen).

Tiefer in die Technik: Was hinter den Einzelelementen steckt

Ohne über die Session hinauszugehen, lassen sich die von Jeremy genannten Elemente technisch einordnen:

• Screenreader-Unterstützung: Inhalte müssen maschinenlesbar und strukturiert sein. Das betrifft Layout, semantische Struktur und die Art, wie Informationen aufbereitet werden, damit sie vorgelesen werden können.
• Skip-Links: Eine Navigationsabkürzung, um schnell in zentrale Bereiche zu springen und nicht jeden Navigationsblock linearfokussieren zu müssen.
• H-Tags: Eine logische Hierarchie (h1, h2, h3, …) bildet die Dokumentstruktur ab und macht sie für Nutzerinnen und Nutzer – und für Hilfstechnologien – erfassbar.
• Fokus-Reihenfolge: Interaktive Elemente sollen in einer nachvollziehbaren Reihenfolge fokussierbar sein, damit die Seite sinnvoll „durchlaufen“ werden kann.
• Alt-Tags: Bilder brauchen Alternativtexte, die das beschreiben, was andere sehen. So werden Informationen nicht visuell-exklusiv vermittelt.
• Farbkontrast: Inhalte müssen erkennbar bleiben, auch wenn die Wahrnehmung eingeschränkt ist. Kontrast ist hierfür eine zentrale Stellschraube.

Diese Aspekte sind – wie Jeremy betonte – messbar entlang der WCAG. Sie sind aber auch operativ: In Tickets, Code-Reviews und Content-Guidelines lassen sie sich konkret verankern.

Was wir aus der Session gelernt haben

• Barrierefreiheit ist ein Qualitätsversprechen, das für alle Nutzerinnen und Nutzer gilt – nicht nur ein juristischer Zwang.
• Die „kleinen Dinge“ (Screenreader, Skip-Links, H-Tags, Fokus, Alt-Texte, Kontrast) entscheiden in Summe über die Nutzbarkeit.
• WCAG bietet einen Messrahmen; welches Niveau anvisiert wird, ist eine bewusste Entscheidung – und rechtlich relevant. (Jeremy: kein Anwalt; bei Bedarf rechtlich beraten lassen.)
• Früh planen spart Kosten und reaktive Arbeit.
• Ein zugängliches Fundament (Drupal) plus bewusst gestaltetes Frontend (Nuxt) sind ein tragfähiges Muster.
• Interne Audits schaffen Transparenz und liefern konkrete, nachhaltige Maßnahmen.
• Verbesserungen müssen fortlaufend ausgerollt und gepflegt werden – auch bei bestehenden Kundinnen und Kunden.
• Externe Audits und Zertifizierungen stärken Vertrauen und Sichtbarkeit.
• Der European Accessibility Act wird von Mitgliedstaaten durchgesetzt; ab Juni 2025 soll die Durchsetzung beginnen. In Österreich können bei Nichteinhaltung Strafen bis „etwa 80.000 €“ drohen.
• Bestehende Websites haben „etwa fünf Jahre“, doch neue Launches sollten von Tag eins an barrierefrei sein.

Für wen diese Erkenntnisse besonders relevant sind

• Produktverantwortliche, die Qualität und Compliance zusammenbringen müssen.
• Engineering-Teams, die Frontend, Content und Navigation konsistent zugänglich gestalten.
• CMS-Integratoren, die die Stärken eines Systems wie Drupal ausspielen wollen.
• Unternehmen, die vor einem Relaunch stehen und Barrierefreiheit von Beginn an einplanen wollen.

Ressourcen aus der Session

Jeremy verwies in seinem Talk auf folgende Anlaufstellen:

• Produkt: mossball.com
• Unternehmenswebsite: dronomics.com

Außerdem erwähnte er, dass ein Blogpost auf dronomics.com „letzte Woche“ im Newsletter der Drupal Association gefeatured wurde.

Fazit: Barrierefreiheit ist ein Entwicklungsprinzip

Die Session „Web Accessibility“ von Jeremy Chinquist (drunomics GmbH) hat die Essenz auf den Punkt gebracht: Barrierefreiheit ist die Fähigkeit, „von allen genutzt werden zu können – einschließlich Menschen mit Behinderungen“. Die technische Umsetzung beginnt bei den Grundlagen – Screenreader, Skip-Links, H-Tags, Fokus, Alt-Texte, Kontrast – und setzt sich fort im Prozess: planen, auditieren, verbessern, zertifizieren. Die rechtlichen Fristen verleihen dem Thema Dringlichkeit; die Produktqualität liefert die eigentliche Motivation.

Mossball dient hier als praktisches Beispiel: auf Drupal basierend, mit einem Nuxt-Frontend, intern auditiert, kontinuierlich verbessert und mit dem Ziel externer Zertifizierung. Wer jetzt handelt, liefert eine bessere User Experience – und ist rechtlich auf der sicheren Seite, wenn die Durchsetzung in den Mitgliedstaaten startet.

Die klare Empfehlung aus der Session: Wenn eine Website heute neu live geht, sollte sie „von Tag eins an“ barrierefrei sein. Wer bestehende Websites betreibt, hat Zeit – „etwa fünf Jahre“ – aber profitiert davon, neue Anforderungen frühzeitig einzuplanen. Das spart Aufwand, reduziert Risiko und macht digitale Produkte für alle besser.

• 

  

  mossbo Cloud CMS Ecosystem

  Wolfgang Ziegler von drunomics gibt in seinem devjobs.at TechTalk einen Überblick über die grundlegenden Funktionen von mossbo und welche Benefits es im Vergleich zu anderen CMS' gibt.

  Jetzt ansehen
• 

  

  Professionelle Web Entwicklung aus Österreich

  Oliver Berndt von drunomics zeigt in seinem devjobs.at TechTalk die Kernkompetenzen von dem Unternehmen und wie sie mit Drupal arbeiten.

  Jetzt ansehen
• 

  

  Security- und Risiko-Management

  Jeremy Chinquist von drunomics erzählt in seinem devjobs.at Interview darüber, wie das Unternehmen mit Security- und Risiko-Management umgeht und welche Standards eingehalten werden.

  Jetzt ansehen
• 

  

  Agile Development at drunomics

  Jeremy Chinquist von drunomics spricht in seinem TechTalk über die Grundgedanken der agilen Entwicklungsmethode, welche beim Developer Team im Unternehmen zum Einsatz kommt.

  Jetzt ansehen

• 

  

  Sinduri Guntupalli, Product Manager bei drunomics

  Sinduri Guntupalli von drunomics spricht im Interview über ihren technischen Background und das Besondere an der Arbeit mit Drupal.

  Jetzt ansehen