kurz gefasst:
nachfolgend geben wir einen strukturierten überblick über den ablauf einer accessibility prüfung mit dem ziel den aktuellen stand der barrierefreiheit zu ermitteln.
der umfang und der zu tätigende aufwand für die prüfung der barrierefreiheit steigt und fällt zum einen je nach ziel-level: a-aa-aaa. weiters definiert sich der umfang auch durch den funktions- und inhaltsumfang der zu prüfenden webseite. festzuhalten ist, dass der level aa als gesetzliche grundlage festgelegt worden ist. dies ermöglicht als guter kompromiss zwischen der optimalen barrierefreien webseite und leistbarem aufwand die herstellung der barrierefreiheit für viele webbenutzer.
hier eine kurze darstellung der wcag regeln
| version | prinzipien | richtlinien | erfolgs-kriterien | für a | für aa | für aaa |
|---|---|---|---|---|---|---|
| 2.0 | 4 | 12 | 61 | 25 | 38 | 61 |
| 2.1 | 4 | 13 | 78 | 30 | 50 | 78 |
| 2.2 | q1-2023 |
vorgehensweise
definition testsample
um die zu testenden seiten auszuwählen, analysieren wir die unterschiedlichen inhaltsarten der webseite. beispiele hierfür sind:
- standardseiten
- blogbeiträge einzelseiten, blogbeiträge archivseiten
- formularseiten
- shop produkt einzelseiten, shop kategorieseiten, shop produkt archivseiten
- custom post types, einzel- und archivseiten
- weitere funktionen, z.b. eventbuchung, terminreservierung u.a.
aus den unterschiedlichen inhaltsarten werden repräsentative url`s ausgewählt und als testsample definiert.
automatisierte tests
festzuhalten ist, dass es nicht das eine tool gibt, das verlässlich alle abweichungen zu den geforderten eigenschaften aufzeigt. die ergebnisse der verwendeten tools ergeben jedoch eine gute übersicht über den reifegrad der barrierefreiheit, müssen jedoch manuell validiert werden.
ein einfaches beispiel zum verständnis:
ein fehlender alt-tag eines bildes muss nicht zwangsläufig einen fehler darstellen.
wenn das bild keine aussagekraft besitzt, zum beispiel eine grafik als trenner oder rein dekoratives element, darf kein alt-tag vorhanden sein um für den fall der verwendung eines screen-readers unnötiges vorlesen von nicht aussagefähigen informationen zu vermeiden.
wir verwenden zur durchführung automatischer tests nachfolgende tools:
- … axe devtools (https://www.deque.com/axe/)
- … tenon toolkit (https://tenon.io)
- … wave evaluation tool (https://wave.webaim.org)
- … google lighthouse (lighthouse chrome extension)
- … css & html validator (w3c validator service)
- zusammenfassung der ergebnisse der automatisierten tests.
- erstellung einer to-do (fehler) liste nach manueller validierung.
manuelles testverfahren
nach durchführung der automatischen tests erfolgt ein visueller und auditiver test um alle fehler die durch visuelle und auditive wahrnehmung festgestellt werden können zu finden. beispiele hierfür sind:
- kontrastverhältnisse
- responsiveness
- check der audio- und videoinhalte
ebenfalls zentraler bestandteil der manuellen tests ist die prüfung mittels screen-reader und die eingehende prüfung der tastaturbedienbarkeit.
zum abschluß erfolgt der abgleich der barrierefreiheitserklärung (soweit vorhanden) mit dem tatsächlichen ist-stand.
protokollierung der ergebnisse
die protokollierung der ergebnisse erfolgt mit hilfe des wcag-em reporting-tools (https://www.w3.org/WAI/eval/report-tool/)
damit ist zum einen die vollständigkeit der prüfung sichergestellt und weiter ist dieser report als arbeitsgrundlage zur behebung der gefundenen fehler allen mit accessible themen befassten webentwicklern bekannt.
weitere informationen zum thema barrierefreiheit für kmu in österreich findest du in unserem ausführlichen blogbeitrag.
bei offenen fragen oder bei interesse über den aktuellen stand deiner seite zögere nicht uns zu kontaktieren:
