{"id":10802,"date":"2026-05-15T17:57:09","date_gmt":"2026-05-15T15:57:09","guid":{"rendered":"https:\/\/www.netz-barrierefrei.de\/wordpress\/?p=10802"},"modified":"2026-05-15T18:03:08","modified_gmt":"2026-05-15T16:03:08","slug":"umgang-mit-pruefberichten-zur-digitalen-barrierefreiheit-tipps-fuer-auftraggebende","status":"publish","type":"post","link":"https:\/\/www.netz-barrierefrei.de\/wordpress\/umgang-mit-pruefberichten-zur-digitalen-barrierefreiheit-tipps-fuer-auftraggebende\/","title":{"rendered":"Umgang mit Pr\u00fcfberichten zur digitalen Barrierefreiheit: Tipps f\u00fcr Auftraggebende"},"content":{"rendered":"<p><iframe loading=\"lazy\" src=\"https:\/\/digitale-barrierefreiheit.podigee.io\/358-umgang-mit-dem-prufbericht\/embed?context=external&#038;theme=default\" style=\"border: 0\" frameBorder=\"0\" height=\"100\" width=\"100%\"><\/iframe><br \/>\nHeute geht es darum, wie man aus Kundensicht auf Pr\u00fcfberichte blicken und wie man mit ihnen umgehen sollte.<\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_83 counter-hierarchy ez-toc-counter ez-toc-white ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Inhalt<\/p>\n<span class=\"ez-toc-title-toggle\"><a href=\"#\" class=\"ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle\" aria-label=\"Toggle Table of Content\"><span class=\"ez-toc-js-icon-con\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/span><\/a><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/umgang-mit-pruefberichten-zur-digitalen-barrierefreiheit-tipps-fuer-auftraggebende\/#Warum_sind_Pruefberichte_so_umfangreich\" >Warum sind Pr\u00fcfberichte so umfangreich?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/umgang-mit-pruefberichten-zur-digitalen-barrierefreiheit-tipps-fuer-auftraggebende\/#Die_Herausforderung_mit_der_Fachsprache\" >Die Herausforderung mit der Fachsprache<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/umgang-mit-pruefberichten-zur-digitalen-barrierefreiheit-tipps-fuer-auftraggebende\/#Beratung_sichert_den_Erfolg\" >Beratung sichert den Erfolg<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/umgang-mit-pruefberichten-zur-digitalen-barrierefreiheit-tipps-fuer-auftraggebende\/#Checkliste_Worauf_solltet_ihr_bei_einem_Pruefbericht_achten\" >Checkliste: Worauf solltet ihr bei einem Pr\u00fcfbericht achten?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/umgang-mit-pruefberichten-zur-digitalen-barrierefreiheit-tipps-fuer-auftraggebende\/#Transparenz_bei_den_Pruefwerkzeugen\" >Transparenz bei den Pr\u00fcfwerkzeugen<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/umgang-mit-pruefberichten-zur-digitalen-barrierefreiheit-tipps-fuer-auftraggebende\/#Welche_Aufgaben_fallen_beim_Auftraggeber_an\" >Welche Aufgaben fallen beim Auftraggeber an?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/umgang-mit-pruefberichten-zur-digitalen-barrierefreiheit-tipps-fuer-auftraggebende\/#Priorisierung_der_Aufgaben\" >Priorisierung der Aufgaben<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/umgang-mit-pruefberichten-zur-digitalen-barrierefreiheit-tipps-fuer-auftraggebende\/#Wichtiger_Hinweis_zur_Konformitaet_Fehler_vs_Empfehlungen\" >Wichtiger Hinweis zur Konformit\u00e4t: Fehler vs. Empfehlungen<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/umgang-mit-pruefberichten-zur-digitalen-barrierefreiheit-tipps-fuer-auftraggebende\/#Nutzt_die_Nachbesprechung\" >Nutzt die Nachbesprechung<\/a><\/li><\/ul><\/nav><\/div>\n<h2><span class=\"ez-toc-section\" id=\"Warum_sind_Pruefberichte_so_umfangreich\"><\/span>Warum sind Pr\u00fcfberichte so umfangreich?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Zuerst einmal solltet ihr generell damit rechnen, dass diese Pr\u00fcfberichte sehr umfangreich sind. Ich wei\u00df zwar nicht, wie kompakt ein klassischer Software-Testbericht aussieht, aber ich vermute, diese sind etwas k\u00fcrzer.<\/p>\n<p>Dass Berichte zur Barrierefreiheit so lang sind, liegt an den vielen Meta-Informationen. Es gibt eine ausf\u00fchrliche Einleitung, in der die Rahmenbedingungen dokumentiert werden, und jeder einzelne Pr\u00fcfschritt wird genau aufgef\u00fchrt. Den meisten Platz nimmt jedoch die Dokumentation der Fehler ein \u2013 vor allem durch die Beschreibungen und die Screenshots. Gerade wenn mehrere Screenshots pro Issue (also pro gefundenem Problem) enthalten sind, bl\u00e4ht das den Bericht auf.<\/p>\n<p>Ich habe schon erlebt, dass Unternehmen diese Berichte als PowerPoint-Pr\u00e4sentation bereitstellen. Das halte ich pers\u00f6nlich f\u00fcr absolut \u00fcberfl\u00fcssig. Besonders im \u00f6ffentlichen Dienst gibt es leider immer noch Personen, die solche Berichte ausdrucken \u2013 und das oft mehrfach, damit jeder eine Kopie hat. Bei PowerPoint ist das reine Papier- und Ressourcenverschwendung. In einer PDF-Datei ist es in der Regel etwas kompakter, aber oft immer noch umfangreicher als n\u00f6tig. Wenn ihr die Wahl habt \u2013 und das solltet ihr immer so einfordern \u2013, verlangt ein Format, mit dem man direkt weiterarbeiten kann. Das kann Markdown, HTML oder JSON sein. Also ein Format, das sich m\u00f6glichst automatisiert weiterverarbeiten und direkt in Ticket-Systeme (wie Jira) \u00fcberspielen l\u00e4sst. Umfangreich bleibt es wegen der Screenshots und Beschreibungen trotzdem, und es h\u00e4ngt nat\u00fcrlich davon ab, wie viele Barrieren gefunden wurden. Das wird h\u00e4ufig untersch\u00e4tzt, geh\u00f6rt aber dazu.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Die_Herausforderung_mit_der_Fachsprache\"><\/span>Die Herausforderung mit der Fachsprache<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Die zweite gro\u00dfe Herausforderung ist die Sprache. Wir Barrierefreiheits-Expertinnen versuchen immer, die Problembeschreibungen allgemein verst\u00e4ndlich zu formulieren. Unsere Zielgruppe beim Kunden sind ja nicht nur Entwicklerinnen und Entwickler, sondern auch das Management oder die Projektleitung. Wir wissen, dass die Lesenden in der Regel keine Fachleute f\u00fcr Barrierefreiheit sind.<\/p>\n<p>Auf der anderen Seite m\u00fcssen wir uns kurz fassen. Wenn wir anfangen, tiefere Details wie die genaue ARIA-Semantik im Bericht zu erkl\u00e4ren, nimmt das kein Ende. Das w\u00e4re zu viel Text, der den Beteiligten vor Ort oft gar nicht weiterhilft. Hier sto\u00dfen wir an Zeit- und Ressourcen-Grenzen \u2013 und auch die Geduld der Lesenden ist nicht unbegrenzt.<br \/>\nAchtet darauf, ob die Beschreibungen verst\u00e4ndlich sind. Lest am besten stichprobenartig rein und pr\u00fcft, ob die Entwicklungsteams damit arbeiten k\u00f6nnen. Nat\u00fcrlich wird nicht jeder Begriff sofort klar sein. Wir m\u00fcssen in den Berichten Fachbegriffe wie ARIA, Maschinenlesbarkeit oder Semantik verwenden. Das tun wir, damit die Entwicklerinnen und Entwickler die Probleme exakt recherchieren k\u00f6nnen. Wenn wir hier ungenaue Begriffe verwenden, wird die eigene Recherche im Netz extrem schwierig.<\/p>\n<p>Dabei ist es oft sinnvoller, die englischen Fachbegriffe (gerade bei ARIA) zu nutzen. Auf Deutsch ist vieles nicht gut oder uneinheitlich dokumentiert. Von der WCAG gibt es beispielsweise mehrere deutsche \u00dcbersetzungen (die offizielle \u00dcbersetzung, die Fassung aus der BITV, die Version f\u00fcr den EN-Standard etc.), die sich nicht immer einig sind. Mit den englischen Begriffen findet man beim Recherchieren deutlich mehr und pr\u00e4zisere Informationen.<\/p>\n<p>Deshalb m\u00fcssen wir voraussetzen, dass die Kundenseite ihren Teil der Arbeit leistet. Wenn Begriffe wie \u201eARIA\u201c oder \u201eLive-Regionen\u201c unklar sind, muss man diese selbst recherchieren. Um dieses Thema kommt man bei der Barrierefreiheit nicht herum.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Beratung_sichert_den_Erfolg\"><\/span>Beratung sichert den Erfolg<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Deshalb empfehle ich euch dringend: Buche nicht nur den reinen Test, sondern hole dir direkt die passende Beratung dazu. Am besten beauftragt man die Beratung bei der Stelle, die auch den Test durchgef\u00fchrt hat, weil das erfahrungsgem\u00e4\u00df viel reibungsloser abl\u00e4uft.<\/p>\n<p>Das Schlechteste, was man tun kann, ist, einen Test machen zu lassen und den Bericht dann in der Schublade liegenzulassen \u2013 frei nach dem Motto: \u201eWir haben den Test gemacht, damit ist unsere Pflicht erf\u00fcllt.\u201c Das ist v\u00f6lliger Quatsch, dann kann man es auch gleich lassen.<\/p>\n<p>Der zweitgr\u00f6\u00dfte Fehler ist es, den Pr\u00fcfbericht ohne entsprechendes Fachwissen im eigenen Team umsetzen zu wollen. Es ist toll, wenn man diese Expertise im Haus hat. Wenn nicht, ist es am einfachsten, sich Unterst\u00fctzung zu holen \u2013 entweder von der Pr\u00fcfstelle oder von einer neutralen Person f\u00fcr das Consulting.<\/p>\n<p>Ich sage das nicht, um mehr Auftr\u00e4ge zu generieren, sondern weil die Praxis zeigt: Ohne Barrierefreiheits-Expertise ist die Umsetzung extrem z\u00e4h, schwierig und fehleranf\u00e4llig. Zudem kann die Pr\u00fcfstelle nat\u00fcrlich keine Verantwortung f\u00fcr das Endergebnis \u00fcbernehmen, wenn es vorab keine fachliche Abstimmung gab.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Checkliste_Worauf_solltet_ihr_bei_einem_Pruefbericht_achten\"><\/span>Checkliste: Worauf solltet ihr bei einem Pr\u00fcfbericht achten?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Wenn ihr einen Pr\u00fcfbericht erhaltet, sollten die folgenden Kerninformationen (Metadaten) immer enthalten sein:<\/p>\n<p>&#8211; Gepr\u00fcfte Seiten\/Ansichten: Welche Teile des Produkts wurden getestet?<br \/>\n&#8211; Kriterienkatalog: Welcher Standard wurde zugrunde gelegt? (In der Regel die europ\u00e4ische Norm EN 301 549 oder die WCAG 2.2).<br \/>\n&#8211; Konformit\u00e4tsstufe: Bei der WCAG sollte immer dabei stehen, welche Stufe gepr\u00fcft wurde (A, AA oder AAA).<br \/>\n&#8211; Basisdaten: Das Pr\u00fcfdatum und der Name der pr\u00fcfenden Firma. Das Datum ist wichtig, weil sich am Produkt w\u00e4hrend oder nach dem Test noch Dinge ge\u00e4ndert haben k\u00f6nnten.<\/p>\n<p>Die Kernfrage lautet: Ist die Dokumentation der Pr\u00fcfschritte wirklich vollst\u00e4ndig? Ein gut dokumentierter Mangel muss immer folgende Elemente enthalten:<\/p>\n<p>1. Den konkreten WCAG- oder EN-Pr\u00fcfschritt.<br \/>\n2. Die genaue Problembeschreibung.<br \/>\n3. Einen L\u00f6sungsvorschlag oder das erwartete Verhalten (Soll-Zustand).<\/p>\n<p>Es muss also immer klar daraus hervorgehen: Was l\u00e4uft aktuell falsch und wie sollte es eigentlich aussehen?<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Transparenz_bei_den_Pruefwerkzeugen\"><\/span>Transparenz bei den Pr\u00fcfwerkzeugen<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Ein weiterer wichtiger Aspekt ist die Frage: Welche Pr\u00fcfwerkzeuge wurden benutzt? Einige Kriterien werden rein visuell gepr\u00fcft, wie zum Beispiel eine sinnvolle Reihenfolge der Inhalte. Das l\u00e4sst sich oft nur auf Basis einer menschlichen Einsch\u00e4tzung beurteilen. Viele andere Pr\u00fcfschritte, wie etwa Kontraste, sind dagegen sehr objektiv. Daf\u00fcr gibt es spezielle Tools wie Kontrast-Checker. Welches Tool man daf\u00fcr genau nutzt, ist im Grunde egal, da immer das gleiche Ergebnis herauskommen sollte.<\/p>\n<p>Andererseits gibt es Bereiche wie ARIA, bei denen es extrem wichtig ist zu dokumentieren, welches Tool konkret verwendet wurde. Nur so lassen sich die Fehler sp\u00e4ter exakt reproduzieren. Das ist f\u00fcr die Behebung entscheidend: Wenn man einen Fehler nicht reproduzieren kann, ist es unglaublich schwer, ihn zu korrigieren. Achtet also darauf, dass die Beschreibungen so gestaltet sind, dass das umsetzende Team die Probleme nachstellen kann und die verwendeten Werkzeuge dokumentiert sind.<\/p>\n<p>Besonders wichtig ist das beim Einsatz von Screenreadern oder beim Pr\u00fcfschritt 11.7 (Benutzerdefinierte Einstellungen) aus der EN 301 549. In diesem Bereich herrscht oft Uneinigkeit dar\u00fcber, wie genau gepr\u00fcft werden soll. Hier m\u00fcsst ihr wissen, welche Einstellungen die pr\u00fcfende Person genutzt hat, um benutzerdefinierte Ansichten zu simulieren. Nur so k\u00f6nnt ihr das Verhalten bei euch reproduzieren und im Sinne des Pr\u00fcfberichts korrigieren.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Welche_Aufgaben_fallen_beim_Auftraggeber_an\"><\/span>Welche Aufgaben fallen beim Auftraggeber an?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>1. Die Vollst\u00e4ndigkeitspr\u00fcfung: Wie gerade beschrieben, solltet ihr pr\u00fcfen, ob alle wichtigen Meta-Daten und verst\u00e4ndliche Beschreibungen vorliegen.<br \/>\n2. Die \u00dcbersetzung in die eigene Fachsprache: Ihr m\u00fcsst das gesamte Konvolut an Daten in eure interne Sprache \u00fcbersetzen. Jedes Unternehmen hat eigene Sprachregelungen und Bezeichnungen f\u00fcr bestimmte Komponenten. Diese \u00dcbersetzungsarbeit solltet ihr leisten, bevor ihr die M\u00e4ngel in ein Ticket-System gie\u00dft.<br \/>\n3. Tickets komponentenorientiert erstellen: Die WCAG ist sehr checklistenorientiert und leider nicht komponentenorientiert aufgebaut. Man arbeitet sich von oben nach unten durch die Liste (von Erfolgskriterium 1.1.1 bis zum letzten, meist 4.1.3) und pr\u00fcft das gesamte Produkt daraufhin ab. Moderne Software-Teams arbeiten heute jedoch fast ausschlie\u00dflich mit Komponenten.<br \/>\nDas bedeutet f\u00fcr euch: Ihr m\u00fcsst die einzelnen Pr\u00fcfschritte den jeweiligen Komponenten eurer Anwendung zuordnen. Ein konkretes Beispiel: Kontrastprobleme werden im Bericht meist alle in einem einzigen Pr\u00fcfschritt gesammelt. Betroffen sind davon aber oft v\u00f6llig unterschiedliche Komponenten (z. B. der Header, ein Button und der Footer). Ihr m\u00fcsst diese M\u00e4ngel also aufteilen. Das ist etwas m\u00fchsam, l\u00e4sst sich aber kaum vermeiden \u2013 es sei denn, ihr bindet eine Beratung so tief ein, dass diese eure internen Komponenten kennt und die Zuordnung direkt \u00fcbernimmt. Als Au\u00dfenstehender wei\u00df man das sonst schlichtweg nicht.<br \/>\n4. Tickets zuweisen und User Stories erstellen: Nach der Erstellung m\u00fcssen die Tickets den passenden Teams zugeordnet werden. Je nach Teamstruktur k\u00f6nnen sich die Beteiligten die f\u00fcr sie relevanten Punkte auch selbst heraussuchen. Zudem sollten hieraus \u2013 meist durch die Entwicklerinnen oder die Product Owner \u2013 passende User Stories geschrieben werden, um die Anforderungen f\u00fcr die Praxis greifbar zu machen.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Priorisierung_der_Aufgaben\"><\/span>Priorisierung der Aufgaben<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Ein umfassender Pr\u00fcfbericht enth\u00e4lt schnell Dutzende oder Hunderte von M\u00e4ngeln. Es ist v\u00f6llig klar, dass man das nicht in einem Rutsch und oft nicht einmal in einem Jahr abarbeiten kann. Deshalb m\u00fcsst ihr die Aufgaben sinnvoll priorisieren. Hierzu gibt es verschiedene Ans\u00e4tze:<\/p>\n<p>&#8211; Kritische Blocker zuerst: Welche Barrieren hindern Nutzende komplett an der Bedienung und m\u00fcssen sofort gel\u00f6st werden?<br \/>\n&#8211; Quick Wins mitnehmen: Das sind Fehler, die sich schnell und mit wenig Aufwand beheben lassen. Das motiviert das Team, weil man schnell Erfolge sieht, bevor man die dicken Bretter bohrt.<br \/>\n&#8211; Synergien nutzen: Wenn an einer Komponente ohnehin gerade gearbeitet wird, solltet ihr die Barrierefreiheitsanforderungen dort direkt mit einflie\u00dfen lassen.<br \/>\n&#8211; Veraltete Komponenten aussortieren: Manchmal erledigen sich Tickets von selbst. Wenn eine fehlerhafte Komponente ohnehin bald wegfallen soll, kann man den Austausch eventuell vorziehen und spart sich so die Behebung des Fehlers in der alten Version.<br \/>\n&#8211; Aufwendige Tickets zur\u00fcckstellen: Komplexe Probleme mit hohem Aufwand, die nicht kritisch sind, kann man bewusst f\u00fcr einen sp\u00e4teren Zeitpunkt einplanen.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Wichtiger_Hinweis_zur_Konformitaet_Fehler_vs_Empfehlungen\"><\/span>Wichtiger Hinweis zur Konformit\u00e4t: Fehler vs. Empfehlungen<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Es wird auf Kundenseite oft missverstanden, daher betone ich es noch einmal ganz deutlich: Alles, was im Bericht als Fehler markiert ist, muss zwingend behoben werden.<\/p>\n<p>Das Gesetz verlangt Konformit\u00e4t. Eine Anwendung ist rechtlich gesehen erst dann barrierefrei beziehungsweise konform, wenn alle Fehler beseitigt wurden. Pr\u00fcfstellen priorisieren Fehler zwar oft in \u201ehoch\u201c, \u201emittel\u201c oder \u201egering\u201c, um euch eine Orientierung zu geben. Aber auch ein Fehler mit \u201egeringer Priorit\u00e4t\u201c bleibt ein Fehler und muss gel\u00f6st werden.<\/p>\n<p>Unterscheiden m\u00fcsst ihr dabei zwischen zwei Kategorien:<\/p>\n<p>&#8211; Fehler: M\u00fcssen in jedem Fall behoben werden (ob heute oder morgen, ist eine Frage eurer Priorisierung).<br \/>\n&#8211; Empfehlungen (Best Practices): Sind genau das \u2013 Empfehlungen. Sie optimieren die Usability, sind aber f\u00fcr die rechtliche Konformit\u00e4t nicht zwingend erforderlich.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Nutzt_die_Nachbesprechung\"><\/span>Nutzt die Nachbesprechung<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>In der Regel bieten Pr\u00fcfstellen nach der \u00dcbergabe des Berichts eine Sprechstunde oder eine Nachbesprechung an. Wir bei Adesso machen das standardm\u00e4\u00dfig so, und ich kann euch nur empfehlen: Nutzt diese Gelegenheit!<\/p>\n<p>Lasst euch damit aber nicht zu viel Zeit. Barrierefreiheits-Expertinnen und -Experten testen sehr viel. In meiner Spitzenzeit habe ich 30 bis 40 Websites und Anwendungen pro Monat gepr\u00fcft. Wir dokumentieren zwar so pr\u00e4zise wie m\u00f6glich, damit wir uns auch selbst wieder hineindenken k\u00f6nnen. Aber nach ein paar Monaten wei\u00df niemand mehr aus dem Kopf, was die konkreten Probleme bei einem bestimmten Projekt waren. Nach zwei bis drei Wochen ist die Erinnerung noch frisch, nach einem Jahr ist sie weg.<\/p>\n<p>Schaut euch den Bericht also z\u00fcgig an und stellt eure R\u00fcckfragen zeitnah. Nat\u00fcrlich gibt es dabei Grenzen \u2013 eine unendlich lange Beratung ist im reinen Testbudget meist nicht enthalten. Aber Unklarheiten oder ungenaue Beschreibungen im Bericht zu kl\u00e4ren, geh\u00f6rt absolut dazu. Es ist vollkommen legitim nachzufragen, wenn etwas nicht pr\u00e4zise genug beschrieben wurde oder ihr eine Einsch\u00e4tzung anders seht. <\/p>\n","protected":false},"excerpt":{"rendered":"<p>Heute geht es darum, wie man aus Kundensicht auf Pr\u00fcfberichte blicken und wie man mit ihnen umgehen sollte. Warum sind Pr\u00fcfberichte so umfangreich? Zuerst einmal&#8230;<\/p>\n<div class=\"more-link-wrapper\"><a class=\"more-link\" href=\"https:\/\/www.netz-barrierefrei.de\/wordpress\/umgang-mit-pruefberichten-zur-digitalen-barrierefreiheit-tipps-fuer-auftraggebende\/\">Weiterlesen<span class=\"screen-reader-text\">Umgang mit Pr\u00fcfberichten zur digitalen Barrierefreiheit: Tipps f\u00fcr Auftraggebende<\/span><\/a><\/div>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-10802","post","type-post","status-publish","format-standard","hentry","category-allgemein","entry"],"_links":{"self":[{"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/posts\/10802","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/comments?post=10802"}],"version-history":[{"count":2,"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/posts\/10802\/revisions"}],"predecessor-version":[{"id":10804,"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/posts\/10802\/revisions\/10804"}],"wp:attachment":[{"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/media?parent=10802"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/categories?post=10802"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.netz-barrierefrei.de\/wordpress\/wp-json\/wp\/v2\/tags?post=10802"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}