Automatisierte Testtools vs. Handarbeit

Ist die Seite Bayern.de barrierefrei, ja oder nein? Diese Frage haben sich mehrere Parteien im Rahmen eines Feldversuchs gestellt, um verschiedene Werkzeuge zur Einschätzung der Barrierefreiheit gegenüberzustellen. Während dieser Artikel vor allem den manuellen Test und dessen Ergebnisse behandelt, hat Thomas Heilmann die automatisierten Tests und den Vergleich zum manuellen Test dokumentiert.

Automatisierte Testtools taugen nichts

Als offizieller Prüfer des BIK-Tests und Entwickler des umfassenden Usability- und Accessibility-Tests „Barriere-Check Pro“ ist Testen sozusagen mein Täglich-Brot. Natürlich verwendet man für Teilbereiche des Testens Werkzeuge. Angefangen beim Color Contrast Analyzer über diverse Browser-Erweiterungen, wie der Web Developer Toolbar oder der Web Accessibility Toolbar (WAT) von der Paciellogroup bis hin zum W3C-HTML-Validator und diversen nützlichen Bookmarklets. Ohne solche Werkzeuge wäre man als Tester de facto aufgeschmissen.

Aber wenn man als Tester ohnehin auf Werkzeuge angewiesen ist, kann man die diversen Werkzeugen dann nicht in einem Werkzeug bündeln und dann automatisieren? Das ist eine nahe liegende Fragestellung. Ich bin der festen Überzeugung, automatisierte Testtools taugen nichts. Sie können eine gute Unterstützung sein, mehr aber auch nicht. Kürzlich ist mir ein Lighthouse Accessibility Report von Google (https://developers.google.com/web/tools/) in die Hände gefallen, darin steht (frei übersetzt) folgender Satz „Diese Accessibility Checks zeigen Möglichkeiten auf, die Barrierefreiheit ihrer Web Anwendung zu verbessern. Nur ein Teil von Accessibility Problemen kann automatisch erkannt werden. Deshalb ist manuelles Testen ebenfalls empfohlen“. So kann man das sogar stehen lassen. Übrigens der genannte Report hatte der getesteten Anwendung 100 Prozent Accessibility attestiert. Wohl dem, der die zuvor genannte Einschränkung nicht übersehen hat. Denn die 100 Prozent beziehen sich natürlich nur auf die automatisch testbaren Bereiche. Die Anwendung selbst war weit (sehr weit) von Barrierefreiheit entsprechend der Richtlinien entfernt.

Bayern.de im BITV/WCAG Selbstbewertungs-Test

Für das Experiment „Automatisierte Testtools vs. Handarbeit“ habe ich mich bereit erklärt, für den Bereich „Handarbeit“ gerade zustehen. Ich habe für meinen Test aus verschiedenen Gründen die Vorlage der „BITV/WCAG Selbstbewertung“ genutzt (https://testen.bitv-test.de/selbstbewertung/). Zum einen hat das Selbstbewertungsformular von BIK den Vorteil, dass das Ergebnis einem BIK-Test Ergebnis entspricht (wenn man die Prüfschritte richtig durchläuft und korrekt bewertet). Zum anderen sind die Prüfschritte, deren Anleitung und die zugrunde gelegt Werkzeugliste öffentlich (https://testen.bitv-test.de/index.php?a=dl), so dass jeder das Ergebnis auch nachvollziehen kann. Last but not least hatte ich dort sowieso schon ein Benutzerkonto, so dass ich die Vorlage gut abspeichern und das Ergebnis somit dokumentieren konnte.

bayern.de – schlecht zugänglich

Vorneweg, für das Experiment habe ich nur die Startseite getestet. Theoretisch ist es möglich, dass dadurch das Ergebnis verzerrt ist. Normalerweise werden zwischen vier und sechs Seiten exemplarisch für einen Test herangezogen. Dadurch kann das Ergebnis besser, aber auch schlechter werden. Die Einschätzung „schlecht zugänglich“ gilt für die Startseite und explizit für die Inhalte zum Prüfzeitpunkt am 03.05.2018. Eine Bewertung nach WCAG müsste „nicht konform“ lauten. Die Punktzahl im BIK-Test läge bei 75,75 Punkten. Wie gesagt, ich habe das Selbstbewertungsformular verwendet. Es hat für diesen Test also keinen Zweitprüfer von BIK gegeben. Und auch wie sonst bei abschließenden Tests von BIK keinen Qualitätssicherer. Das Ergebnis ist also kein offizielles BIK-Testergebnis, sondern spiegelt nur meine persönliche Meinung wieder. In den verschiedenen offiziellen BIK-Tests, die ich in der Vergangenheit durchgeführt habe, lag die Abweichung zu Zweitprüfer und/oder Qualitätssicherung im Durchschnitt bei etwa vier Punkten, sodass bei einer milderen Bewertung auch eine Punktzahl von knapp über 80 denkbar wäre. 90plus oder mehr, was für eine gute Zugänglichkeit stehen würde, halte ich für ausgeschlossen.

Ergebnis der Selbstbewertung im Detail

Nachfolgend finden Sie die Ergebnisse des ausführlichen Tests. Zu diesem Zeitpunkt habe ich noch keine Kenntnis darüber gehabt, wie die Testergebnisse der automatisierten Tools ausgefallen sind. Prüfschritte, die von mir als erfüllt oder nicht anwendbar bewertet worden, finden sich in der nachfolgenden Bewertung nicht wieder.

Nicht erfüllt sind 5 Prüfschritte

1.1.1a Alternativtexte für Bedienelemente

Die grafischen Links für die Rubrik „Bayern“ haben keine Alternativtexte und auch sonst sind die Links leer. Der Text darunter, Berlin, Brüssel, Welt, ist nicht verlinkt. Das gilt auch für den Bereich „Leitung“ mit den drei Porträts in der rechten Spalte unter Kontakt.

Viele Grafiken, die eigentlich Hintergrundbilder sein müssten, haben redundante Alternativtexte, was dazu führt, dass Linknamen doppelt und dreifach vorgelesen werden können. Beispiel-Link „Top-Video“ mit Link-Title „Zum Top-Video auf YouTube“ und Bild mit alt=“Zum Top-Video auf YouTube“ und title=“Zum Top-Video auf YouTube“ … viermal das Gleiche. Dieses Problem tritt an verschiedenen Stellen auf.

Ein weiteres Problem ist, dass der Alternativtext für grafische Funktionselemente sich nicht dem Status anpasst. Beispielsweise der Alternativtext Für den Start-Stop-Button im Presse-Ticker, der immer alt=“Presseticker pausieren“ lautet – Egal, ob das Funktionselement auf Pause oder Start steht.

1.3.1a HTML-Strukturelemente für Überschriften

Die Überschriftenstruktur ist technisch gesehen korrekt, was die Outline betrifft. Allerdings bestehen die ersten sechs Überschriften aus <h1> Metanavigation – Service-Menue <h2>Suche <h1>mobile Suche <h1>Haupt-Menue <h2>Logo der Bayerischen Staatsregierung <h1>Haupt-Menue … zumindest wenn man CSS abschaltet. Diese versteckten Überschriften sind gut gemeint, stammen aber aus einer Zeit, in der ARIA noch nicht so gut unterstützt wurde, um Seitenbereiche ausreichend zu kennzeichnen. Dezent eingesetzt sind sie immer noch ein probates Mittel, um Seiten vor allem für blinde Nutzer „aufzuräumen“. In der hier eingesetzten Art und Weise ist das auf gut deutsch „Käse“.

Auch die Bezeichnung von Überschriften ist nicht immer hilfreich. Beispielsweise die versteckte Überschrift „Banner“ für den Logo-Slider über dem Footer. Das ist für blinde Menschen keine hilfreiche Überschrift.

Die versteckte Überschrift <h2 class=“unsichtbar“>Suche</h2> überschreibt nicht nur die Suche, sondern die ganze grafische Link-Liste zur Schriftvergrößerung, Kontrastumstellung, leichten Sprache und Gebärdensprache. Auch das hilft nicht bei der Orientierung.

1.4.3a Kontraste von Texten ausreichend

Der Farbkontrast ist an vielen Stellen nicht ausreichend. Vor allem die Kombination aus dem Cyan-Blau mit Weiß (008fcf … ffffff) ist mit einem Kontrastverhältnis von 3.6:1 sehr problematisch.

2.1.1a Ohne Maus nutzbar

Sämtliche <a role=“button“>-Elemente scheinen nicht zu funktionieren, weil das href-Attribut fehlt. Dadurch lassen sich alle interaktiven Elemente, wie der Start-Pause-Button, die Weiter-Pfeile, aber auch die erweiterten grafischen Links, für weiterführende Informationen oder um Einstellungen vornehmen zu können, nicht mit der Tastatur bedienen. An dieser Stelle muss man konstatieren, dass sich die (Start)Seite ohne Maus nicht vollständig bedienen lässt.

4.1.1a Korrekte Syntax

Die Ergebnisse des W3C-HTML Validators dürfen sich nur auf vollständige Start- und Endtags, korrekte Verschachtelung, doppelte Attribute sowie nicht eindeutige IDs beziehen. Zum Glück gibt es das WCAG parsing only Bookmarklet, welches die angezeigten Fehler des Validators mit einem Klick darauf reduziert. Es bleiben trotzdem noch genug Fehler übrig, so dass auch der Prüfschritt „korrekte Syntax“ mit nicht erfüllt bewertet werden muss.

Eher nicht erfüllt sind 3 Prüfschritte:

1.1.1b Alternativtexte für Grafiken und Objekte

Hier ist die Frage, ob Bilder einen sinnvollen Alternativtext haben, die den Inhalt des Bildes widerspiegeln. Das ist beim Slider nicht der Fall. Der Alternativtext alt=“Kabinettssitzung am 24. April 2018.“ hat nichts mit dem abgebildeten Motiv zu tun, auch wenn der Termin möglicherweise stimmen mag. Der Alternativtext für Herrn Söder „Das Beste für Bayern“ ist leer.

Manchmal sind die Alternativtexte einfach auch falsch. Beispiel: alt=“Facebook Post“ für alle Bilder der Facebook-Beiträge. Hier wäre ein leerer Alternativtext richtig gewesen. Oder eben die Beschreibung dessen, was abgebildet ist. Aber kein generischer Alternativtext.

Auch die In der Regel vermutlich automatisch erzeugte Doppelung von Alternativtext und Title-Attribut führen zu massiven Barrieren. Beispiel: alt=“v.l.: Georg Eisenreich, Staatsminister für Digitales, Medien und Europa begrüßt Daniel Plato, Minister für kommunale Sicherheit, Westkap, in der Bayerischen Staatskanzlei.“ title=“v.l.: Georg Eisenreich, Staatsminister für Digitales, Medien und Europa begrüßt Daniel Plato, Minister für kommunale Sicherheit, Westkap, in der Bayerischen Staatskanzlei.“ … da ist es leider kein Wunder, dass das title-Attribut keinen guten Ruf hat und von Screenreader-Nutzern häufig abgeschaltet wird.

1.1.1c Leere alt-Attribute für Layoutgrafiken

Leere Alt-Attribute wurden an Stellen verwendet, wo sie nicht leer bleiben durften. An anderer Stelle wiederum wurden Alternativtexte geschrieben, wo Hintergrundbilder oder leere Alternativtexte die richtige Wahl gewesen wäre – wie in den Prüfschritten 1.1.1a und 1.1.1b bereits ausführlich an Beispielen geschildert.

2.4.7a Aktuelle Position des Fokus deutlich

Der Tastaturfokus ist nicht spezifiziert. Normalerweise würde auch der Systemkranz ausreichen, wenn dieser nicht unterdrückt wird. Allerdings ist die Farbkombination im Footer-Listen-Menü nicht mit dem Systemkranz in Google Chrome kompatibel. De facto ist hier der Tastaturfokus unsichtbar. Deshalb muss man an dieser Stelle feststellen, dass die aktuelle Position des Fokus nicht durchgängig deutlich ist. Im Firefox und Internet Explorer sieht es etwas besser aus, wobei auch im Internet Explorer der Systemkranz im Footer nicht ausreichend ist.

Nicht anwendbar sind 15 Prüfschritte (Kommentare ohne Punktabzug):

1.2.5a Audiodeskription für Videos

In der Bewertung zum Prüfschritt 1.2.3a Audiodeskription oder Volltext-Alternative für Videos gab es schon eine kleine Abwertung. Deshalb hier keine zusätzliche Abwertung.

1.3.1h Beschriftung von Formularelementen programmatisch ermittelbar

Das Suchformular im Kopfbereich ist als einzelnes Element ausreichend gelabelt. Einziger Kritikpunkt wäre, dass der Submit-Button fehlt und an der Stelle das nicht angemessene Link-Element verwendet wurde.

2.4.8a Position im Webauftritt klar

Der Prüfschritt 2.4.8a Position im Webauftritt klar ist aufgrund der Tatsache, dass hier nur die Startseite getestet wurde, nicht anwendbar. An der Stelle sei allerdings angemerkt, dass die Startseite mit dem verlinkten Logo auf sich selber verweist, was nicht den Richtlinien entspricht. Insgesamt reichen die Informationen auf der Startseite alleine aber nicht aus, um diesen Prüfschritt seriös mit einem Punktabzug zu bewerten.

Erfüllt sind 18 Prüfschritte: (Kommentare ohne Punktabzug):

2.2.2a Bewegte Inhalte abschaltbar

Die Spezifikationen fordern für alle sich selbständig bewegende Elemente eine Funktion, um die Bewegung anzuhalten. Weiterhin fordern die Spezifikationen, dass diese Funktion deutlich sichtbar am Seitenbeginn oder direkt oberhalb des bewegten Inhalts platziert ist. In der Praxis befinden sich solche Elemente allerdings immer unterhalb oder am Ende eines Multimediaelements. Vor allem wenn man an Video-Player denkt, würde ich persönlich das auch als erwartungskonform bezeichnen. Wie dem auch sei, für die Position müsste man eigentlich einen Punkteabzug vornehmen. Das entspricht aber nicht meiner persönlichen Sichtweise, deshalb lasse ich das an dieser Stelle außen vor. Ist ja nur eine Selbstbewertung und kein offizieller BIK-Test.

2.4.2a Sinnvolle Dokumenttitel

Da für den Artikel zum Vergleich von verschiedenen Test-Frameworks nur die Startseite von bayern.de herangezogen wurde, muss man für diesen Prüfschritt die Bewertung „erfüllt“ wählen. Allerdings lässt sich dieser Prüfschritt eigentlich erst dann korrekt bewerten, wenn man eben verschiedene Seiten testet. Besser wäre hier vielleicht auch „Bayerisches Landesportal – Startseite“.

3.1.2a Anderssprachige Wörter und Abschnitte ausgezeichnet

Aus unerfindlichen Gründen gibt es vor allem in den versteckten Überschriften für Screenreader-Nutzer denglische Wortzusammensetzungen, die vorgelesen sehr seltsam klingen, beispielsweise Service-Menue oder Haupt-Menue. Ansonsten ist dieser Prüfschritt aber zumindest für die Startseite erfüllt – es sei denn ich habe was übersehen.

3.2.3a Konsistente Navigation

Auch dieser Prüfschritt ist nur anhand der Startseite schlecht kontrollierbar. Erfahrungsgemäß führt aber gerade dieser Bereich am wenigsten zu Problemen, weil sich Navigationen zumeist einheitlich präsentieren.

Eher erfüllt sind 4 Prüfschritte:

1.2.3a Audiodeskription oder Volltext-Alternative für Videos

Es gibt Videos, in denen neben dem gesprochenen Wort auch Bilder gezeigt werden, die die Situation illustrieren. Beispielsweise bei dem Video „Empfang der bayerischen Olympioniken“. Hier fehlt eine Audiodeskription oder Volltext-Alternative. Konzeptionell sind sie offensichtlich auch nicht vorgesehen. Da dies aber nicht alle Videos betrifft, gibt es dafür die Bewertung „eher erfüllt“.

1.3.3a Ohne Bezug auf sensorische Merkmale nutzbar

In der erforderlichen YouTube Datenschutz-Aktivierung (um sich YouTube-Videos überhaupt anzeigen lassen zu können) findet sich folgender Satz „Sie können mit einem Klick dauerhaft das Abspielen aktivieren oder im Datenschutzschalter rechts die Aktivierung auch dauerhaft wieder rückgängig machen“. Damit referenziert dieser Text Informationen, deren räumliche Position (rechts) man sehen können müsste, was natürlich vor allem für blinde Menschen nicht der Fall ist. Da dies sowohl bei den Top-Videos als auch bei den darunter liegenden Videos jeweils der Fall ist, gibt es hier einen kleinen Abzug in der Bewertung.

1.4.5a Verzicht auf Schriftgrafiken

In der rechten Spalte unter „Themen“ verwendet die Startseite Schriftgrafiken. Das ist durchaus ein Problem, denn diese Schriftgrafiken können vom Benutzer nicht individuell in Bezug auf Farbe oder Größe angepasst werden.

2.4.4a Aussagekräftige Linktexte

In der Spalte unter „Themen“ befinden sich immer doppelte Links. Zum einen die Bilder, die mit Alternativtexten und Title-Attribut korrekt ausgezeichnet wurden. Allerdings findet sich darunter immer auch nochmal ein gedoppelter, leerer Link, der vor allem für Screenreader und Tastaturnutzer bemerkbar wird.

Einige grafische Links haben keinen so genannten Accessibility-Name und eben auch keinen Alternativtext. Das wurde allerdings schon im Bereich Alternativtexte für Funktionselemente bewertet.

Der „Vorlesen“ Link von Readspeaker lautet ebenfalls immer gleich, so dass sich der Bezug, was vorgelesen werden soll, nur durch den Kontext in der Reihenfolge erschließt.

Der Link-Name alt=“Nächstes Bild ansteuern“ wiederholt sich ebenfalls und gibt keinen Aufschluss darüber, welches Bild nun angesteuert wird. Ähnlich verhält es sich mit dem sich wiederholenden Alternativtext „Zurück blättern und Weiter blättern“.

Die verlinkte Überschrift in den Facebook-Posts „Unser Bayern“ steht ebenfalls über jedem Post und gibt keinen individuellen Aufschluss darüber, was sich dahinter verbirgt.

Die Links unter „Fotos“ führen auf eine neue Seite, direkt in ein modales Fenster. Vor allem für blinde Menschen braucht es hier mehr Vorwarnung, um sich dann auf der folgenden Seite mit dem modalen Fenster auch orientieren zu können. Insgesamt finden sich alleine auf der Startseite einige Linktexte, die in der Form nicht aussagekräftig sind und deutlich Optimierungspotenzial mit sich bringen.

Teilweise erfüllt sind 4 Prüfschritte:

1.3.1b HTML-Strukturelemente für Listen

Das <div class=“jcarousel-pagination“ … besteht nur aus hintereinander gereihten Links. Diese müssen definitiv als Listen organisiert sein, was sie nicht sind. Gleiches gilt für die Paginierung im <div class=“fbcarousel-pagination“ …

Genau genommen ist die Themenliste auf der rechten Seite auch eine grafische Link-Liste, was aber nicht so umgesetzt wurde. Da aber ansonsten relativ durchgängig mit Listen zur Strukturierung gearbeitet wurde, kann man hier vielleicht großzügig sein und die Bewertung „teilweise erfüllt“ vornehmen.

Die Verwendung einer Definitionsliste zur Strukturierung des mehrspaltigen in Ausklappmenüs in der Hauptnavigation macht keinen Sinn und lässt zudem das <dd>-Element leer.

Das Suchformular im Kopfbereich als Teil der grafischen Link-Liste zu organisieren <li id=“suchfeld“> und <li id=“suchicon“> hat wenig mit einer semantischen Entscheidung zu tun. Das Suchfeld und das Suchicon als jeweils einen Listenpunkt anzulegen macht hier auch keinen Sinn.

1.4.4a Text auf 200% vergrößerbar

Dieser Test wird bei einer Auflösung von 1290 mal 768 Pixeln durchgeführt. Zumeist erscheint in dieser Ansicht schon (zumindest teilweise) die mobile Ansicht. Dies ist auch bei bayern.de der Fall. Grundsätzlich funktioniert die Vergrößerung. Allerdings ergibt sich bei den geforderten 200 Prozent Vergrößerung im Test ein horizontaler Scrollbalken, der vor allem für Menschen mit motorischen Behinderungen Probleme verursachen kann. Auf bayern.de ist dadurch beispielsweise der Pause-Button der Pressemitteilungen nicht erreichbar. Gleiches gilt für einige grafische Service-Links sowie der Gefällt-mir-Link.

Das grafische Element zur Schriftvergrößerung am Seitenanfang hätte an dieser Stelle ein Ausweg sein können. Allerdings bewegt sich die Schriftvergrößerung hier im Nanobereich und führt zudem auch noch zu Überlagerungen, beispielsweise bei den Pressemitteilungen. Das Element zur Schriftvergrößerung taugt hier de facto nichts.

2.4.1a Bereiche überspringbar

Die Spezifikationen bieten für die Anforderung der Übersprungnavigation verschiedene Möglichkeiten an: Wenn Seitenbereiche entweder durch eindeutige und strukturierende Überschriften oder durch Sprunglinks oder mithilfe von HTML5 Strukturelementen und/oder Aria Landmark Roles erschlossen sind, gilt der Prüfschritt als erfüllt. HTML5 Seitenstruktur-Elemente gibt es auf bayern.de nicht. Gleiches gilt für Landmark Roles. Auch Skip-Links am Seitenanfang sind nicht vorhanden. Für motorisch behinderte Menschen, die auf Tastatursteuerung angewiesen sind, ist die Seite vor allem aufgrund der technischen Umsetzung der Hauptnavigation mit den mehrfach verschachtelten Flyout-Menüs de facto nicht benutzbar. Auch der massive Footer ist eine große Barriere. Screenreader-Nutzer können die Seite zumindest anhand der Überschriften überspringen und so leichter navigieren. Allerdings muss man auch hier feststellen, dass vor allem die an sich gut gemeinten, versteckten Überschriften für Screenreader-Nutzer noch Optimierungsbedarf haben. Anhand der Spezifikationen kann man argumentieren, dass dieser „2.4.1a Bereiche überspringbar“ erfüllt ist. Für blinde Nutzer mag das zutreffen. Alle anderen Tastaturnutzer haben das Nachsehen. Deshalb gebe ich dafür nur die Bewertung „teilweise erfüllt“ ab, was aus meiner persönlichen Sicht eine sehr milde Bewertung ist. Im Barriere Check Pro gäbe es dafür von mir einen „Daumen runter“.

4.1.2a Name, Rolle, Wert verfügbar

Wie schon im Prüfschritt 1.1.1a Alternativtexte für Bedienelemente festgestellt gibt es das Problem, dass der Alternativtext für grafische Funktionselemente sich nicht durchgängig dem Status anpasst. Beispielsweise der Alternativtext für den Start-Stop-Button im Presse-Ticker, der immer alt=“Presseticker pausieren“ lautet – egal, ob das Funktionselement auf Pause oder Start steht. Gleiches gilt auch für den an vielen Stellen eingesetzten, grafischen Pfeil mit dem Alternativtext „Klicken, um mehr XYZ anzuzeigen“. Zum einen ändert sich der Status nicht, wenn man den Link klickt und mehr angezeigt wird, der Alternativtext bleibt gleich. Zum anderen beschreibt der Alternativtext nicht, was sich hinter der Funktion verbirgt. Soll der Link eine neue Seite (beispielsweise mit mehr Videos oder mehr Fotos) aufrufen oder soll der Link ein Akkordeon-Menü öffnen oder schließen? Hier fehlt definitiv etwas Aria-Anreicherung (zum Beispiel: aria-expanded=“true“). Auch das ist gegebenenfalls sogar relativ milde bewertet.

Mein Fazit

Da ich, wie gesagt zu dem Zeitpunkt, da ich diese Zeilen hier schreibe, die Ergebnisse der automatischen Tests noch nicht kenne, bin ich darauf sehr gespannt. Meine feste Überzeugung ist, dass kein automatisiertes Tool Ergebnisse liefern kann, die zukünftig eine WCAG Konformität entsprechend der EU-Richtlinie 2102 gerichtsfest bestätigen können. Persönlich erschrocken bin ich über die vorgefundenen Barrieren auf der Startseite von bayern.de. Da ist auf jeden Fall noch Handlungsbedarf. Einen kostenlosen Test haben die Betreiber mit diesem Artikel jetzt auf jeden Fall vorliegen. Vielleicht machen Sie was draus.

Jörg Morsbach, Diplomdesigner und Kommunikationswirt (WAK), betreibt bereits seit 2003 die Düsseldorfer Agentur anatom5 und macht sich aus Überzeugung für universelles Design und einen weit reichenden Inklusionsgedanken stark. anatom5 wurde vielfach für Barrierefreiheit ausgezeichnet. Seit Anfang 2017 ist Jörg Morsbach  zugelassener Erstprüfer des BITV-Test (BIK-Test). Sein heimliches Steckenpferd ist die Suchmaschinenoptimierung.

Zum Portfolio von anatom5 gehören Internetauftritte und Webapps ebenso, wie barrierefreie PDF-Dokumente und Übersetzungen in leichte Sprache. Zudem hat anatom5 mit dem Barriere-Check Pro ein Testverfahren entwickelt, das auch WCAG-Empfehlungen, Best-Practice Lösungen, Aspekte der Usability und Performance sowie BITV-Anforderungen der Priorität 2 berücksichtigt.

Sein Credo lautet:

Ohne Screenreader-Tests und Analysen im Detail ist Testen mit automatisierte Testtools nur das sprichwörtliche „Fischen im Trüben“.