Barrierefreiheit evaluieren mit der WCAG EM

00:00:05: Herzlich willkommen zu einem neuen Podcast zur digitalen Barrierefreiheit.

00:00:08: Heute möchte ich über die WCAG EM, die Evaluation Methodology sprechen.

00:00:16: Das ist ein aktuell neu aktualisiertes also ein aktuelles Dokument der Arbeitsgruppe des World Wide Web Consultations wo es darum geht wie man strukturiert Websites oder andere Produkte testet.

00:00:34: Das Dokument gibt es schon länger.

00:00:36: Es ist aber gerade aktualisiert worden mit der Version, ich glaube jetzt im Juli und deswegen ganz interessant weil man vor dem Thema Website weggegangen ist.

00:00:48: das ist ja auch ein Ziel der WCRG die irgendwann erscheinen wird oder nicht Die auch von dieser Fokussierung auf Websites weggeben möchte.

00:01:03: native Apps gibt, es gibt Desktop Software und es gibt Hardware die genauso von der WCAG erfasst werden soll.

00:01:11: Und die Evaluationsmethodik ist entsprechend schon angepasst worden in der Versionszahl.null.

00:01:17: Wie immer sind sich die meisten Dokumente informativ das heißt auch die WCAGM ist informativ und nicht normativ wie die WCAG selbst.

00:01:29: Kurze Einordnung, die WCAG ist normativ in dem Sinne dass sie relativ selten und sehr schwer gängig zu ändern ist was wir gerade merken.

00:01:39: Und informative Dokumente können mit einem deutlich vereinfachten Prozess aktualisiert werden und sind auch weniger spärbigen sozusagen in ihren Folgen.

00:01:54: Genau worum geht es der WCAGM wie gesagt?

00:01:56: Es geht darum das man eine Methodik festlegt wie Produkte strukturiert getestet werden.

00:02:05: Und das ist deshalb interessant, weil die meisten Prüfroutinen oder Qualitätsanforderungen an Prüfungen – zum Beispiel auch von der deutschen Überwachungsstelle für Barrierefreiheit im Prinzip als diese Methodik abbilden.

00:02:22: insofern kommt man nicht daran vorbei sich damit zu beschäftigen.

00:02:27: Nicht direkt, also man muss sich diese siebzig Tausend Zeichen lesen die da drinstehen sondern indirekt durch die Qualitätsanforderungen von Prüfungen und die glaube ich auch immer wichtiger werden je mehr Agentur oder einzelne Personen Prüfung für diese Dinge übernehmen gerade bei öffentlichen Stellen wenn man da Prüfungsdurchführer muss.

00:02:52: Die werden glaube ich immer stärker auf diese Qualitätsanforderungen gucken, aber auch große Unternehmen.

00:03:05: Da schauen wir uns das ganze Thema strukturiert an.

00:03:08: der erste Schritt ist den Umfang der Evaluation festzulegen.

00:03:21: Zunächst einmal schaut man sich das Produkt an und guckt was man eigentlich genau prüfen möchte also welche Domain zum Beispiel oder welches Subdomain Produkt, man sich genauer anguckt.

00:03:36: Da gehört auch so etwas dazu.

00:03:37: bei Websites schaue ich mir auch die PDFs an.

00:03:41: das ist etwas was häufig vergessen wird dass es ja auch PDFs gibt die bei ihre Freisein müssen deren Evaluation aber eine andere Qualifizierung erfordert als eine Webprüfung.

00:03:54: also die meisten webprüferInnen kennen sich mit pdf nicht aus.

00:04:00: und das zweite Problem Natürlich, dass es enorm aufwendig ist, PDFs zu prüfen.

00:04:05: Je nachdem wie komplex die sind und wie viele es gibt kann das deutlich umperreicher sein als so eine Beprüfung.

00:04:23: Im nächsten Schritt... Belege ich fest, nach welchen WCAG-Kriterien besuchsweise dann IAN-Kriteen ich prüfen möchte und welche Komformitätslevel ich erreichen möchte.

00:04:36: Also A, AA oder dreifachA und welche Version der WCAGI – zwei Punkt Null, zwei Punkt Eins, zwei Punkte Zwei.

00:04:44: Bedenken daran das ist ja natürlich ein internationales Dokument Und wir wissen ja auch z.B.

00:04:50: in den USA, die Sektion Fünfhundert Acht fordert tatsächlich WC AG zwei Punkt Eins wenn ich nicht irre.

00:04:57: Das heißt sie haben einen anderen Maßstab.

00:04:59: Hier in Deutschland ist es auch WC Agi Zwei Punkt Eins plus EN Dranen und Eins von Vierneun Und für das BFSG wäre es theoretisch auch WCA Agi Zweid Punkt Eins und En Dranel Eins von vierneun.

00:05:13: Aber Wir müssen es auf jeden Fall festlegen, weil manche Kunden wollen trotzdem nur die WCRG geprüft haben.

00:05:21: Und auch das muss man mit dem Kunden entsprechend festlegen.

00:05:36: Dann lege ich die Prüfparameter fest.

00:05:42: Das heißt, die find the Accessibility Baseline in Dokument und da lege Ich fest welche Browser und Assistiventechnologien von dem, von der Anwendung unterstützt werden sollen.

00:06:01: Ja das ist glaube ich jetzt kein super wichtiges Thema.

00:06:04: also zumindest alle Mainstream Browser müssten mit allen Mainstream Screen wieder in Zusammenarbeit und Probleme kann es höchstens bei Mac geben.

00:06:15: bei Safari und VoiceOver sind zwar verbandelt sozusagen aber da gibt's einige Dinge die nicht sauber funktionieren und Linux Und ScreenVider ist auch wieder ein eigenes Thema.

00:06:27: Aber da will in der Regel entweder Windows oder Mac-Testen und nicht unbedingt Assistive Technologien als Basis nehmen für den Test, ist das jetzt keine so superwichtige Antwortung.

00:06:45: Dann kann ich weitere Testanforderungen festlegen wenn zum Beispiel bestimmte Assistiven Technologie verwendet werden sollen oder bestimmte Anforderungen zusätzlich erfüllt sein sollen.

00:06:57: Das ist aber optional.

00:07:10: Im zweiten Schritt geht es dann darum das Produkt sich nochmal genauer anzugucken, vor allem aber die entscheidenden Ansichten des Produkts zu erkunden und herausfinden welche wichtigen Ansichten es gibt.

00:07:30: Das heißt bei einer App zum Beispiel An sich gibt es die wichtigsten Sachen könnten, natürlich der Start-Start-Screen.

00:07:37: Die Einstellungen vielleicht... ...der eigentliche Inhaltsscreen.

00:07:43: Das sind so die wichtigen Sachen, die man sich auf jeden Fall immer angucken muss und sowas wie ein Kontaktformular wenn es eins gibt.

00:07:51: Die schaue ich mir an.

00:07:55: Wichtigsten Komponenten enthalten sind, die in dem Produkt da sind.

00:08:00: So was wie Eingabefelder, Combo-Boxen, Checkboxen, Accordion und so diese ganzen Dinge, die auftauchen.

00:08:09: Dann gucke ich das... Ich die in den Test einbeziehe damit alle wichtigen Komponenten einmal im Test vorkommen.

00:08:24: Dazu gehört dann wie gesagt auch dass man wichtige essenzielle Funktionen identifiziert zum Beispiel Login-Bereich, ein Warenkorb.

00:08:40: Der Abschluss der wahren Streckenlädel des Kaufprozesses oder der Kontaktaufnahme und solche Dinge.

00:08:57: Als separaten Schritt gibt es hier noch, dass man die wichtigen Inhaltstypen erfasst, z. B. auch so etwas wie komplexe Tabellen.

00:09:06: oder gibt es PDFs, die noch geguckt werden müssen?

00:09:10: damit man einmal so ein Übepublikat über die wichtigsten Komponenten in diesem Angebot.

00:09:25: Ein wichtiger Schritt besteht darauf darin, dass man wichtige Technologien erfasst, die auch dem Angebot verwendet werden.

00:09:33: Für welche Rückreise ist es natürlich überwiegend ... Im Web ist das überwiegende TAT-TML und CSS.

00:09:38: In Apps ist dann eher die Programmiersprache, die verwendete Wode oder das Framework.

00:09:45: Auch bei der Setsupportik als Testerin machen muss weiß ich nicht Weil.

00:09:50: im Endeffekt testet man ja mit Tools und mit Assistiven-Technologien.

00:09:54: Und damit muss es funktionieren!

00:09:57: Eine Website ist halt html, css und javascript was sich was man da noch identifizieren muss.

00:10:03: aber vielleicht gibt's da Cases, UseCases wo man das dann doch identifiziieren muss.

00:10:21: Als der Beratenschritt in diesem Abschnitt gibt es auch das Thema wichtige Seitenerfassen, sowas wie die Kontraumitätserklärung.

00:10:31: Also die Erklärung zur Barrierefreiheit, Feedback-Mechanismus zur Barrierfreiheit und auch das was ich nicht auf Handelsformatik tun muss.

00:10:49: Im dritten Schritt also Schritt drei dieser WCAGEM ist, dass man wichtige Stichproben der Seite erfasst.

00:10:59: Also das man festlegt welche Seiten wichtig sind wo alle wichtigen Elemente enthalten sind und die gibt man in den eigenen Evaluationszyklus so zu sagen betreiben und nimmt sie als Stich Probe für das gesamte Angebot.

00:11:24: Dann wird auch noch empfohlen Zufällige Sample mit einbezieht, also eine Seite die man zufällig ausgewählt hat aus den Stichproben die man bereits identifiziert hat und die dem Test einbeziehen.

00:11:41: Ihr wisst ja dass man einfach aus Ressourcengründen nicht beliebig viele Seiten testen kann.

00:11:48: drei bis vier Seiten reichen in der Regel eigentlich ganz gut aus und hier wird noch ein Polen, das man eine zufällig ausgewählte Seite dazu nimmt.

00:12:00: Auch hier weiß ich nicht ob es wirklich notwendig ist.

00:12:08: Weiterhin ist wichtig dass man vollständige Prozesse abbildet,

00:12:12: d.h.,

00:12:13: ich kann mir natürlich den Startpunkt einer Customer Journey angucken also die Produktsuche des Produkts in dem Barenkorb legen kann ich mir angucken.

00:12:27: Aber es geht natürlich darum, dass man sich den gesamten Prozess anguckt.

00:12:30: Das heißt Lock-in, Headset Shop oder Account Anliegen, Produkte in dem wahren Kopf leben, Zahlungsdaten anlegen, Adresse einfleben, Bestelladresse und den Einkauf auch abschießen damit man den kompletten Überblick hat über den Einkaufen.

00:13:02: Und jetzt Ray kommen wir zum eigentlichen Test, das ist der Schritt hier.

00:13:07: Nämlich die Evaluation des, dessen was wir gerade ausgebläht haben.

00:13:15: Im ersten Schritt geht es dann darum dass man alle ausgesuchten Seiten durchtestet Das heißt das man alle WCAG-Kriterien gegen die einzelnen Ansichten die man heraus gesucht hat durchtestet.

00:13:34: Das heisst auch dass man zB alternative Versionen wenn es welche gibt ebenfalls in den Test einbzieht.

00:13:45: die Prüfung durch assistive Technologien auch hier, würde ich sagen ist optional kann man machen muss man nicht.

00:13:51: auf meiner Sicht und hier wird noch mal wiederholt okay wir haben einen kompletten Prozess also müssen wir uns den Prozess auch komplett angucken vom Login von dem Anliegen eines Accounts bis zum Abschluss des Einkaufes z.B.

00:14:22: dann hat der Polen strukturierte den Strukturiertentest mit dem Testes zufälligen Samples, zu vergleichen um mögliche Abweichungen zu erkennen.

00:14:40: Wie gesagt ich halte jetzt nichts davon so ein zufältiges Sample zu nehmen.

00:14:43: insofern muss man das glaube ich nicht haben habe ich auch noch keine Prozedur gesehen.

00:14:51: Keine Ahnung was das die Füße ist.

00:15:00: Dann kommen wir zur weiteren Schritt nämlich die Zusammenfassung der Prüfergebnisse.

00:15:07: Das heißt, dass ich alle Ergebnisse in einem Prüfericht dokumentiere und hier ist ein bisschen glaube ich die meisten worum es geht.

00:15:19: Dass nämlich das dokumentiert wird, dass sich Prüfung stark gefunden hat und dass man entweder Probleme gefunden hat oder keine Probleme gefunden.

00:16:06: Ein weiterer Aspekt ist die Dokumentation des eigentlichen Prüfprozesses.

00:16:15: Das heißt wer hat geprüft, womit wurde geprüst was in welcher Umgebung wurde gepüft also mit welchen Browsern vielleicht auch mit welchem Betriebssystem bei Hardware natürlich mit welcher Geräte Typen und solche Dinge.

00:16:30: die müssen natürlich auch dokumentiert werden.

00:16:33: lustigerweise wird es hier als optional dargestellt, aber ich glaube dass es tatsächlich eigentlich eine Pflichtinformation ist.

00:16:44: Also wenn ich einen Prüfbericht ohne Dokumentation der Prüfunggebungen und den prüffariablen erhalten würde, würde ich dem zurückgeben ehrlich gesagt.

00:16:52: Ist auch eben in den Qualitätskriterien der Überwachungsstelle tatsächlich explizit notiert das man festhält womit mit welcher Tools geprüft wurde.

00:17:07: Jetzt die Namen der Prüfenden weiß ich nicht.

00:17:09: Das fällt ja unter den Datenschutz wahrscheinlich, wenn das Dienstleister sind aber man muss zumindest dokumentieren welcher Dienstleiser die Prüfung durchgeführt hat.

00:17:26: Ebenfalls optional ist die Erstellung einer Konformitätserklärung

00:17:31: d.h.,

00:17:31: die Dokumentation dessen welche Grat an Kompromität erreicht wurde also bestanden, also vollkonform teilweise konform und nicht konform wobei dass auch ja eigentlich nicht so wichtig ist, weil erstens es kein Angebot vollkommen konform.

00:17:51: Aber ich habe tatsächlich noch keinen Angebot gesehen das vollkommen nicht konformen ist.

00:17:55: also alles hat irgendwie dazwischen.

00:17:57: insofern ist es auch wirklich optional.

00:18:06: ein weiterer optionaler Schritt ist die Bereitstellung eines Gesamtskurs Also eine Punktezeil wo dann dokumentiert wird so viele Heater wurden gefunden Prüfschritte sind bestanden.

00:18:20: Kann man machen, das habe ich auch bei vielen Prüftools mittlerweile Standard, dass da eine Form von Diagramm dargestellt wird mit der Auswertung oder die Tabelle.

00:18:34: Ich weiß nicht wiefern das hilfreich ist aber es kann dann hilfreist sein wenn man die Frotschritte messen möchte.

00:18:43: also sagen wir mal ein bisschen noch eine Prüfungsstadt ein halbes Jahr später, dann kann man gucken sind die Ergebnisse besser geworden oder nicht.

00:19:00: Dann auch optional die Bereitstellung eines maschinenlesbaren Prüferis.

00:19:07: Finde ich eigentlich eine ganz gute Sache.

00:19:08: sollte man mehr machen?

00:19:09: weil die prüferische sind ja einfach nicht wirklich standardisiert in den Maschinen lesbaren Format?

00:19:15: da hat man Wenn man Glück hat, hat man eine halbwegs vernünftige Tabelle für die Sachen drinstehen.

00:19:21: Manchmal kriegt man es auch als Powerpoint.

00:19:23: Das finde ich persönlich so wahnsinnig hilfreich.

00:19:26: So ein Powerpoint-Ding.

00:19:29: Also einen verschiedenen Sprache Report, den man auch in die Tools noch besser importieren kann.

00:19:34: Fertig schon ganz cool ist aber auch optional.

00:19:39: Zusammenfassend kann man sagen diese Qualitätskriterien und die Evaluationsmethodik werden immer wichtiger in der digitalen Barrierefreiheit, einfach weil wir sehen dass hier ja sehr viele neue Akteure sind von denen nicht alle wirklich sauber arbeiten und viele auch gar nicht wirklich gut qualifiziert sind für diesen Job.

00:20:05: Insofern ist diese Methodik auf jeden Fall ein guter Schritt in die richtige Richtung auch weil wir immer mehr unterschiedliche Ja, ihr Gewerke sowas wie native apps software und hardware evaluieren müssen.

00:20:23: Und auch hier eine saubere Methode kreifreich ist.

00:20:27: Ich hoffe dass ihr etwas aus dieser Episode mitnehmen konntet und würde mich freuen wenn ihr das nächste mal wieder einschaltet bis bald.