Ablauf eines Barrierefreiheits-Tests

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

00:00:04: Heute geht es um die Vorgehensweise, wenn man einen Barrierenfreiheitstest durchführen möchte.

00:00:11: Wer ein Barriernfreiheitstest durchführt, kann sich an der WCAG EM orientieren.

00:00:19: Die Evaluationsmethodologie zogenbrechen Die Evaluation Methodik ist eine Anleitung des World Wide Web Consortiums, also der WEI, der Web Accessibility Initiative um das ganze Methodisch sinnvoll anzugehen.

00:00:42: Die BKGM ist öffentlich zugänglich.

00:00:45: Also ich werde es euch auch verlinken.

00:00:46: natürlich Es gibt aktuell eine öffentliche Version und ein Entwurf für eine Version Zwei Prognol.

00:00:54: die öffentlichen Version also die publizierte Version bezieht sich vor allem auf Websites und die Zwei.null wird andere Gegenstände wie Apps, PDFs usw.

00:01:06: einbeziehen.

00:01:08: ich habe jetzt die großen Unterschiede nicht entdeckt.

00:01:10: also die Vorgehensweise ist die gleiche generell vielleicht noch für alle.

00:01:15: Leute sind jetzt nicht so tief in der WCRG's sind.

00:01:19: Die WCRGs sind ja normativ das heißt wer sich auch die WCRg beruft muss sich genau darauf berufen.

00:01:27: Die meisten Dokumente der WEI sind aber informativ.

00:01:31: Das heißt, man kann sie als Anleitung benutzen muss es aber nicht.

00:01:38: Generell beginnt die Prüfung damit dass man sich den Prüfgegenstand einmal anguckt.

00:01:44: das heißt wenn es eine Webseite ist oder eine App dann scrollt man einmal durch die einzelne Seite auch durch die unterseiten oder Bildschirme und guckt sich das Dokument generell einmal an.

00:02:00: Warum ist es sinnvoll?

00:02:03: Bei PDFs zum Beispiel, es ist eigentlich relativ schnell feststellbar ob überhaupt eine Prüfung sinnvoll ist.

00:02:10: bei PDFs gibt es ja Text endlich wie bei HTML.

00:02:14: Und häufig ist es so dass PDFs die ich bekomme zum Beispiel gar keine Texte enthalten.

00:02:20: Das heißt, da sind keine überschritten Formatierungen Da sind keine Absätze, keine Tabellen erkennbar formatiert über diese Textstruktur.

00:02:29: Und da kann man die Prüfung auch an der Stelle abbrechen und dem Kunden Geld sparen, weil wenn keine Texte handeln sind ist das Dokument persönlich bei ihrer Freie.

00:02:40: So einen Schnellcheck würde ich tatsächlich auch immer empfehlen, wenn ihr zum Beispiel nicht finale Gegenstände prüft sondern wirklich eine Enthöhe vorliegen habt von Websites zum Beispiel.

00:02:57: Bei diesen Entwicklungen gibt es ja häufig ein Staging oder eine Versionierung und das kann ja sein, dass man irgendwie eine veraltete Version bekommen hat oder eine Version die nicht mehr live ist sondern schon weiterentwickelt wurde.

00:03:11: Das passiert durchaus.

00:03:12: so ist es nicht so superhäufig aber eigentlich sollte es nicht passieren.

00:03:16: was passiert halt.

00:03:18: und da macht es wirklich Sinn zu sagen Leute Deswegen erfüllt die elementaren Voraussetzungen der Barrierefreiheit nicht.

00:03:26: Das kann ich innerhalb von einer halben Stunde höchstens feststellen, dass das sich erfüllt.

00:03:33: Deswegen macht eine Weiterprüfung gar keinen Sinn.

00:03:37: Böden ich jedem empfehlen?

00:03:38: Es hat einfach den Vorteil, dass man dem Kunden jede Menge Zeit und Geld spart und dann hoffentlich die Beauftragung für die endgültige Prüfung bekommt.

00:03:48: Bin ich auf jeden Fall richtlicher als zu sagen Das Ding ist mal nicht barrierefrei, aber ich teste das trotzdem und dann stelle ich die Rechnung.

00:03:57: Und da darf er noch einmal kommen, was er wahrscheinlich nicht tun wird.

00:04:02: Was man auch macht, während der Sichtung ist wirklich zu gucken welche Komponenten gibt es?

00:04:09: Welche Status es gibt, falls es ein Pyrograph von Status gibt.

00:04:14: also ist eine Welt aufgeklappt aufklappbar, zuklapper solche Dinge Damit man einfach eine Einschätzung davon hat, wie komplex die Prüfung auch ist.

00:04:25: Aber vor allem auch welche Screens man einem Test unterziehen sollte.

00:04:32: Bekanntermaßen so eine App und der Website können ja aus hunderten von Seiten bestellen.

00:04:39: Und man ist einfach nicht in der Lage das manuell alles zu prüfen.

00:04:45: Deswegen guckt mal, welche Seiten sind exemplarisch?

00:04:50: oder welche Komponenten, das ist exemplarisch wenn man noch Komponentenbasis vorgeht.

00:04:55: Und ja macht die wichtigsten Prüfgegenstände aus, die man an der Prüfung unterziehen möchte und schaut sich das ganze dann dokumentiert das Ganze für sie selbst um dann einen sinnvollen Prüf Gegenstand ausmachen zu können.

00:05:13: Dann wird vorgeschlagen von der WKGM, dass man einen Kulturabilitätslevel festliegt.

00:05:21: Dass man erreichen möchte also A, AA oder dreifachA was aber in der Regel egal ist weil wir haben eigentlich nur mit laut zu tun die AA alles treben?

00:05:35: A hat sich bisher noch gar nicht, kann ich mich erinnern.

00:05:38: Es kann sein dass jemand dreifach a erreichen möchte aber auch das hatte ich bis zu meine Karriere nicht insofern.

00:05:45: Kann man diese Schritt tatsächlich überspringen?

00:05:48: Ein weiterer Schritt ist die Festlegung des Standards den man zur Anwendung bringen möchte.

00:05:56: Auch das hat sich ja weitgehend erledigt weil wir eine gesetzliche Grundlage haben.

00:06:00: Wir haben die BITV beziehungsweise das BFSG Und da ist die gesetzliche Grundlage bzw.

00:06:07: der Standard festgelegt.

00:06:09: Der nächste Schritt ist dann tatsächlich die Festlegung des Prüfgegenstandes, also wir haben... Also eine Sache habe ich vergessen und zwar ist auch die Abgrenzung immer ganz wichtig.

00:06:21: das muss auch in einer Absprache bitte Kunden erfolgen.

00:06:25: Das heißt bevor ich festlege was ich prüfe sollte ich auch festlegen was ich nicht prüfen.

00:06:32: zum Beispiel, wenn eine App Webuse hat und diese Webuse Inhalte reinzieht die nicht von dem Betreiber selbst kommen.

00:06:41: Die aber auch nicht in seiner Verantwortung liegen oder die er einfach nicht getestet haben möchte aus irgendeinem Grund das kann man als Aussuchstehender häufig gar nicht beurteilen.

00:06:53: deswegen ist es auch immer sinnvoll den Kunden zu fragen welche Welche Komponenten, welche oder gibt es Komponenten und Teile der Webseite?

00:07:04: Anwendungen die ausgeschlossen werden sollen weil sie von zum Beispiel von extern kommen oder aus irgendeinem anderen Grund.

00:07:11: Das ist im Prinzip egal was es auch häufig gibt in Legacy Systeme also das Websites auf mehreren Systemen basieren Gibt es erstaunlich oft.

00:07:21: ich weiß auch nicht warum man das macht.

00:07:24: Es kommt tatsächlich vor Und dann sagt der Kunde, das sind die Websites.

00:07:32: Die Unterseiten, die aus dem neuen Content Management System kommen oder die Views oder was auch immer.

00:07:39: Die kannst du dir angucken und die Alpen werden nach und nach umgezogen oder so was?

00:07:43: Das ist auch etwas, dass er mit den Kunden in eine relativ frühen Stadion besprechen sollte damit man einfach zu gestiegen... Websites testet.

00:07:54: Das ist in der Verantwortung des Kunden, das zu entscheiden was zum Prüfgegenstand gehört beziehungsweise wir entscheiden was zur Prüf-Gegenstand... Was wird zum Prüfe Gegenstand hinzuzählen würden?

00:08:09: und der Kunde muss dann aber entscheiden oder gefragt werden, konsultiert werden ob diese Views auch seiner Ansicht nach die entscheidenden Views sind.

00:08:21: Das ist also wirklich ein sinnvolles Vorgehen.

00:08:24: Bei einer Web-Anwendung, also eine Applikation die komplett im Browser läuft, das Single Page Application da hat sich das Thema ohnehin erledigt weil es da gibt es ja nur eine View.

00:08:37: Da muss man eher sich Szenarien angucken, die man durchtesten möchte.

00:08:42: Besuche ich jetzt gegen diese Seiten aus oder die Views, wie ich sie untersuchen möchte Generell, die Startseite gehört immer dazu.

00:08:53: Weil viele Personen starten von der Startseide zum einen und zum anderen ist die Start-Seite immer ein bisschen exotisch.

00:09:01: Die hat immer eigene Views.

00:09:03: Sie hat häufig in einem Stemplate als Grundlage.

00:09:08: Deswegen ist es immer sinnvoll, die startseite auf jeden Fall mit ins prüflichen Start zu nehmen.

00:09:17: Dann eine normale Inhaltsseite, die einfach nur Inhalte enthält.

00:09:23: Texte, Überschriften, Bilder... Also eine einfache Inhaltseite und dann vielleicht eine komplexere Inhaltesseite also der Seite mit Tappeln, Akkordions usw.

00:09:39: Und auf jeden Fall eine Seite mit Formularen z.B.

00:09:44: Kontaktseite.

00:09:46: Das ist auf jeden Fall immer sinnvoll.

00:09:49: Kompliziert wird es bei Seiten, die einen bestimmten Ablauf vorgeben zum Beispiel auf einer Retail-Seite oder an der Shopping Seite wo man ja ein Prozess durchlaufen muss.

00:10:05: Der Prozess heißt ich suche nach etwas auf der Produktseite oder ich suche ein Produkt über die Suche.

00:10:15: Ich packe das Produkt in den wahren Korb, ich muss einen Konto anleben, ich musste mich einloggen und so weiter bis zum... ich muss meine Zahlungsdaten um meine Adresse eingeben und die Bestellungen abschicken.

00:10:32: Das ist ein Prozess und bei Prozessen muss man sich tatsächlich auch der gesamten Prozess angucken.

00:10:38: Ja, wir hasen ein bisschen das.

00:10:39: Die WEI oder die WC AG sagt ja Konformität besteht nur wenn alle Teile eines Prozesses, eines zusammenhängenden Prozessens auch konform sind und das heißt auch dass man sich den gesamten Prozess angucken muss.

00:10:55: Das ist natürlich enorm umhangreich, das sind ja teilweise zehn Seiten oder so.

00:11:01: Aber das ist schmerzhaft.

00:11:03: aber da muss man leider durch als Kunde vor allem weil es natürlich auch entsprechend mehr Geld kostet.

00:11:09: Jede VU zusätzlich zu testen kostet natürlich zusätzlich Geld, aber das ist leider Teil des Problems.

00:11:19: Nachdem man dann den Prüfgegenstand festgelegt hat, sprich man hat mal die Prüfkunden auch entsprechend eingebunden und geguckt dass alle Komponenten ausgemacht wurden wie relevant sind und dann beginnt tatsächlich die Prüfung Tatsächlich kompliziert und aber auch sehr individuell.

00:11:38: Ich kenne Leute, die jede Seite sich angucken oder die WCRG von oben bis unten durcharbeiten.

00:11:46: Es gibt aber auch Leute, der anders vorgehen, die Brüche gruppieren und dann die Seiten zum Beispiel unterschiedlichen Tabs offen haben.

00:11:58: Egal wie man vorgeht.

00:11:59: Man braucht auf jeden Fall als Prüferin eine Struktur, nach der man konstant vorgeht und dann werden die einzelnen Kriterien geprüft.

00:12:12: Man guckt erst mal ob das Kriterium überhaupt anwendbar ist.

00:12:15: Das heißt es gibt immer bestimmte Prüfschritte so was sie hier blitzen oder plackern zum Beispiel die in der Regel nie anwendbaar sind.

00:12:23: Aber es gibt Prüfschritte, die immer anbindbar sind.

00:12:26: Wenn Inhalte vorhanden sind, so was wie Überschriften vorhandene Texte formatiert.

00:12:33: Testaturbedieberkeit – das sind Dinge, die in der Regel geprüft werden müssen und dann kann man diese Prüf- schritte nach einem Schema durch, wie auch immer man das machen möchte und prüft dann jede einzelne Seite mit diesem Schema ab.

00:12:48: Für diejenigen, die das interessiert, ist der Grund warum die Prüfung immer sehr lange dauern.

00:12:54: Man kann da relativ wenig automatisieren, bei Automatisierung heißt immer auch false positives.

00:13:00: Das heißt man kriegt Ergebnisse die als positiv angezeigt werden ob sie negativ sind oder ungekehrt und dann muss man trotzdem nochmal die automatischen Ergebnisse darauf hin prüfen, ob sie wirklich korrekt sind.

00:13:17: Man muss alle gefundenen Fehler dokumentieren Und man sollte auch eine Empfehlung geben, wie man das jeweilige Problem beheben kann.

00:13:31: Bei der Dokumentation der Fehler ist zum Beispiel auch wichtig natürlich, dass exakt beschrieben wird was das Problem ist.

00:13:38: Wenn die Fehlerbeschreibung zu allgemein ist dann kann das die entwickelte Person nicht nachvollziehen und weiß dann auch nicht was sie korrigieren soll.

00:13:49: Wichtig ist der Fehler als Screenshot oder Teil des Codes einzurinden in den Prüfbericht und wie gesagt eine Empfehlung, wie das Problem beruhen werden kann.

00:14:04: Wichtig ist auch dass der Fehler einem Prüfschritt oder einer BC AG Kriterium ich sage über BC AG ihr wisst, dass es hier bei EN-Drahtnull eins für Pneunbeine also ein BC AG Schritt zugeordnet wird damit auch nachvollziehbar Problem ist, was auf diesem Barrierefreiheitsrichtlinien beruht und nicht nur eine Erfindung ist das zu sagen des Testers oder was der Tester gerne hätte aber eigentlich nichts zur Barrierenfreiheit gehört.

00:14:39: Wiss ich jetzt wie gesagt auch eine Handlungserpinion wie man das Problem beheben kann?

00:14:46: Das muss nicht umhängig sein, also man kann den Leuten die für die Umsetzung zuständig sind auch immer einen Spielraum geben.

00:14:55: Man kann eine Empfehlung geben das heißt man sagt wie das Problem behoben werden könnte aber es gibt natürlich auch immer andere Lösungsmöglichkeiten.

00:15:09: Das sollte den Leuten, die dafür zuständig dass man im Prüfericht eigentlich nicht immer abschließend sein kann, weil es einfach so umfangreich ist.

00:15:21: Eine Sache die man attraktivieren sollte ist einfach das die Umsetzung immer dazu führen kann, dass andere Fehler gemacht werden.

00:15:32: auch das sollte man im Hinterkopf haben als jemand der die Ergebnisse dokumentiert, dass wenn man guckt, dass man potentielle Fehler durch die Umsetzungen einer Fehlerbehebung passieren dass eine Fehlerbehebung nicht dazu führt, dass weitere Fehler gemacht werden.

00:15:47: Die eventuell sogar schreckigen, dass es das was man gerade gelöst hat.

00:15:51: Wichtig ist, dass sie sich leider häufiger ist auch, dass man dokumentiert womit man eigentlich getestet hat.

00:15:59: Heutzutage, gerade bei Web, ist es ja wirklich so, dass mal unanständlich viele Prüfstools hat.

00:16:05: Bookmarklets, Browser DevTools... spezielle Toolbars oder Web Accessibility Toolbars, da gibt es ja unzählige Sachen bei Web.

00:16:18: Bei den anderen Produkten ist das ein bisschen überschaubarer aber trotzdem ziemlich viel und deswegen ist es immer ganz wichtig zu dokumentieren welches Tool wurde verwendet um diese Prüfergebnisse zu erzielen damit die Idee der ist eventuell nachtestet auch nachvollziehen kann, was das Problem war.

00:16:40: Auch sehr sinnvoll ist wirklich sowas wie die Browser-Version bei.

00:16:43: Browser können auch Bugs haben, auch Screenreader können Bugs habe.

00:16:48: Deswegen ist die Screenreaderversion auch wichtig wenn man einen verwendet hat.

00:16:53: Auch das Betriebssystem kann wichtig sein.

00:16:55: muss man jetzt nicht über den glaube ich Dokumentieren?

00:16:59: außerbei weg muss man es dokumentieren damit auch hier Nachwurzungen werden kann, ob es eventuell noch ein Buck im System war.

00:17:10: Was ist generell wichtig bei Prüfberichten?

00:17:13: Wenn ihr Kunden seid, dann solltet ihr das immer einfordern.

00:17:17: Die allgemeine Verständlichkeit muss gegeben sein.

00:17:20: Das heißt eine Kunde muss immer nachvollziehen können was wurde da tatsächlich geprüft und was ist das konkrete Problem?

00:17:32: Das sind Dinge, die immer dokumentiert werden müssen.

00:17:37: Als testende Person ist man ja nicht über den Web-Entwicklerinnen oder Entwicklern generell.

00:17:45: das heißt man kann einfach nicht immer sagen so und so wird es behoben vor allem wenn es irgendwie in Frameworks reingeht wenn du irgendwelche Angular Maui, bla-bla-bla der Frameworks hast.

00:18:00: Kein Mensch kann die alle kennen und es recht nicht als Barrierefreies Expertin.

00:18:04: Als Barrierenfreie Experte beschäftigt man sich mit Barrieremfreiheit, nicht mit irgendwelchen Frameworks, die sie Developer einsetzen.

00:18:13: Und deswegen ist das deren Baustelle wie man das Problem beheben kann.

00:18:17: was man aber als Prüferin für Barrierofreiheit immer dokumentieren muss ist dass er Wünsche verhalten.

00:18:25: Also was wäre, wenn es korrekt funktionieren würde?

00:18:28: Was ist das, was ich erreichen möchte.

00:18:31: Auch hier ist wieder wichtig, dass man dokumentiert Beam angeprüft hat weil das für die Entwicklerinnen einfach nachvollziehbar macht.

00:18:42: Wenn ich jetzt zum Beispiel mit Android Talkback getestet habe dann kann die Person Android TalkBack auf ihrem Prüfgesetz anlassen und das direkt selber testen, ob das was ich beschrieben habe auftritt.

00:18:56: Und ob das, was sie getan hat um das Problem zu korrigieren dazu geführt hat dass das Problem korrigiert wurde.

00:19:04: Deswegen ist diese Dokumentation der Prüfstruhle auch extrem wichtig und ja sollte auch immer gemacht werden.

00:19:14: Erstmal Not Lies gehört auch dazu, dass man die Prüfergebnisse einmal mit dem Grund durch spricht.

00:19:20: Das muss nicht im Detail passieren, weil diese Brutberichte sind ja unglaublich umfangreich.

00:19:26: Wir haben ja gesehen warum.

00:19:28: das sollte auch sein, die sollen ja umfangreichs sein aber man kann zumindest die wichtigsten Feindigs dokumentieren.

00:19:37: Alternativ würde ich auch als ZIT-Teleister auch immer anbieten dass man bei der Erstellung von Giratickets hilft oder Tickets hilft, damit die Sachen noch besser eingekippt werden und dass man generell einen Rückkanal zu den Developern hat.

00:19:55: Damit wenn sie Fragen haben – und Sie werden mit Sicherheit Fragen haben -, damit man sicherstellen kann, dass die Sachen auch korrekt umgesetzt werden.

00:20:05: Das ist extrem wichtig!

00:20:07: Natürlich muss dieser Prüfbericht den Kunden bereitgestellt.

00:20:11: Mittlerweile bitte keine PDFs, keine Word-Dokumente oder sonstiger Quark sondern wirklich CSV irgendwas in der Art.

00:20:21: Oder vielleicht tu es nicht direkt in Ticketsysteme eingefügt werden können.

00:20:27: Im Idealfall das wäre natürlich super wenn die TesterInnen Zugang zu den Ticketssystemen des Kunden bekommen weil sie seine Tickets direkt einfügen können.

00:20:37: Das macht eine ganze Geschichte sehr viel smoother weil man da Screenshots und solche Sachen ein paar Lüftige einfügen kann.

00:20:44: Und die Produkt-Onerin oder wer auch immer, kann dann über die Tickets drüber gucken und sie dann nochmal glatt ziehen so wie es der Kunde haben möchte.

00:20:54: Auch User Stories gehören eigentlich nicht in einen normalen Prüfbericht aber kann man machen?

00:21:01: Das muss der Kunder halt extra beauftragen Um das Ganze doch mal zusammen zu passen.

00:21:07: Also schauen wir uns zuerst den Prüfklickstand an Gucken, welche Sachen gehören dazu und welche Sachen sind ausgeschlossen.

00:21:16: Dann suchen wir uns aus welchen Seiten wir testen zusammen mit dem Kunden oder welche Views.

00:21:22: Dann führen die Prüfung durch machen also Dokumentation für den Kunden besprechen Dokumentations durch oder beantworten Rückfragen der Developer Und ja damit ist der prüfe recht abgeschlossen.

00:21:38: Aus unserer Erfahrung heraus würde ich sagen In der Regel braucht man mindestens zwei Durchläufe, um so die größten Schnitzer auszuheben.

00:21:48: Auszuhämen ist das falsche Wort.

00:21:51: Aufzulösen!

00:21:54: Es dauert halt immer ein bisschen länger und je komplexer die das Angebot ist und je mehr Legacy in diesem System vorhanden ist, also so ein fünfzehn Jahre altes System bis halt später bei ihrer Freizeit machen.

00:22:08: Ein alter System was wieder vier fünf Jahre alt ist, weil sich da einfach so viele Altlasten auf angesandelt haben.

00:22:14: Dann war es das für heute!

00:22:15: Ich hoffe ihr konntet ein bisschen etwas mitnehmen für euch und freue mich wenn ihr das nächste mal wieder einschaltet.

00:22:21: Bis bald.