Infothek Tests Testempfehlungen BITV 2.0 Vorprüfungstest
Das Rahmenkonzept des Aktionsbündnisses für barrierefreie Informationstechnik zur Überprüfung von Barrierefreiheit entstand noch vor der Verabschiedung der Barrierefreien Informationstechnik-Verordnung - BITV 2.0. Prinzipiell kann das Rahmenkonzept mit drei aufeinander aufbauenden einzelnen Testverfahren bestehen bleiben. Die einzelnen Testverfahren müssen jedoch dabei an den gegenwärtigen Stand der Techniken angepasst werden.
Der Vorprüfungstest wurde vom Aktionsbündnis für barrierefreie Informationstechnik in zwei Versionen angeboten: in einer Version zur damals gültigen BITV und in einer Version gemäß des damaligen Entwurfs der 
Web Content Accessibility Guidelines - WCAG 2.0 . Seit Verabschiedung der BITV 2.0 in Anlehnung an die WCAG 2.0 sollte nur noch ein Vorprüfungstest nach WCAG 2.0 durchgeführt werden.
Leider enthält diese Version des Vorprüfungstests keine Angaben zu Rahmenbedingungen wie zur Qualifikation der Prüfer, zu zeitlichen Angaben oder zur erforderlichen Testdokumentation.
Ebenso fehlt die Berücksichtigung der Anforderungen von Menschen mit Lernschwierigkeiten und hörbehinderten Menschen. Eine detaillierte Überprüfung dieser in Anlage 2der BITV 2.0 beschriebenen Anforderungen sollte innerhalb des dreistufigen Rahmenkonzepts in den Überprüfungen der Stufe 2 (BITV-Kurztest) und Stufe 3 (Hauptprüfung) erfolgen. Im Rahmen des Vorprüfungstests sollte aber zumindest überprüft werden ob überhaupt Angebote in Leichter Sprache oder in Gebärdensprache vorliegen.
Mit insgesamt 17 Prüfanweisungen ist der Vorprüfungstest des Aktionsbündnisses für barrierefreie Informationstechnik für eine kurze und bewusst oberflächliche Ersteinschätzung schon recht detailliert. Zum Vorprüfungstest gibt es drei Alternativen:
Prüfwerkzeuge wie zum Beispiel Wave oder als Firefox-Add-On ) oder der egovmon eAccessibility Page Check überprüfen einige Aspekte der Barrierefreiheit automatisch. Automatische Prüfwerkzeuge haben einige Mängel und werden vermutlich nie Barrierefreiheit vollständig überprüfen können. Für eine erste Einschätzung der eingehaltenen Barrierefreiheit kann eine solche automatische Überprüfung aber durchaus genügen.
Um einen ersten Eindruck über die Zugänglichkeit von Webseiten zu erhalten können auch einfache und leicht durchführbare manuelle Überprüfungen durchgeführt werden (eine kurze Anleitung zu „Easy Checks“, liegt als W3C-Editor-Entwurfsversion vor: Easy Checks - A First Review of Web Accessibility).
Mit dem frei verfügbaren Bewertungswerkzeug BaNu (Barrieren finden, Nutzbarkeit sichern) des Bundesverwaltungsamtes oder mittels einer BITV-Test-Selbstbewertung können Tests zur Überprüfung der eingehaltenen Barrierefreiheit prinzipiell von jeder IT-Abteilung selbst durchgeführt werden.
Sowohl bisheriger Vorprüfungstest, als auch die genannten automatischen Bewertungswerkzeuge, die „Easy Checks“ des W3C und die Selbstbewertung beziehen sich ausschließlich auf Webseiten, und sind nicht ohne weiteres auch auf (Desktop-) Anwendungen übertragbar. Im folgenden Abschnitt „Ergänzungen zum Vorprüfungstest“ wird eine überarbeitete Fassung des AbI-Vorprüfungstests vorgestellt.
Dieser Artikel stellt eine vom Projekt Di-Ji überarbeitete Fassung des AbI-Vorprüfungstests auf Basis der WCAG 2.0 vor.
Der vorliegende Test basiert auf den WCAG 2.0 und dem Entwurf EN 301 549 ("Accessibility requirements for public procurement of ICT products and services in Europe"). Die Prüfschritte wurden so gewählt, dass grundlegende Ansprüche an die Zugänglichkeit einer Website oder einer Anwendung gewährleistet sind. Dabei wurde darauf geachtet, dass sowohl zu den 4 Grundprinzipien Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit, als auch für unterschiedliche Arten der Behinderung Prüfschritte ausgewählt wurden.
Die in den vorgeschlagenen Prüfschritten beschriebenen Testverfahren orientieren sich an denen des bisher vorliegenden BITV-Tests sowie an den von der WAI des W3C veröffentlichten Techniques zur WCAG 2.0.
Ziel des empfohlenen Vorprüfungstests ist, einen ersten Eindruck von einem Webauftritt oder einer grafischen Programmoberflächen zu erhalten. Der hier empfohlene Vorprüfungstest ist im Zusammenhang mit dem Konzept zu sehen, das im Abschnitt: Rahmenkonzept zur Prüfung näher erläutert ist.
Mit Hilfe dieses Vorprüfungstests kann nicht festgestellt werden, ob ein Internetangebot oder eine Programmoberfläche alle Anforderungen der Barrierefreien Informationstechnik-Verordnung (BITV 2.0) erfüllt. Der Vorprüfungstest kann daher auch nicht als Grundlage für die Vergabe eines Zertifikats oder ähnliches dienen (z.B. nicht für Auszeichnungen wie "Vortest geprüft").
Mit Hilfe der im Rahmen des Vorprüfungstests erstellten Dokumentation können vom Betreiber des Web- oder Programmangebotes die exemplarisch in der Stichprobe aufgezeigten Barrieren auf das gesamte Angebot übertragen werden. Die Dokumentation der Testergebnisse ist eine erste Unterstützung für die Überarbeitung des Angebotes. Da die Testdokumentation des Vorprüfungstests keine konkreten Hinweise dazu enthält, wie jede einzelne Barriere individuell behoben werden kann, gibt es in der Dokumentation eine Liste mit Verweisen auf online verfügbare Informationsseiten, die bei der Korrektur hilfreich sind. Die Testdokumentation kann auch als Basis für einen Beratungsprozess genutzt werden.
Der hier beschriebene Vorprüfungstest reiht sich in eine Folge von 3 aufeinander aufbauenden Tests ein:
Der Vorprüfungstest dient dazu, eine erste Einschätzung des Angebots zu liefern. Der Test ist zeitlich stark begrenzt. Es wird lediglich eine kleine Stichprobe betrachtet, in der nach unterschiedlichsten Barrieren aus den Bereichen Wahrnehmbarkeit, Bedienbarkeit, technologische Robustheit und Verständlichkeit gesucht wird. Eine vollständige Überprüfung der BITV findet nicht statt.
Der BITV-Kurztest wird durchgeführt, wenn die im Vorprüfungstest aufgeführten Barrieren des Angebotes beseitigt worden sind, und die Betreiber dieses Angebotes sich intensiver mit dem Thema "Barrierefreies Informationstechnik" und der BITV beschäftigt haben. Hierbei wird nicht das gesamte Angebot, sondern lediglich eine Stichprobe betrachtet, die jedoch im Gegensatz zum Vorprüfungstest einem vollständigen BITV-Test unterzogen wird. Wird die Stichprobe (zum Beispiel überprüfte Webseiten oder Teile eines Programms) mit Hilfe des Testergebnisses überarbeitet, sollte diese Stichprobe anschließend barrierefrei sein. Auf alle anderen Seiten des Angebots, die nicht betrachtet worden sind, soll der Betreiber des Angebots die Testergebnisse selbständig übertragen. Als Empfehlung zur Durchführung von BITV-Kurztests für Webseiten gilt das Prüfverfahren zur BITV 2.0.
Die Hauptprüfung des Angebots könnte als Grundlage für eine Zertifizierung des Angebots dienen und enthält zusätzlich Hinweise auf die Selbstverpflichtung des Anbieters, sich ständig um die Einhaltung der Anforderungen, die ein barrierefreies Angebot erfüllen muss, zu halten. Eine Hauptprüfung sollte erst durchgeführt werden, wenn ein erfolgreicher Kurztest durchgeführt worden ist. Die Hauptprüfung sollte in regelmäßigen Abständen wiederholt werden.
Bei den Instrumenten, die zur Verfügung stehen müssen, handelt es sich im wesentlichen um Software, d.h. um Prüfprogramme und unterschiedliche Browser. Die Anforderungen an die Hardware sind unerheblich. Es muss nur sichergestellt sein, dass die entsprechenden Prüfprogramme installiert oder online genutzt werden können und die Internetseiten aufgerufen werden können. Die Durchführung des Vorprüfungstests ist unter verschiedenen Windows-Betriebssystemen möglich. Es muss lediglich sichergestellt sein, dass alle eingesetzten Tools unter der verwendeten Plattform verfügbar sind. Die eingesetzte Testumgebung sollte auf jeden Fall in der Testdokumentation erwähnt werden, damit die festgestellten Barrieren für den Betreiber der getesteten Website nachvollziehbar sind. Zum Test werden immer die aktuellsten beziehungsweise gebräuchlichsten Versionen der angegebenen Software benutzt. Zum gegenwärtigen Zeitpunkt sind dies:
Der Vorprüfungstest kann von einer einzelnen Person durchgeführt werden. Wenn eine einzelne Person den Test durchführt, muss diese Erfahrungen in allen genannten Bereichen besitzen, die im Folgenden aufgeführt werden. Der Tester sollte möglichst in ein Team zum Erfahrungsaustausch eingebunden sein. Die Teams bzw. die einzelnen Tester sollten in den folgenden Bereichen Erfahrungen besitzen.
Der zeitliche Umfang für den hier empfohlenen Vorprüfungstest liegt bei ca. 1 bis 2 Stunden, inklusive der Testdokumentation und der Vorbereitungen (z.B. Seitenauswahl). Wird als zusätzlicher Service zum Vorprüfungstest eine Nutzerbeurteilung durchgeführt, verlängert sich der zeitliche Umfang je nach Umfang der Nutzerbeurteilung.
Der Vorprüfungstest wird auf der Grundlage der Barrierefreien Informationstechnik-Verordnung (BITV) durchgeführt. Im Rahmen dieses Vorprüfungstests werden nicht alle Anforderungen mit den entsprechenden Bedingungen überprüft, da dies ein deutlich größerer zeitlicher Aufwand wäre, als für diesen Test vorgesehen ist. Die im Folgenden betrachteten Punkte reichen aus, um einige häufige und typische Barrieren aufzuzeigen. Alle Anforderungen lassen sich den 4 Grundprinzipien der Web Content Accessibility Guidelines (WCAG) 2.0 zuordnen:
Alle diese Bereiche müssen berücksichtigt werden. Für den Vorprüfungstest sind aus jedem Bereich mindestens 2 Prüfkriterien ausgewählt worden, die den entsprechenden BITV-Anforderungen (möglichst der Priorität I) zugeordnet werden können.
Die folgende Aufzählung zeigt die ausgewählten Prüfkriterien. Diese spiegeln jeweils nur einen Teilaspekt der BITV-Anforderungen bzw. Bedingungen wieder:
Da der Vorprüfungstest zeitlich begrenzt ist und nur eine erste Einschätzung des Angebots liefern soll, wird ein sehr begrenzter Prüfumfang gewählt.
Für den Vorprüfungstest von Internetangeboten werden 3 Seiten ausgewählt, die zur Überprüfung aller Kriterien betrachtet werden:
Weitere Seiten als die zu Beginn des Tests ausgewählten können zur Beurteilung einzelner Prüfkriterien zusätzlich betrachtet werden. Es muss entweder der Navigationspfad, wie eine Seite erreicht werden kann oder die Adresse der Seite im Testbericht aufgeführt werden.
Für den Vorprüfungstest von Programmangeboten werden 3 Funktionen ausgewählt, die zur Überprüfung aller Kriterien betrachtet werden:
Nachfolgend sind für ausgewählte BITV-Bedingungen Beschreibungen und Prüfanweisungen für Internetseiten und Programmoberflächen aufgeführt.
Für jeden Nicht-Text-Inhalt, der dem Nutzer oder der Nutzerin präsentiert wird, ist eine Text-Alternative bereitzustellen, die den Zweck dieses Inhalts erfüllt.
Text-Alternativen müssen in den folgenden Fällen nicht bereitgestellt werden (vgl. Richtlinien für barrierefreie Webinhalte, Richtlinie 1.1):
Informative Abbildungen sollen einen Alternativtext besitzen, der die visuell gegebene Information in einer Textvariante wiedergibt, das heißt bei Schriftgrafiken sollte der Alternativtext den dargestellten Text enthalten, bei einem Foto eine kurze Beschreibung des abgebildeten Inhalts.
Alternativtexte für Bedienelemente, wie beispielsweise eine Grafik zum Abschicken eines Formulars, sollen die Aktion (zum Beispiel Abschicken eines Formulars) oder das Ziel (bei verknüpften Grafiken) enthalten.
Layoutgrafiken, die ausschließlich gestalterischen dekorativen Zwecken dienen, sollen einen leeren Alternativtext enthalten.
Eine Alternative für zeitbasierte Medien oder eine Audiodeskription des aufgezeichneten Videoinhalts wird für synchronisierte Medien bereitgestellt, außer die Medien sind eine Medienalternative für Text und als solche deutlich gekennzeichnet.
Sollte Multimedia einen zentralen Teil der Site bilden, ist zu überprüfen, ob es eine Alternative für sehbehinderte, blinde und gehörlose Nutzer zu diesen Inhalten gibt.
Die Alternative kann über die Software selbst oder über eine BITV-konforme alternative Version bereitgestellt werden
Bei der visuellen Präsentation von Text und Schriftgrafiken ist das Kontrastverhältnis zwischen Vordergrund- und Hintergrundfarbe mindestens 4,5:1. Für Großschrift und Schriftgrafiken mit Großschrift gilt ein Kontrastverhältnis von mindestens 3:1. Kein Mindestkontrast ist erforderlich für nebensächliche Texte und Schriftgrafiken,
Der Text lässt sich ohne assistive Technologie bis auf 200 % vergrößern, ohne dass es zu einem Verlust von Inhalt oder Funktionalität kommt.
Um diesen Prüfschritt zu erfüllen, müssen alle Textinhalte nach der Vergrößerung lesbar sein und dürfen sich nicht überschneiden. Bei Schrift, die sich nicht vergrößern lässt, ist dieser Prüfpunkt nicht erfüllt.
Softwareplayer, Viewer oder Editoren mit einer internen 200%-Vergrößerung für Schrift erfüllen das Prüfkriterium automatisch, es sei denn Inhalte funktionieren mit dieser Vergrößerung nicht.
Falls die Programmoberfläche selbst keine Möglichkeit zur Schriftvergrößerung bietet, sollte die Software mit den Vergrößerungsmöglichkeiten des zugrundeliegenden Betriebssystems funktionieren.
Die gesamte Funktionalität des Inhalts muss über eine Tastaturschnittstelle bedient werden können, ohne dass bestimmte Zeitvorgaben für die einzelnen Tastenanschläge einzuhalten sind. Dies gilt nicht, wenn die zugrundeliegende Funktion Eingaben verlangt, die nicht nur von den Endpunkten, sondern auch vom Verlauf der Benutzerbewegung abhängen.
In den WCAG 2.0 sind die Ausnahmen näher erläutert (vgl. Richtlinien für barrierefreie Webinhalte, Richtlinie 2.1):
Anmerkung 1: Diese Ausnahme bezieht sich auf die zugrundeliegende Funktion und nicht auf die Eingabetechnik. Zum Beispiel: Wenn man Handschrift benutzt, um Text einzugeben, dann verlangt die Eingabetechnik (Handschrift) Pfad-abhängige Eingaben, die zugrunde liegende Funktion (Texteingabe) verlangt dies aber nicht.
Anmerkung 2: Es ist nicht verboten, noch sollte es Sie davon abhalten, eine Maus-Eingabe oder andere Eingabemethoden zusätzlich zur Tastaturbedienung zur Verfügung zu stellen.
Dieses Prüfkriterium bedeutet nicht, dass Anwendungen direkt eine Tastatur oder ein „Keyboard Interface“ unterstützen müssen. Es bedeutet auch nicht, dass Anwendungen eine Bildschirmtastatur bereit stellen müssen. Das der Anwendung zugrunde liegende Betriebssystem kann eingabegerätunabhängige Eingabedienste für Anwendungen bereit stellen, die eine Bedienung über eine Tastatur ermöglichen. Software, welche die Bedienung von solchen vom Betriebssystem bereit gestellten Eingabediensten unterstützt, wäre im Sinne des Prüfkriterium durch eine Tastatur bedienbar und würde diesen Prüfschritt erfüllen.
Für Gruppen von Elementen, die auf mehreren Webseiten wiederholt werden, sind Mechanismen verfügbar, um diese zu umgehen.
Elementgruppen können auch durch Verwenden von Frames oder Iframes erstellt werden. In diesem Fall sollten die so erstellten Gruppen entsprechend bezeichnet sein: mit einem title-Attribut für frame- beziehungsweise iframes-Elemente.
Dieses Prüfkriterium ist nach dem Entwurf EN 301 549 nicht auf Software anwendbar.
Ziel und Zweck eines Links sind aus dem Linktext selbst ersichtlich oder aus dem Linktext in Verbindung mit dem durch Programme bestimmten Link-Kontext.
Hinweis (vgl. Understanding WCAG 2.0, Understanding Success Criterion 2.4.4): Der Zweck eines Links geht in der Regel aus dem Linktext hervor. Ergänzende Information kann auch in einem zugeordneten Tooltip angegeben sein (bei HTML im title-Attribut). Bei verlinkten Grafiken ist der Linktext der alt-Text eines img-Elements. Der Zweck eines Links kann auch aus dem umgebenden Absatz, der übergeordneten Überschrift oder der zugeordneten Tabellenzelle mit entsprechenden Tabellenüberschriften hervorgehen, in welcher sich der Link befindet. Bei Webseiten kann der Zweck eines Links auch durch zusätzlichen, überCSS versteckten Linktext angegeben sein.
Nach dem Entwurf EN 301 549 gilt:
Bei Software ist ein “link” jegliche Textfolge oder Bild in der Benutzeroberfläche außerhalb eines Kontrollelementes der Benutzeroberfläche, welche sich wie ein Link verhält. Dies schließt allgemeine Kontrollelemente nicht ein (Eine OK-Schaltfläche ist beispielsweise kein Link).
Bei Tastaturbedienung ist immer ein Tastaturfokus sichtbar.
Die vorherrschend verwendete natürliche Sprache jeder Webseite ist durch Programme erkennbar.
Hinweis: In der BITV werden für dieses Prüfkriterium lediglich Webseiten genannt. Die Entsprechung für Anwendungen lautet nach dem Entwurf EN 301 549:
„Die voreingestellte menschliche Sprache jeder Software-Bedienoberfläche kann durch Software bestimmt werden.“
Screenreader sollen dadurch zum Beispiel in der Lage sein ein korrektes Aussprachelexikon zu laden und Webseiten oder Programmoberflächen korrekt vorlesen zu können.
Die natürliche Sprache aller verwendeten Textpassagen oder Ausdrücke ist durch Programme erkennbar.
Dieses Prüfkriterium ist nach dem Entwurf EN 301 549 nicht auf Software anwendbar.
Wird die Einstellung eines Elements der Benutzerschnittstelle geändert, führt dies nicht automatisch zu einer Änderung des Kontextes, es sei denn, die Nutzerin oder der Nutzer wurde vor Benutzung des Elements über dieses Verhalten informiert.
Hinweis: Hier müssen Kontextänderungen von Inhaltsänderungen unterschieden und abgegrenzt werden (siehe: Understanding WCAG 2.0, Understanding Success Criterion 3.2.2):
Unter Kontextänderungen werden wesentliche Änderungen am Inhalt einer Webseite verstanden. Wenn solche Änderungen vorgenommen werden, ohne dass dies dem Benutzer bewusst ist, kann dies zur Desorientierung derjenigen Benutzer führen, die nicht die gesamte Seite zeitgleich sehen können.
(Dies sind z.B. Änderungen des Benutzeragenten, des Viewports, des Fokus oder sonstige Änderungen des Inhalts, der zu einer Bedeutungsänderung der Webseite führt.)
Anmerkung: Eine Änderung des Inhalts ist nicht immer eine Änderung des Kontextes. Änderungen am Inhalt, wie zum Beispiel eine expandierende Gliederung, ein dynamisches Menü oder eine Steuerung über Reiter, ändern nicht zwangsläufig den Kontext, außer sie ändern auch eines der oben genannten (z.B. den Fokus).
Navigationsmechanismen, die innerhalb eines Webangebots wiederholt werden, treten bei jeder Wiederholung in der gleichen Reihenfolge auf, es sei denn, die Nutzerin oder der Nutzer veranlasst eine Änderung.
Dieses Prüfkriterium ist nach dem Entwurf EN 301 549 nicht auf Software anwendbar.
Für notwendige Eingaben der Nutzerinnen und Nutzer sind Hinweise oder Label (Beschriftungen) zur Verfügung zu stellen.
Eine Beschriftung soll in Formularfeldern direkt über oder vor dem Feld stehen, bei Checkboxen und Radiobuttons soll eine Beschriftung nach dem Formularelement stehen. In HTML-Dokumenten sollten die Formularelemente über label oder legend verknüpft sein. Ist dies nicht der Fall, sollte zumindest eine Beschriftung und eine ausführliche Textanweisung zum Ausfüllen einzelner Formularelemente vorhanden sein.
Bei Webseiten, die rechtliche Verpflichtungen begründen oder zu finanziellen Transaktionen der Nutzerinnen und Nutzer führen oder von Nutzerinnen und Nutzern kontrollierbare Daten in Datenspeichersystemen ändern bzw. löschen oder Testantworten der Nutzerinnen und Nutzer absenden, haben Nutzerinnen und Nutzer mindestens eine der folgenden Möglichkeiten:
Dieses Prüfkriterium ist anwendbar, wenn Nutzer durch das Ausfüllen von Formularen oder durch Tätigen sonstiger Aktionen rechtlich bindende Verpflichtungen eingehen (zum Beispiel Online-Bestellvorgänge und andere finanzielle Transaktionen)
Inhalte, die mit Markup-Sprachen erstellt werden, bestehen aus Elementen, für die folgende Eigenschaften gelten:
Nach dem Entwurf EN 301 549 gilt:
Anforderungen zur Syntaxanalyse sind nur anwendbar für Inhalte, die getrennt dargestellt und für assistive Technologien verfügbar gemacht werden. Wenn Markup-Sprachen verwendet werden, um Rahmenbedingungen für Benutzerschnittstellen intern zu beschreiben, und diese dabei assistiven Technologien nicht zur Verfügung stehen, weder direkt noch über ein Dokument-Objekt-Modell (DOM), ist diese Bedingung automatisch erfüllt.
BITV-Text: Auf der Startseite des Internet- oder Intranetangebotes einer Behörde im Sinne des § 7 Absatz 1 Satz 1 des Behindertengleichstellungsgesetzes sind gemäß Anlage 2 folgende Erläuterungen in Deutscher Gebärdensprache und in Leichter Sprache bereitzustellen:
Prüfanweisung zur Anlage 2 (bei Inter- oder Intranetseiten)
Die Testdokumentation sollte die Testumgebung, die Methoden, mit denen getestet wird (z.B. eingesetzte Testtools, Nutzerbeteiligung usw.), ausgewählten Seiten und alle Testergebnisse beinhalten und sich am Entwurf zu Evaluationsberichten zur Barrierefreiheit orientieren (W3C: Template for Accessibility Evaluation Reports). Die formalen Daten, die in der Dokumentation enthalten sein sollten, sind im Einzelnen:
Aus dem Bericht muss hervorgehen, auf welche Seite und auf welches Element sich die beschriebenen Barrieren beziehen.
Die Ergebnisse der einzelnen Überprüfungen unterschiedlicher Seiten sollten im Testbericht zusätzlich zum ausführlichen Ergebnis kurz zusammengefasst werden, indem z.B. darauf hingewiesen wird, dass das Angebot kleinere Barrieren enthält oder vollständig unzugänglich ist. Es sollte erwähnt werden in welchen Bereichen (z.B. Wahrnehmung oder Bedienbarkeit) die meisten Probleme aufgetreten sind. Außerdem ist anzugeben wie die Auswirkungen dieser Barrieren für bestimmte Nutzergruppen sind, z.B. Navigation von blinden Menschen nicht bedienbar.
Alle Aspekte, die die Barrierefreiheit der Seite unterstützen, sollten positiv erwähnt werden, unabhängig davon, ob sie bewusst zur Erreichung von Barrierefreiheit eingesetzt werden oder nicht.
Fallen bei der Prüfung weitere Mängel auf, die nicht im Prüfumfang dieser Vorprüfungstestempfehlung enthalten sind, können diese in einem Anmerkungsfeld dokumentiert werden. Dies sollte aber nicht zu einer erheblichen Vergrößerung des Testaufwandes führen. Bei einer solchen Ausweitung des Aufwandes sollte der Auftraggeber stattdessen generell auf das Vorhandensein hingewiesen werden.