Umgang mit dem Prüfbericht

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

00:00:03: Heute gibt es eine relativ kurze Folge und zwar möchte ich das Thema aus dem letzten Podcast aufgreifen, wo es um die Prüfberichte gehen.

00:00:14: Und heute möchte ich euch kurz sagen wie man aus der Kundensicht auch Prüfgerichte gucken sollte bzw.

00:00:21: wie man damit umgehen sollte.

00:00:25: Erst einmal solltet ihr generell damit rechnen, dass diese Prüfberichte sehr umfangreich sind.

00:00:31: Ich weiß nicht wie unfangreich so ein klassischer Software-Test bericht aussieht aber ich vermute mal die sind ein bisschen klapper.

00:00:43: Generell hängt es natürlich damit zusammen, dass da sehr viele Meterinformationen sind.

00:00:48: Zum Beispiel welcher Prüfschritt?

00:00:49: Es ist auch eine etwas umfangreichere Einleitung wo Sachen dokumentiert werden.

00:00:57: Das heißt das ist schon mal umfangreich.

00:00:59: aber natürlich vor allem die Dokumentation der Fehler die etwas Text einnehmen Aber natürlich auf die Screenshots gerade bei mehrere Screenshot pro Issue, also pro erfundene Problem vorhanden sind.

00:01:17: Das macht das ganze Ding sehr umfangreich.

00:01:20: Ich habe auch schon gesehen dass es tatsächlich Unternehmen gibt die das als Powerpoint bereitstellen finde ich persönlich absolut übernüssig weil zumindest im Public Bereich finden wir dann immer noch Leute die das Ding ausdrucken und zwar nicht einmal sondern mehrfach quasi damit jeder eine Kopie hat Und das ist gerade den Powerpoint.

00:01:43: Das ist halt absolute Papierverschwendung, Ressourcenverschwindung finde ich.

00:01:50: Im PTA ist es ein bisschen kompakter in der Regel aber auch da ist es häufig umverreicher als es sein muss.

00:01:57: wenn ihr die Möglichkeit habt und das würde ich auch immer anfordern dann fordert immer etwas an mit dem man weiter arbeiten kann ob das Markdown ist oder das HTML ist, ob das Jason Also irgendwas, was man möglichst automatisiert weiterverarbeiten kann und dann in die Ticketsysteme beschieben kann.

00:02:17: Es wird trotzdem umfangreich sein wie gesagt wegen der Screenshots und der Beschreibungen Und natürlich auch hängt es davon ab, wie viele Probleme gefunden wurden.

00:02:27: Das habe ich im letzten Podcast schon gesagt.

00:02:32: das wird häufig unterschätzt Wie viele Dinge tatsächlich vorhanden sind, aber das gehört dazu der Sache.

00:02:40: Die zweite große Herausforderung ist die Sprache, die dort verwendet wird.

00:02:47: Wir versuchen eigentlich immer Verständlich zu sein was die Problembeschreibungen angeht Das heißt allgemeinverständlich.

00:02:55: unsere Zielgruppe sind jetzt nicht DeveloperInnen sondern wirklich die Allgemeine Personengruppe auch Management.

00:03:05: Da versuchen wir so verständlich wie möglich zu sein, weil wir wissen, wie sind die Barrierefreiheitsexpertinnen und nicht die Leute, die es lesen.

00:03:12: Die sind keine Barrierenfreiheitsexpertenin.

00:03:16: Insofern ist das natürlich für sie immer schwierig.

00:03:19: Auf der anderen Seite sind wir auch dazu gezwungen uns möglichst kompakt zu halten.

00:03:25: Das heißt wir dürfen nicht oder wir können einfach nichts zu viel schreiben.

00:03:29: Also wenn wir jetzt anfangen irgendwelche Area Semantik zu erklären Dann kommen wir wirklich zu keinem Ende und das ist dann auch Prosa, die den Leuten auf der anderen Seite nicht unbedingt weiter hilft.

00:03:45: Das heißt da ist einfach eine Zeitbegrenzung, eine Ressourcene-Begrenzung auf unserer Seite.

00:03:51: aber auch die Geduld der Leute, die es lesen müssen, ist natürlich auch begrenzt oder nicht unbegrenzt.

00:03:59: Insofern müssen wir uns da teilweise kurz passen Und müssen einfach auch davon ausgehen, dass die andere Seite ihren Teil der Arbeit macht.

00:04:08: Nämlich dann zu recherchieren wenn sie zum Beispiel nicht wissen was area bedeutet oder was eine live Region ist Da müssen Sie sich halt damit beschäftigen.

00:04:18: da kommt man beim Thema bei Ihrer Frage nicht vorbei.

00:04:21: Deswegen würde ich euch immer empfehlen holt Euch nicht nur einen Test sondern holt euch auch direkt die Beratung dazu.

00:04:32: also bucht die beratungen am besten bei der stelle, die auch den test durchgeführt hat weil das erfahrungsgemäß viel geschmeidiger läuft.

00:04:41: Das dübste oder das schlechteste was man machen kann ist wirklich so ein test durchführen zu lassen und sie liegen zu lassen.

00:04:48: das habe ich ja auch schon gesehen Also irgendwo abgelegt unter.

00:04:53: wir haben den fest durch geführt damit es unsere arbeit getan so auf dem motto Das kann man doch auch lassen.

00:05:01: Das weit schwierig schlaueste, was wir machen können ist den Prüfbericht nehmen und versuchen den ohne Barrierefreiheitsexpertise umzusetzen.

00:05:11: Es ist natürlich schön wenn man dem Haus hat das kommt gelegentlich vor.

00:05:17: Aber wenn man sie nicht hat, dann ist es wirklich am einfachsten, ihr holt das dort wo ihr die Test habt durchführen lassen oder ihr holst euch eine neutrale Person.

00:05:25: Das geht natürlich auch.

00:05:27: Also eine andere Person oder ein anderes Unternehmen was das Konzerte durchführt.

00:05:34: Ich sage das jetzt nicht weil ich unbedingt mehr Aufträge haben möchte oder meinen Arbeitgeber mehr Auftraggeber, mehr Aufträge haben möchte.

00:05:42: Das auch aber hat.

00:05:44: der Kerngedanke ist wirklich man kriegt es ohne Bayerische Freizeit-Expertise.

00:05:49: Man kriegt das hin Aber es ist relativ zäh und sehr schwierig und relativ fehleranfällig.

00:05:56: Und natürlich kann Dänige des als erstes getestet hat nicht die Verantwortung dafür übernehmen was da mehr dabei rauskommt wenn keine Konsultation mit einer Barrierefreiheitsexperte stattgefunden hat.

00:06:09: So viel dazu.

00:06:11: Worauf sollte man achten, wenn man einen Prüfbericht bekommt?

00:06:15: Erstmal diese Metadaten, also die Kerninformationen sollten immer vorhanden sein.

00:06:20: Das heißt welche Seiten wurden getestet, welcher Test oder welches, welche Kriterienkatalog wurde zur Grunde gelegt.

00:06:29: Also das ist in der Regel E-N-Dranl.

00:06:33: oder die WCAGII, was auch immer das sollte drinstehen.

00:06:37: Auch bei der WCAgII natürlich auch immer welche Priorität, welche Konformitätsstufe also A, AA oder dreifachA.

00:06:49: Das sind so die Dinge die immer im Bett stehen und mit drin stehen sollten.

00:06:52: natürlich solche Banalitäten wie das Datum, welche Firma hat den Test durchgeführt?

00:07:01: Das sind so Dinge, die immer drinstehen sollten.

00:07:04: Das Datum ist deshalb auch wichtig weil natürlich auch Änderungen stattgefunden haben könnten während der Test durchgeführt wurde oder nachdem er testdurch geführt wurde und aber die Ergebnisse bei euch angekommen sind.

00:07:25: Das sind so die Dinge, die immer drin stehen sollten und natürlich solltet ihr das Test entsprechend auch dokumentieren.

00:07:32: Dass diese Informationen alle da sind.

00:07:38: Dann solltete gucken dass der Test oder dass die Beschreibungen möglich verständlich sind.

00:07:44: dann würde ich euch empfehlen wirklich mal drüber zu lesen Und zu gucken.

00:07:49: ist alles soweit verständlich, dass man sagen kann okay die Developer auch ohne bei ihrer Freiheitserfahrung können das soweit nachvollziehen.

00:07:59: Wie gesagt nicht jeder einzelne Begriff ist verständig.

00:08:04: vielleicht noch eine Sache dazu zur Verständlichkeit.

00:08:06: wir müssen einfach auch immer die Fachbegriffe verwenden.

00:08:10: ich sage schon area Maschinenlichtbarkeit Semantik Das sind Begriffe mit denen wir täglich arbeiten und uns durchaus bewusst dass es nicht alle Menschen in der IT tun.

00:08:24: Aber es ist deshalb wichtig, weil die Leute, die es dann umsetzen wollen, es ja auch recherchieren müssen.

00:08:32: und wenn ich da irgendwas hinschreibe wie... keine Ahnung wie man Maschinenlespakate übersetzen kann.

00:08:40: Wenn ich da etwas hinscheibe was nicht den Fachbegriff entspricht, dann werden die Leute auch ganz große Probleme haben das zu recherchieren auf eigene Faust.

00:08:48: Das ist ja doch das Ziel von uns dass sie jetzt selber herausfinden können.

00:08:53: deswegen sind wir darauf angemessen diese Fachbegriffe zu verwenden und ich finde es auch relativ hilfreich.

00:09:01: aber deswegen ist es auch sinnvoll wirklich immer die englischen Begriffe gerade bei Area usw.

00:09:05: zu verwende weil viele Sachen sind auf Deutsch nicht wirklich gut dokumentiert Und die Übersetzung ist auch nicht immer einheitlich.

00:09:15: Bei der WCA geht zum Beispiel... Ich habe keine Ahnung, wie viele deutsche Übersetzungen es davon gibt aber ich schätze mal mindestens drei oder vier.

00:09:23: Also es gibt die Üversetzung von der EN in eine deutsche Version.

00:09:31: Da gibt es die Üersetzung für den DIRS im BIKBET-Fortest und vielleicht noch eins, zwei weitere weiß das schon.

00:09:42: Aber das Problem ist, die sind halt sich nicht immer einig.

00:09:45: Und deswegen ist es immer sinnvoller tatsächlich die engischen Begriffe zu verwenden, weil man die besser recherchieren kann und weil es dazu deutlich mehr Informationen gibt.

00:10:01: Die Kernfrage auch ist die Prüfungen oder die Dokumentation der Prüfschritte.

00:10:08: ist das wirklich vollständig?

00:10:12: also sind da wirklich die Sachen aus ausgestabiert, die man dafür benötigt.

00:10:17: Das ist einmal der WCRG Prüfschritt oder der EN-Prüfschritte.

00:10:23: das ist die Problembeschreibung, das ist eine mögliche Lösung oder wie heißt es einer nicht eine?

00:10:35: Das erwünschte Verhalten also als Verbindung muss immer drin sein, das erwünschele Verhalten läuft falsch und wie sollte es eigentlich sein?

00:10:48: Und was auch immer wichtig ist, welches Prüfbergzeug wurde benutzt.

00:10:53: Es gibt ein paar Sachen die rein visuell geprüft werden so etwas wie sinnvolle Reihenfolge oder solche Dinge weil das... Das ist einfach eine Einschätzung die man auf Basis der visuellen Reihenvoll betreffen muss ob sie sinnvoll ist.

00:11:10: Aber für viele andere Prüfschritte oder so was wie Kontrast, das ist relativ objektiv.

00:11:15: Dafür gibt es eigene Tools wie Contrast Checker und so weiter.

00:11:18: aber es ist im Prinzip egal welches Tool man benutzt kommt immer das gleiche raus.

00:11:25: Andererseits gibt es Bereiche wie Area zum Beispiel wo es dann ganz wichtig ist zu gucken welches tool wurde wirklich benutzt um es reproduzieren zu können.

00:11:37: Das ist ganz wichtig, dass man das Problem reproduziern kann, weil wenn man sich reproduzieren kann, dann ist es ganz schwierig selbst zu beheben.

00:11:47: Also wirklich auch gucken sind die Beschreibungen so gestaltet, die Sachen produzieren kann und sind tituls dokumentiert, mit denen getestet wurde.

00:11:59: Das ist vor allem wichtig bei wenn man Screenreader zum Beispiel benutzt hat oder bei den Prüfstritt.

00:12:07: elf Punkt sieben.

00:12:08: Benutzt hat nicht der Einstellungen weil da herrscht gar keine Einigkeit was ein finanziell eigentlich geprüft werden soll.

00:12:16: elf Punkt Sieben.

00:12:18: Und da muss natürlich wissen okay welche Einstellung hat die Person benutzt?

00:12:23: um benutzertifizierte Einstellungen zu simulieren, damit man das selber bei sich reproduzieren kann und dann auch so korrigieren kann wie es im Prüfbericht beschrieben wurde.

00:12:43: Welche Aufgaben fallen jetzt auf der Seite des Auftrag-Liebers an?

00:12:49: Ich glaube die erste Schritt ist wirklich zu gucken, da.

00:12:53: der erste Schritt ist natürlich diese Vorstelligkeitsprüfung.

00:12:55: Das habe ich gerade erläutert!

00:12:56: Der zweite Schritt ist dann zur Übersetzung des ganzen Konvolutes in die eigene Sprache.

00:13:06: das heißt ich muss gucken dass zum Beispiel es gibt ja interne Sprachregelungen wie wird eine Komponente genannt und solche Dinge dass sich diese Übersetzungsleistung vollbringe Bevor ich die ganze Dinger in ein Ticket gieße, das mache natürlich dann der nächste Schritt.

00:13:26: Dass man Tickets aus den einzelnen Berichtsteilen erstellt.

00:13:33: Das Problem ist ja – das habe ich glaube ich beim letzten Mal nicht so stark hervorgehoben – dass die WCAG sehr checklistenorientiert und nicht komponentenorientierte.

00:13:46: Das heißt im Prinzip, ich laufe mit einer Checkliste die einzelne Komponenten durch von einer Applikation.

00:13:55: Und dann gehe ich halt von eins als eins zu vier zwei... Keine Ahnung was der letzte Schritt ist.

00:14:02: Ich glaube vier als drei ist der letzte.

00:14:04: Vier als drei gehe ich einfach von oben nach unten durch und gehe jede Komponente daraufhin durch und das ist aber nicht komponentenorientiert.

00:14:13: Und die meisten Teams arbeiten ja heute auf Basis von Komponenten,

00:14:17: d.h.,

00:14:18: ich muss es wahrscheinlich oder ich muss das auf jeden Fall um die einzelne Prüfschritte den Komponenten zu ordnen, muss eventuell mehrere Sachen unterschiedlich dem Kompontanten zuordnen, weil zum Beispiel Kontrastprobleme werden einfach alle in einem Bruchschritt zusammengefasst, aber es sind ja unterschiedliche Komponsenten auch dieser Kontrastthema zutrifft.

00:14:38: Das macht das Ganze ein bisschen anstrengend, aber da kommt man nicht halt an sich dran vorbei.

00:14:43: Es sei denn, man bittet den Konsalten so ein, dass er weiß welche Komponente, wie er die Prüfschlüsse den Komponenten zuordnet, dass Eisband als Außenstehender einfach nicht und das ist die Übersetzungsleistung, die man machen muss also wirklich die Sprache so anpassen, dass es mit der eigenen Sprachkonvention in dem jeweiligen Team passt.

00:15:08: Dann die Erstellung der Tickets wie gesagt.

00:15:11: Hier auch direkt die Zuordnung zu den jeweiligen Teams, das ist relativ viel Arbeit aber das muss leider gemacht werden.

00:15:20: Das hängt natürlich auch davon ab wie das Team aufgebaut ist, eventuell sind ja mehrere Leute direkt an dem Bericht dran und können sich einfach die Sachen rauspecken, die zu ihrem jeweiligem Team gehören.

00:15:33: Das ist auch eine gute Möglichkeit.

00:15:38: Und dann gegebenenfalls natürlich die User Stories erstellen.

00:15:41: Das gehört ja heute vielfach dazu, dass man User Stories baut und die müssen natürlich auch entsprechend integriert werden.

00:15:50: Auch hier keine Ahnung ob das der Protagoner macht oder die jeweiligen Developer wahrscheinlich letzteres damit das Ganze noch mal viel greif höher wird.

00:16:13: Das wichtigste Thema ist das Thema Priorisierung der gefundenen Sachen.

00:16:20: Ich habe ja schon erfolge herum, es wird sehr wahrscheinlich so sein dass es sehr umfangreiche Prüperichte gibt mit Dutzenden oder hundert von gefunden Problemen und das kann man nicht in einem Rutsch abarbeiten und ich meine im Jahr abarbeiten nachdem die Großsysteme ist sondern das ist eine größere Geschichte Und deswegen muss man die Sachen natürlich priorisieren.

00:16:50: Jetzt hängt es davon ab wie man priorisiert möchte, da gibt's mehrere Möglichkeiten.

00:16:55: Einmal eine Möglichkeit ist das Thema gucken welche Sachen sind die wichtigsten Blocker?

00:17:03: also welche Sachen müssen auf jeden Fall relativ schnell gelöst werden?

00:17:09: Das ist eine Möglichkeit.

00:17:11: Dann eine Möglichkeit ist aber auch Quick-Mins, also Dinge die relativ schnell gelöst werden können.

00:17:19: Das hat einfach den Vorteil dass das Team dann motiviert wird nochmal weiter zu machen mit größeren Sachen.

00:17:26: Da gibt es natürlich immer Komponenten an denen bereits gearbeitet wird.

00:17:31: Dann macht es natürlich Sinn da direkt bei ihrer Freiheitsanforderung direkt mit reinzukippen um sie dann direkt zur Berücksichtigen.

00:17:40: Manchmal erledigen sich auch Tickets von selbst, wenn man sagt okay diese Komponente ist veraltet und wird sowieso rausgenommen.

00:17:46: Vielleicht kann man da sagen ok wir nehmen sie früher heraus Und dann müssen wir das bei ihrem freien Thema bei dieser Komponenten nicht berücksichtigen.

00:17:55: Es ist auch eine gute Möglichkeit Unter natürlich die Tickets die einfach einen hohen Aufwand haben und vielleicht aber auch zurückgestellt werden können.

00:18:10: Da kann man gucken kann man vielleicht ein bisschen warten, bis mal diese Tickets angeht und sie vielleicht irgendwann später angehen.

00:18:19: Nicht irgendwann sondern wirklich später angehnen.

00:18:23: Vielleicht noch eine Sache die uns häufig zugetragen wird oder die häufig viel interpretiert wird?

00:18:31: Ich will das nochmal hervorheben.

00:18:35: Alles was als Fehler markiert wird ist ein Fehler der behoben werden muss.

00:18:44: Ich habe es schon mal gesagt, ich erkläre das nochmal ganz kurz, das Thema Konformität.

00:18:50: eine Angebot ist nur dann bei ihrer frei beziehungsweise konform wenn alle Fehler behoben wurden.

00:19:01: Ich bin persönlich kein Fan von diesem Konformitätskonzept.

00:19:04: aber das ist nun mal so, das ist Law, das Gesetz, da kann man nichts machen.

00:19:09: Das heißt auch wenn Konsultant sagt, ein Problem ist nicht schwerwiegend.

00:19:17: Also es runterpriorisiert.

00:19:19: Das machen die Konsultants häufig, dass sie Probleme priorisieren.

00:19:24: auch wenn die Leute das runterprioritiert haben heißt es nicht, dass es nicht gelöst werden muss.

00:19:29: Auch Low Priority-Probleme müssen gelöst sein.

00:19:34: Ich hebe das so stark hervor weil es häufig missverstanden wird gerade auf der anderen Seite.

00:19:40: aber der Product Owner Der Projektverantwortliche muss da wirklich ein Auge drauf haben, nur weil diese Dinge gering priorisiert wurden heißt es nicht dass man sie nicht lösen muss.

00:19:51: Was man hier unterscheiden muss sind zwei Sachen nämlich einmal Fehler und Empfehlungen.

00:19:57: Ich glaube die meisten Konsulting-Unternehmen unterscheidet das zwischen Fehlern und Empfehlungen.

00:20:04: Empfehnungen sind genau das.

00:20:06: Empfehmungen müssen nicht befolgt werden können befolgswerden.

00:20:12: Fehler müssen in jedem Fall behoben werden, ob sie heute oder morgen behoben.

00:20:18: Das ist eine andere Frage aber Sie müssen auf jeden Fall behuben werden.

00:20:22: Meine letzte Empfehlung ist In der Regel bietet der Konsultant oder das Unternehmen der Auftragnehmer auch eine Sprechstunde an.

00:20:36: zu dem Prüfbericht.

00:20:37: also wir machen es standardmäßig von der ADESO dass man sagt, okay wir sprechen den Prüfbericht einmal durch und das würde ich euch empfehlen.

00:20:45: Macht das auf jeden Fall!

00:20:47: Lasst euch dabei nicht zu viel Zeit weil die Konsultants ja ziemlich viel testen.

00:20:52: also ich habe glaube ich in meiner Rekordzeit irgendwie drei vier Websites pro Monat getestet oder Angebote getestete Und natürlich versuchen mir das so zu dokumentieren dass wir uns auch alles selber gut merken können.

00:21:09: Aber ich könnte jetzt nicht sagen, aus dem Kopf heraus was ich letztes Jahr getestet habe.

00:21:17: Was da konkrete Probleme waren.

00:21:19: Nach zwei drei Wochen hab' ich noch ganz gut im Gedächtnis aber nach einem Jahr oder so ist es einfach alles weg.

00:21:25: Das heißt ich muss mich da selber nochmal einlesen.

00:21:28: Es ist alles okay?

00:21:29: Aber ich würde euch empfehlen macht das so schnell wie möglich.

00:21:32: Nachdem ihr euch den Prüfbericht einmal angeguckt habt... Stellt Rückfragen, nutzt diese Möglichkeit auf jeden Fall.

00:21:41: Da gibt es natürlich ein Limit.

00:21:42: also man kann sich unendlich viele Rückfragungen stellen weil dann die Leute sagen Leute ihr habt einen Test bezahlt und keine Beratung.

00:21:50: das müsste man im Hinterkopf haben.

00:21:52: aber nutzt auf jeden fall die Möglichkeit euch beraten zu lassen zu dem Prüfbericht oder wenn ihr über Rückfrage zu den prüfberichten habt Und natürlich wenn es da Unklarheiten gibt.

00:22:02: also wenn ihr denkt okay dass ist nicht präzise genug beschrieben dann muss das auch im Rahmen des Testvolumens gegeben sein, dass diese Frage kostenlos beantwortet wird.

00:22:16: Wer dir sagt okay die Frage oder das Problem ist nicht präzise genug beschrieben worden?

00:22:21: Oder eventuell hat der Konsultant irgendeine Fehlentschätzung gemacht, dass es vollkommen legitim danach zu fragen.

00:22:28: Gut, das war's für heute!

00:22:29: Ich hoffe ihr konntet etwas aus dem Beitrag mitnehmen und würde mich freuen wenn er nächste Woche wieder einschaltet Bis bald.