Barrierefreiheit ist kein Nischenthema mehr. Rund 1,3 Milliarden Menschen weltweit sind auf zugängliche digitale Angebote angewiesen. Gleichzeitig fallen über 90 % aller Websites bei grundlegenden WCAG-Checks durch. Das ist kein Randproblem, sondern der Normalzustand. Entsprechend brechen viele Nutzer ab, wenn ein System nicht bedienbar ist – mit direkten Auswirkungen auf Nutzung und Conversion.
Für Liferay-Projekte ist die Ausgangslage grundsätzlich gut. Die Plattform liefert sauberes HTML, unterstützt semantische Strukturen und bringt viele Komponenten mit, die grundsätzlich zugänglich sind. In der Realität entstehen die Probleme aber nicht im Core, sondern im Projekt selbst. Typisch sind fehlerhafte Templates, unsaubere Heading-Strukturen, fehlende ARIA-Attribute oder Navigationen, die sich nicht per Tastatur bedienen lassen. Auch Inhalte spielen eine große Rolle, etwa wenn Redakteure keine Alternativtexte pflegen oder Strukturen zerstören.
Genau hier setzen Tools wie Eye-Able, axe DevTools oder Siteimprove an. Sie helfen dabei, WCAG-Verstöße sichtbar zu machen und Scores zu verbessern, indem sie typische Probleme wie Kontrastfehler, fehlende Labels oder strukturelle Schwächen identifizieren. Gerade in Liferay-Projekten lassen sich solche Tools gut integrieren, um kontinuierlich zu prüfen, ob Templates, Fragmente oder Inhalte regressiv werden.
Wichtig ist aber: Diese Tools lösen das Problem nicht. Sie zeigen Symptome, nicht die Ursache. Wenn Templates strukturell falsch gebaut sind oder Komponenten nicht sauber entwickelt wurden, wird auch ein perfekter Score keine gute Nutzbarkeit erzeugen.
Der entscheidende Hebel liegt daher in der Umsetzung innerhalb von Liferay. Saubere Templates, konsistente Komponenten und klare Content-Regeln machen den Unterschied. Wer das im Griff hat, erreicht WCAG-Konformität vergleichsweise effizient. Wer sich nur auf Tools verlässt, optimiert Zahlen, aber nicht das System.
