Methodische Details zum Monitoring

Die Checks wurden größtenteils in Zusammenarbeit mit dafür beauftragten Agenturen vorgenommen. In Wien wurden die vereinfachten Checks von internen Expert:innen durchgeführt, in Tirol wurden alle Checks von internen Expert:innen gemacht.

Insgesamt wurde für alle drei Arten von Checks eine einheitliche Prüf- und Reporting-Vorgangsweise für ganz Österreich angestrebt, die weitestgehend erreicht werden konnte.

Eingehende Checks Websites

Für die eingehenden Checks der Websites wurden alle Anforderungen, die in Tabelle A.1 des Anhangs A der EN 301 549 V3.2.1 (2021-03) (PDF) (externer Link) angeführt sind, geprüft. Für Dokumente (PDF-Dokumente o. Ä.) wurden die Kriterien laut Kapitel 10 der EN 301 549 V3.2.1 (2021-03) geprüft. Diese entsprechen weitestgehend den WCAG-Erfolgskriterien der Version 2.1, Konformitätslevel A und AA. Eine detaillierte Entsprechungstabelle zum Ausklappen ist weiter unten verfügbar.

Folgende WCAG-Kriterien sind laut EN 301 549 für den Check von Dokumenten konkret ausgenommen:

• 2.4.1 Bypass Blocks
• 2.4.5 Multiple Ways
• 3.2.3 Consistent Navigation
• 3.2.4 Consistent Identification

Alle eingehend gecheckten Websites wurden mittels detaillierter manueller Prüfung auf Konformität mit den WCAG-Kriterien überprüft. Bei den Checks waren blinde und sehbehinderte Tester:innen beteiligt.

Die Checks erfolgten in Anlehnung an die WCAG-EM (Website Accessibility Conformance Evaluation Methodology) (externer Link). Dafür wurden folgende Prüfschritte durchgeführt:

• Einsatz von Analyse-Tools für einen ersten Eindruck über Aufbau und Struktur der Seiten
• Visuelle und auditive Prüfung (Kontraste, Prüfung von Multimedia-Inhalten etc.)
• Analyse des Quellcodes
• Prüfung der Tastaturbedienbarkeit
• Prüfung von Gesten- und Bewegungssteuerung (Mehrpunkt- oder pfadbasierte Gesten, Alternativen zu Steuerung durch Bewegung des Geräts)
• Prüfung mit Screenreadern

Folgende Tools wurden dafür unterstützend eingesetzt:

• QualWeb, W3C Markup Validation Service, Colour Contrast Analyser (CCA), Text Spacing Bookmarklet, Taba11y
• Screenreader: NVDA, TalkBack und VoiceOver, JAWS (in Tirol)

Bei den zusätzlichen Kriterien aus EN 301 549 wurde überprüft, ob zum jeweiligen Kriterium ein Fehler oder keine Fehler festgestellt werden konnten. Es wurde nicht jeder, möglicherweise vorhandene Fehler, sondern lediglich der erste gefundene Fehler dokumentiert, oder, wenn insgesamt kein Fehler gefunden wurde, das Kriterium als "erfüllt" bewertet.

Stichprobenziehung der zu prüfenden Unterseiten

Für die eingehenden Checks wurden folgende Unterseiten der einzelnen Websites für die Überprüfung ausgewählt (sofern vorhanden):

• Startseite, Anmeldung, Sitemap, Kontakt, Hilfe und Seiten mit rechtlichen Informationen
• zumindest eine relevante Seite für jede Art von Dienst, der von der Website bereitgestellt wird, und für jeden anderen Hauptzweck einschließlich Suchfunktion
• die Seiten mit der Erklärung oder den Angaben zur Barrierefreiheit sowie die Seiten mit dem Feedbackmechanismus
• fünf beispielhaft ausgewählte Seiten mit einem deutlich anderen Erscheinungsbild oder anderen Arten von Inhalten
• zumindest ein relevantes abrufbares Dokument, falls vorhanden, für jede Art von Dienst, der von der Website bereitgestellt wird, und für jeden anderen Hauptzweck
• nach dem Zufallsprinzip ausgewählte Seiten im Umfang von mindestens 10 % der mittels der vorherigen Schritte definierten Stichprobe

Beinhaltet irgendeine der oben ausgewählten Unterseiten einen Schritt in einem Verfahren, so werden alle Schritte des Verfahrens geprüft. Das heißt, es werden alle Unterseiten geprüft, die zum Durchlaufen des gesamten Prozesses notwendig sind.

Vereinfachte Checks Websites

Für die vereinfachten Checks wurde eine Auswahl der WCAG-Erfolgskriterien überprüft. Die Checks beschränkten sich auf 13 WCAG-Erfolgskriterien, die zumindest teilweise automatisiert getestet werden können. Sie umfassen Erfolgskriterien zu allen 4 Prinzipien: wahrnehmbar, bedienbar, verständlich und robust. Die Erfolgskriterien hängen mit Bedürfnissen der Nutzer:innen bezüglich eines barrierefreien Zugangs zusammen. In der „Entsprechungstabelle vereinfachte Checks Websites“, die weiter unten zum Ausklappen zur Verfügung steht, ist dargestellt, wie sich der Zusammenhang mit den ausgewählten Erfolgskriterien laut EN 301 549 gestaltet. Für den Bund wurden nur klassische Webinhalte überprüft, Tirol hat bei den vereinfachten Checks zusätzlich, sofern vorhanden, auch PDF-Dokumente überprüft.

Bei den vereinfachten Checks handelt es sich um Prüfungen auf Nichtkonformität. Durch die automatisierten Checks einer Auswahl von WCAG-Erfolgskriterien kann die Konformität nicht festgestellt werden. Die Kriterien werden außerdem meist nicht zur Gänze überprüft, sondern es wird eine Reihe einzelner automatisierter Checks dazu durchgeführt. Diese sind in der Spalte „Durchgeführte Checks (Qual Web Rule ID)“ in der unten stehenden „Entsprechungstabelle vereinfachte Checks Websites“ angeführt. Bei den vereinfachten Checks wird also geprüft, ob mit den einzelnen automatisierten Checks zu den ausgewählten Kriterien Fehler gefunden werden können, und nicht, ob Kriterien erfüllt werden.

Erläuterungen zu den in der Entsprechungstabelle genannten Checks sind auf der Website der ACT-Rules Community (externer Link) zu finden. Die jeweilige Erklärung ist bei jeder Rule verlinkt.

Tirol führte bei den vereinfachten Prüfungen auf den Unterseiten Barrierefreiheitserklärung, Impressum sowie bei vorhandenen Kontaktfunktionalitäten auch teilweise manuelle Checks durch.

Folgende Test-Tools wurden in den drei Monitoringzeiträumen genützt:

• Monitoringzeitraum 2022:
  • QualWeb Core (Version 0.7.10, 23.11.2021)
  • Tirol: QualWeb und zusätzlich HTML Validator von W3C, Koa11y, WAVE-Chrome Extension, JAWS-Fusion 2022
  • Wien: Google Lighthouse
• Monitoringzeitraum 2023:
  • QualWeb Core (Version 0.7.28, 21.11.2022)
  • Tirol: QualWeb und zusätzlich HTML Validator von W3C, WAVE-Chrome Extension, JAWS-Fusion 2023
  • Wien: QualWeb und zusätzlich Google Lighthouse
• Monitoringzeitraum 2024:
  • QualWeb Core (Version 0.7.46, 01.12.2023)
  • Tirol: QualWeb und zusätzlich Koa11y, WAVE-Chrome Extension, JAWS-Fusion 2024
  • Wien: QualWeb und zusätzlich Google Lighthouse

Stichprobenziehung der zu prüfenden Unterseiten

Für die vereinfachten Checks wurden folgende Unterseiten der einzelnen Websites für die Überprüfung ausgewählt:

• Startseite
• Eine Anzahl von Unterseiten, die in einem angemessenen Verhältnis zur geschätzten Größe und Komplexität der Website steht: 15 bis 20 Unterseiten wurden neben der Startseite zusätzlich für die Prüfung ausgewählt. Ausgehend von der Hauptnavigation wurden Unterseiten ausgewählt, die ein anderes Erscheinungsbild beziehungsweise andere Funktionalitäten als die bisher in die Stichprobe aufgenommenen Unterseiten haben (z. B. Formulare, Actionable Elements, Bilder, Tabellen, dynamische Inhalte, Struktur, anderes Layout).

In Tirol wurden ebenfalls Unterseiten mit unterschiedlichen Funktionalitäten bzw. unterschiedlicher technischer Umsetzung sowie eine PDF-Datei ausgewählt. Es wurden 5 bis 8 Unterseiten geprüft.

Eingehende Checks Apps

Für die eingehenden Checks der Apps wurden alle Anforderungen, die in Tabelle A.2 des Anhangs A der EN 301 549 V3.2.1 (2021-03) angeführt sind, geprüft. Für Dokumente (PDF-Dokumente o. Ä.) wurden die Kriterien laut Kapitel 10 der EN 301 549 V3.2.1 (2021-03) geprüft. Diese entsprechen weitestgehend den WCAG-Erfolgskriterien der Version 2.1, Konformitätslevel A und AA. Eine detaillierte Entsprechungstabelle ist weiter unten zum Ausklappen verfügbar.

Wie bei den eingehenden Checks der Websites sind folgende WCAG-Kriterien laut EN 301 549 beim Check von Dokumenten ausgenommen:

• 2.4.1 Bypass Blocks
• 2.4.5 Multiple Ways
• 3.2.3 Consistent Navigation
• 3.2.4 Consistent Identification

Darüber hinaus sind folgende WCAG-Kriterien laut EN 301 549 beim Check von Apps ausgenommen:

• 2.4.1 Bypass Blocks
• 2.4.2 Page Titled
• 2.4.5 Multiple Ways
• 3.1.2 Language of Parts
• 3.2.3 Consistent Navigation
• 3.2.4 Consistent Identification

Alle eingehend gecheckten Apps wurden mittels detaillierter manueller Prüfung auf Konformität mit den Kriterien überprüft. Bei den Checks waren blinde und sehbehinderte Tester:innen beteiligt. Die Checks erfolgten in Anlehnung an die WCAG-EM (Website Accessibility Coonformance Evaluation Methodology) (externer Link). Dafür wurden folgende Prüfschritte durchgeführt:

• Einsatz von Analyse-Tools (dort, wo es möglich ist) für einen ersten Eindruck über die Apps
• Visuelle und auditive Prüfung (Kontraste, Prüfung von Multimedia-Inhalten etc.)
• Üblicherweise kein Zugriff auf den Quellcode möglich, nur bei Progressive Web Apps kann eine Code-Analyse gemacht werden
• Prüfung von Gesten- und Bewegungssteuerung (Mehrpunkt- oder pfadbasierte Gesten, Alternativen zu Steuerung durch Bewegung des Geräts)
• Prüfung mit Screenreadern

Folgende Tools wurden dafür unterstützend eingesetzt:

• Android
  • Accessibility Scanner
  • Color Picker und WebAIM Contrast Checker
  • Screenreader TalkBack
• iOS
  • Color Contrast
  • Screenreader VoiceOver

Bei den zusätzlichen Kriterien aus EN 301 549 wurde überprüft, ob zum jeweiligen Kriterium ein Fehler oder keine Fehler festgestellt werden konnten. Es wurde nicht jeder, möglicherweise vorhandene Fehler, sondern lediglich der erste gefundene Fehler dokumentiert, oder, wenn insgesamt kein Fehler vorgefunden wurde, das Kriterium als "erfüllt" bewertet.

Stichprobenziehung der zu prüfenden Screens

Für die eingehenden Checks von Apps wurden folgende Screens der einzelnen Apps (sofern vorhanden) für die Überprüfung ausgewählt – die Auswahl erfolgte analog zu den eingehenden Checks der Websites:

• Startscreen, Screens mit Anmeldungsbereich, Screenübersicht (Sitemap), Kontakt, Hilfe und Screens mit rechtlichen Informationen
• zumindest ein relevanter Screen für jede Art von Dienst, der von der App bereitgestellt wird, und für jeden anderen Hauptzweck einschließlich Suchfunktion
• die Screens mit der Erklärung oder den Angaben zur Barrierefreiheit sowie die Screens mit dem Feedbackmechanismus
• fünf beispielhaft ausgewählte Screens mit einem deutlich anderen Erscheinungsbild oder anderen Arten von Inhalten
• zumindest ein relevantes abrufbares Dokument, falls vorhanden, für jede Art von Dienst, der von der App bereitgestellt wird, und für jeden anderen Hauptzweck
• nach dem Zufallsprinzip ausgewählte Screens im Umfang von mindestens 10 % der mittels der vorherigen Schritte definierten Stichprobe

Beinhaltet irgendeine der oben ausgewählten Unterseiten einen Schritt in einem Verfahren, so werden alle Schritte des Verfahrens geprüft. Das heißt, es werden alle Screens geprüft, die zum Durchlaufen des gesamten Prozesses notwendig sind.

Kommunikation mit Einrichtungen aus der Stichprobe

Bei allen drei Prüfarten (vereinfachte Checks Websites, eingehende Checks Websites und eingehende Checks Apps) wurden die Ergebnisse mit dem WAD Report Tool (externer Link) in Form eines Reports dokumentiert. Das Ergebnis der Prüfung wurde, nach einem Qualitätscheck, an die geprüfte Einrichtung übermittelt.

Tirol übermittelte den vereinfacht geprüften Einrichtungen einen ausführlicheren Report. Dieser stellt einerseits einen Fehlerbericht mit Hintergrundinformationen dar, enthält aber auch Handlungsempfehlungen sowie Formulierungsvorschläge für die Barrierefreiheitserklärung.

Um sicherzustellen, dass es während des Prüfvorgangs zu keinen Verzögerungen kommt, wurden bei den eingehenden Checks die Einrichtungen direkt nach der Stichprobenziehung kontaktiert. Damit wurde einerseits die zuständige Ansprechperson eruiert und andererseits wurden gegebenenfalls Zugangsdaten abgefragt.

Besonders den eingehend geprüften Einrichtungen wurden Beratungsgespräche angeboten, die von den öffentlichen Einrichtungen gerne angenommen wurden. Diese Termine dauerten rund 90 Minuten. Dabei wurden Teile des Reports besprochen, und konkrete Fragen der Einrichtungen bzw. der betreuenden Webagenturen konnten beantwortet werden.