Das Prüfverfahren zur BITV


Sie sind hier: BIK BITV-Test > Prüfergebnisse > Blubbsoft Lernplattform QuestorPro 4.1.16


Blättern: zum nächsten Test zum letzten Test

Blubbsoft Lernplattform QuestorPro 4.1.16

Prüfung

Anmerkungen zum Prüfauftrag

Bei dem Befragungsportal handelt es sich um einen ein Demo-Portal, dass alle Komponenten beinhaltet, die mit der Befragungssoftware möglich sind.

Ergebnis

0 von 4 Seiten BITV-konform

Geprüfte Seiten

Seite 1 (Loginseite)

Screenshot: Loginseite - öffnet vergrößerte Ansicht

Seite 2 (Beispielumfrage Schritt 1 )

Screenshot: Beispielumfrage Schritt 1  - öffnet vergrößerte Ansicht

Seite 3 (Beispielumfrage Schritt 2)

Screenshot: Beispielumfrage Schritt 2 - öffnet vergrößerte Ansicht

Seite 4 (Bestätigungsseite)

Screenshot: Bestätigungsseite - öffnet vergrößerte Ansicht

Bewertung und Anmerkungen zu einzelnen Prüfschritten

92 Prüfschritte prüfen 82 Anforderungen der BITV / EN 301 549.

Nicht erfüllt sind 14 von 92 Prüfschritten:

  • Prüfschritt 9.1.3.1a - HTML-Strukturelemente für Überschriften

    Seite 2: nicht BITV-konform
    • Die Dopplung "Beispielumfrage" jeweils in der ersten H1 und H2 macht keinen Sinn und sollte vermieden werden.
    • Die H4-Überschriften "Fragen zur Zufriedenheit" und "Fragen zu Musterstadt" sowie "Seit wann wohnen Sie bereits hier" und "Gute Gründe für Musterviertel" sollten aus meiner Sicht im Umfrageformular eher als Legend-Elemente in Kombination mit Fieldsets umgesetzt werden. Dann entfällt auch das Problem, dass vor den H4-Überschriften eine H3-Überschrift fehlt (Überschriften-Outline).
    • Über den Button "Daten löschen" öffnet sich ein Popup mit einer sichtbaren Überschrift [span class="popup-title delete-popup-title"]Daten löschen[/span]. Auch hier wird kein Überschriften-Element verwendet. Eine einfache Lösung wäre role="heading" aria-level="2".
    Seite 3: nicht BITV-konform
    • Die Dopplung "Beispielumfrage" jeweils in der ersten H1 und H2 macht keinen Sinn und sollte vermieden werden.
    • Die H4-Überschriften "Fragen zum Mietspiegel" sowie "Spielplatzneubau am Beispielweg" und "Persönliche Fragen" sollten aus meiner Sicht im Umfrageformular eher als Legend-Elemente in Kombination mit Fieldsets umgesetzt werden. Dann entfällt auch das Problem, dass vor den H4-Überschriften eine H3-Überschrift fehlt (Überschriften-Outline).
    • Über den Button "Daten löschen" öffnet sich ein Popup mit einer sichtbaren Überschrift [span class="popup-title delete-popup-title"]Daten löschen[/span]. Auch hier wird kein Überschriften-Element verwendet. Eine einfache Lösung wäre role="heading" aria-level="2".
    Seite 1, 4: BITV-konform
  • Prüfschritt 9.1.3.1b - HTML-Strukturelemente für Listen

    • Die kleine Footer-Navigation bestehend aus den Links Impressum | Datenschutz | Über QuestorPro könnte in einer UL-LI-Liste organisiert sein.
    • Für die Fehlermeldungen wird ein Listen-Element verwendet. [ul class="feedbackPanel"]. Zum Beispiel auf der Bestätigungsseite beim Text "Der Fragebogen wurde bereits abgeschickt." Verwenden Sie Listen-HTML für echte Auflistungen. Auf der Login-Seite betrifft das die Meldung "Das Kennwort ist ungültig." Auf den beiden Formularseiten betrifft das die ganzen Fehlermeldungen, wie beispielsweise "Die Antwort darf nicht leer sein." Es konnte keine Fehlermeldung gefunden werden, die eine Listenstruktur rechtfertigen würde.
    Seite 1: nicht BITV-konform

    Siehe allgemeine Anmerkungen.

    Seite 2: nicht BITV-konform

    Siehe allgemeine Anmerkungen.

    Seite 3: nicht BITV-konform

    Siehe allgemeine Anmerkungen.

    Seite 4: nicht BITV-konform

    Siehe allgemeine Anmerkungen.

  • Prüfschritt 9.1.3.1d - Inhalt gegliedert

    Seite 4: BITV-konform

    Auch hier: Verwenden Sie für Absätze wie "Ihr Fragebogen ist eingegangen. Sie können dieses Fenster jetzt schließen." das dafür vorgesehene Absatz-HTML-Element.

    Seite 2: nicht BITV-konform
    • Die ganzen Erklärungen (class="explanation") stehen derzeit nur in einem DIV-Element. Absätze müssen mit dem dafür vorgesehenen HTML-Strukturelementen ausgezeichnet werden. DIV und SPAN Elemente haben keine semantische Bedeutung und sollte nur zur Positionierung bzw. Gestaltung eingesetzt werden. Siehe: https://www.w3.org/TR/2011/WD-html5-author-20110809/the-div-element.html. Das betrifft aber auch alle Beschriftungen und Labels bei und an Formularelementen im Umfrageformular (class="scale-label-content polar-label-left" und class="scaled-block-padding-normal scaled-question-text"). Verwenden Sie mindestens Absatzel-Elemente oder andere angemessene HTML-Elemente, wie Labels und Fieldsets. Siehe https://webaim.org/techniques/forms/controls und https://webaim.org/techniques/forms/advanced.
    • Ein kleineres Problem ist, dass im Satz am Beginn des Formulars das Satzzeichen [!] als Marker für "Zwangsfrage" verwendet wird. Satzzeichen werden von Screenreadern zumeist nicht mit vorgelesen (Einstellungssache). Das gängigere Sternchen hingegen würde ausgegeben.
    Seite 3: nicht BITV-konform

    Siehe ausführliche Beschreibung unter "Seite 2 - Beispielumfrage Schritt 1". Das betrifft auch die Beschriftungen [div class="question-title-text"].

    Seite 1: BITV-konform
  • Prüfschritt 9.1.3.1h - Beschriftung von Formularelementen programmatisch ermittelbar

    Erklärung: Formularelemente und ihre Beschriftungen (Lables, etc.) sollen über Markup miteinander verknüpft sein. Bei Label-Elementen geschieht das über das for-Attribut oder den Einschluss des beschrifteten Formularelements in das label-Element. Sind Beschriftungen nicht mit dem label-Element ausgezeichnet, soll eine Beschriftung des zugehörigen Formularelements auf anderem Weg (etwa über das aria-labelledby-Attribut) sichergestellt sein.

    Seite 2: nicht BITV-konform
    • Die Beschriftung im Formular funktioniert mit Screenreader leider nicht. Das scheint zum einen an der Verwendung der CSS Eigenschaften display: table; und display: table-cell; zu liegen. Ein alter Screenreader-Bug führt dazu, dass die genannten CSS Eigenschaften tatsächlich als eine Art Tabellen-Semantik interpretiert werden. NVDA liest zum Beispiel auf dem ersten Formular-Element in diesem Konstrukt immer alle Pseudo-Tabellen-Header und Pseudo-Tabellen-Zellen hintereinander weg vor – sobald man aber jedes einzelne Formular-Element ansteuert, fehlt oft eine sinnvolle Beschriftung.
    • Darüber hinaus werden praktisch alle Input-Elemente durch aria-labelledby beschriftet, und zwar oft nur mit Bezugspunkt auf die übergeordnete Leitfrage und nicht mit Bezug auf auf das direkt zugeordnete Label. Dadurch sind z. B. Radio-Buttons mit der Beschriftung "sehr zufrieden" etc. mit der horizontal vorangestellten Frage "Angebot an Arbeitsplätzen" etc. beschriftet. Zum Nachvollziehen: alle Radio-Buttons bei der Frage "Angebot an Arbeitsplätzen" beziehen sich auf die selbe ID id27 – obwohl sie optisch unterschiedlich gelabelt sind.
    • An sich ist die Technik mit aria-labelledby mit mehreren Bezugspunkten, also mehreren referenzierten IDs, machbar. Allerdings funktioniert das im Formular an vielen Stellen nicht. Bei der Frage "Fragen zu Musterstadt. Seit wann wohnen Sie bereits hier? In Musterstadt – bitte geben Sie nur Monat und Jahr an." wird beispielsweise nur der letzte Part "In Musterstadt – bitte geben Sie nur Monat und Jahr an." vorgelesen, sodass die Frage unverständlich bleibt. Das ist an vielen Stellen so.
    • Die Frage "Was war für Sie der Grund nach Musterviertel zu ziehen? Sie können mehrere Antworten auswählen, jedoch mindestens zwei." ist z.B. überhaupt nicht mit den nachfolgenden Checkboxen verknüpft, was sinnvollerweise mit einem Fieldset-Legend-Kontstrukt umgesetzt werden könnte. Siehe https://www.w3.org/WAI/tutorials/forms/grouping/. Am besten Sie orientieren sich an dieser Vorgehensweise. Wobei Sie die dazugehörige, letzte Frage "Weiterer/anderer Grund" mit dem Input type="text" über aria-labelledby="id82 id8a" ja korrekt mit der Eingangsfrage und dem vorangestellten Label verknüpft haben. Technisch geht es also mit aria-labelledby. Es wurde nur nicht konsequent durchgezogen. Abgesehen davon: Die immer wiederholte aria-labelledby-Verknüpfung von Frage-Topic *und* Bewertungsoption *kann* man so machen, aber ich würde hier, um den Screenreader-Nutzenden Redundanzen zu ersparen, klar eine Gruppierungs-Semantik empfehlen. Vielleicht muss man auch noch etwas stärker differenzieren, was die Beschriftung der Radio Groups und der anderen Inputs wie Datum usw. angeht? Hier gibt es ja z.T. versteckte Labels.
      Und dann Fälle wie "Weiß ich nicht" (mit nativem Label, eingeschlossen), dass müsste sich wohl programmatisch auch auf die Frage "Seit wann wohnen Sie bereits hier?" beziehen, also eher mit fieldset/legend oder eben zweiwertigem aria-labelledby umgesetzt sein.
    • Der Hinweis auf Pflichtfelder [abbr class="question-attribute-icon mandatory" title="Zwangsfrage"]![/abbr] funktioniert nicht zuverlässig. Im NVDA mit Chrome wird der Hinweis "Zwangsfrage" nicht ausgegeben, in Kombination mit Mozilla Firefox funktioniert es, allerdings nicht, wenn man das Formular im Lesemodus durchwandert. Hier würde z. B. ein Sternchen erfasst. Ggf. könnte man hier mit visuell verstecktem Text statt [abbr] und title arbeiten, damit das auch im Lesemodus funktioniert (Vergl. Hinweise zu 9.1.3.1d).
    • Nochmal zur Verdeutlichung: Die Input type radio sind nicht mit den Bewertungsoptionen verknüpft, sondern nur mit dem übergeordneten Topic. Sie könnten entweder mit beiden verknüpft sein (zwei Werte im aria-labelledby-Attribut wie aria-labelledby="id27 id21" für "Angebot an Arbeitsplätzen / sehr zufrieden", oder eine richtig umgesetzte Gruppenbeschriftung über fieldset /legend (oder auch role=group mit aria-labelledby-Verweis auf den Topic) nutzen und dann die Inputs nur mit der Bewertungsoption verknüpfen (besser). Auch die Gruppen von Elementen, wie unterhalb von "Gründe für Musterviertel" sind nicht programmatisch gesetzt bzw. beschriftet, werden also bei Fokussierung nicht mit ausgegeben. Das sind hier die Hauptprobleme!
    Seite 3: nicht BITV-konform
    • Siehe ausführliche Problem-Beschreibung unter "Seite 2 - Beispielumfrage Schritt 1".
    • Wichtig: die alleinige Auszeichnung der Randwerte bei Von-Bis-Fragen ist sowohl für sehende Nutzende (beispielsweise in einer linearen Darstellung und starker Vergrößerung) als auch für Screenreader-Nutzende ein Problem. Zum Beispiel bei der Frage: "Wenn Sie an den aktuellen Zustand des Spielplatz denken, wie würden Sie diesen bewerten? ". Hier wird ja bei Fokussierung der Radio Inputs, welche die Zwischen-Punkte auf der Skala von "sauber" bis "schmutzig" abbilden sollen, immer nur "sauber schmutzig" ausgegeben. Das müsste ganz anders umgesetzt sein, um nicht-visuell verständlich zu sein? Beschriften Sie am besten jedes Input-Element einzelnen und sorgen Sie für verknüpfte Gruppenbeschriftungen.
    Seite 1: BITV-konform
    Seite 4: nicht anwendbar
  • Prüfschritt 9.1.3.2 - Sinnvolle Reihenfolge

    Beim lineraren Durchwandern im Screenreader-Lesemodus wird erst die Frage "Bitte geben Sie an, wie zufrieden oder unzufrieden Sie mit jedem einzelnen der folgenden Aspekte in Musterstadt sind" ausgegeben, dann die Beschriftungen der Radio Inputs, und erst dann die eigentliche Gruppenbeschriftung für die Radio Group, "Angebot an Arbeitsplätzen". Die gleiche nicht sinnvolle Reihenfolge zieht sich durch das ganze Formular hindurch. Das gleiche Reihenfolgeproblem besteht in der responsiven Ansicht. Die Zuordnung der Topics mit den entsprechenden Radio Input Groups ist so nicht gut möglich, falsche Zuordnungen sehr leicht möglich.

    Seite 2: nicht BITV-konform

    Siehe allgemeine Anmerkungen.

    Seite 3: nicht BITV-konform

    Siehe allgemeine Anmerkungen.

    Seite 1, 4: BITV-konform
  • Prüfschritt 9.1.3.5 - Eingabefelder zu Nutzerdaten vermitteln den Zweck

    Erläuterung: Eingabefelder, die sich auf den Nutzer selbst beziehen, sollten eine semantisch eindeutige, sprachunabhängige Bestimmung ihres Zweckes ermöglichen. Geeignet dafür ist zurzeit das HTML autocomplete-Attribut, mit dem sich der Eingabezweck für Felder wie etwa Name, E-Mail oder Telefonnummer ebenso wie für Adress-Daten oder Kreditkarten-Daten definieren lässt. Eine Liste der möglichen Attribute finden Sie auf der folgenden Seite: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete

    • Beim Ausfüllen des Formulars ist zwischenzeitlich mal ein Fehler aufgetreten, der folgende Fehlermeldung auswarf "Hinweis Beim Auftreten von Fehlern wird automatisch unser technischer Support informiert. Wir bemühen uns, den Fehler rasch zu beheben. Bitte versuchen Sie in Kürze noch einmal, auf das Befragungsportal zuzugreifen."
    • Die URL lautet: https://besser.bei.blubbsoft.de/qp/error/6JMWPL5RK7GLA;jsessionid=D0AD9C24F82AF04EDC60A4606E386631
    • Optional kann man dort dem Support auch eine E-Mail schreiben. Unter der Überschrift "Bitte beschreiben Sie detailliert, was Sie getan haben. Auf diese Weise kann das Problem am besten nachvollzogen und behoben werden." findet sich ein E-Mail-Input-Feld – allerdings ohne autocomplete-Attribut.
    Seite 2: nicht BITV-konform

    Siehe allgemeine Anmerkungen. Betrifft nur die Seite "Ein Fehler ist aufgetreten".

    Seite 3: nicht BITV-konform

    Siehe allgemeine Anmerkungen. Betrifft nur die Seite "Ein Fehler ist aufgetreten".

    Seite 1, 4: nicht anwendbar
  • Prüfschritt 9.1.4.3 - Kontraste von Texten ausreichend

    • Insgesamt sind die Text-Kontraste weitgehend ausreichend. Allerdings müssen Sie die geforderten Kontraste auch für verschiedene Zustände berücksichtigen. Bei allen Button-Elementen am Ende der Umfrage-Formulare erscheint bei Tastaturfokus (:focus) und Mouseover (:hover) ein Orangeton, der in Kombination mit weißer Schriftfarbe lediglich ein Kontrastverhältnis von 2,4:1 aufweist.
    • Erläuterung: Normaler Text muss einen Farbkontrast von 4,5:1 zum Hintergrund aufweisen, damit er auch von Menschen mit verschiedenen Sehschwächen gut wahrgenommen werden kann. Für große Texte (14 pt fett/18,7 px oder 18 pt/24 px und größer) gilt ein Mindestkontrast von 3:1.
    Seite 1: BITV-konform

    Siehe allgemeine Anmerkungen.

    Seite 2: nicht BITV-konform

    Siehe allgemeine Anmerkungen.

    Seite 3: nicht BITV-konform

    Siehe allgemeine Anmerkungen.

    Seite 4: BITV-konform
  • Prüfschritt 9.1.4.11 - Kontraste von Grafiken und grafischen Bedienelementen ausreichend

    Erläuterung: Die für die Identifizierung notwendige visuelle Information von zum Verständnis und zur Bedienung wichtigen Grafiken sowie deren Zustände sollen einen Kontrast von mindestens 3:1 zur angrenzenden Farbe haben.

    Seite 2: BITV-konform

    Das Formularfeld Input type="text" hat nur eine hellgraue Outline, die zum weißen Hintergrund ein Kontrastverhältnis von 1,4:1 hat. Minimum wäre hier 3:1.

    Seite 3: nicht BITV-konform

    Die Formularfelder mit Input type="text" haben auch hier nur eine hellgraue Outline, die zum weißen Hintergrund ein Kontrastverhältnis von 1,4:1 hat. Minimum wäre hier 3:1.

    Seite 1, 4: BITV-konform
  • Prüfschritt 9.2.4.2 - Sinnvolle Dokumenttitel

    Alle Seiten, von der Login-Seite, über das Umfrageformular, bis hin zur Bestätigungsseite haben den gleichen Dokumententitel "Befragungsportal". Wenn wir mal davon ausgehen, dass die H1 "Beispielumfrage" später der Titel bzw. Name des Umfrageformulars ist, also beispielsweise "Musterstadt Umfrage zur Energiewende 2030", dann sollte der Name des Umfrageformulars Teil des Dokumententitels sein. Also beispielsweise "Musterstadt Umfrage zur Energiewende 2030 – Login" oder "Musterstadt Umfrage zur Energiewende 2030 – Schritt 1 von 2" oder "Musterstadt Umfrage zur Energiewende 2030 – Danke für Ihre Teilnahme".

    Seite 1: nicht BITV-konform

    Siehe allgemeine Anmerkungen.

    Seite 2: nicht BITV-konform

    Siehe allgemeine Anmerkungen.

    Seite 3: nicht BITV-konform

    Siehe allgemeine Anmerkungen.

    Seite 4: nicht BITV-konform

    Siehe allgemeine Anmerkungen.

  • Prüfschritt 9.2.4.3 - Schlüssige Reihenfolge bei der Tastaturbedienung

    Seite 2: nicht BITV-konform
    • Der Button "Daten löschen" wird dynamisch eingeblendet, zum Beispiel wenn man im Umfrageformular Schritt 1 am Ende die Checkbox Miete wählt (scheint aber auch zu erscheinen, sobald irgend ein Input überhaupt aktiviert ist.). Optisch erscheint der Button vor dem Fortschrittsbalken und vor den optisch nachfolgenden Buttons. In der Tastaturreihenfolge erscheint er aber als letztes. Das ist irritierend (zunächst hatte ich vermutet, dass das Element gar nicht mit Tastatur bedienbar ist.) Auch im Umfrageformular Schritt 2 ist das so.
    • Die Button "Daten löschen" und "Später weitermachen" öffnen ein Popup. Vom Design-Pattern her handelte sich dabei um einen Dialog-Element. Achten Sie auch also auf das Fokus-Management. Siehe ausführliche Keyboard Support Beschreibung unter https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html und Best Practice: https://adrianroselli.com/2020/10/dialog-focus-in-screen-readers.html . Das zu erwartende Verhalten wäre, dass der Tastaturfokus in dem Modalfenster „eingesperrt“ wird so lange, bis das Fenster entweder geschlossen wird, oder das Formular abgesendet wurde. Danach muss der Tastaturfokus wieder auf das Element zurückversetzt werden, das den Dialog geöffnet hat. Aktuell erhält der Dialog nicht direkt nach dem Öffnen den Tastaturfokus, sondern er wandert weiter in den Fußbereich. Man muss nochmal das ganze Formular durchlaufen, dann irgendwann wandert der Fokus in den Dialog. Der Fokus sollte sofort versetzt und im Dialog gehalten werden, bis er explizit geschlossen wird.
    Seite 3: nicht BITV-konform

    Siehe Beschreibung unter "Seite 2 - Beispielumfrage Schritt 1"

    Seite 1, 4: BITV-konform
  • Prüfschritt 9.3.3.1 - Fehlererkennung

    Wenn das in Formularen Nutzereingaben überprüft werden, sollen die Felder mit fehlerhaften oder fehlenden Eingaben von Menschen mit verschiedenen Behinderungsarten identifiziert werden können. Dies hilf Nutzer*innen dabei Eingaben zu korrigieren. Der Prüfschritt ist immer dann anwendbar, wenn eine Seite Formulare enthält, welche bei inkorrektem Ausfüllen Fehlermeldungen erzeugen. Wenn Fehlermeldungen nahe am fehlerhaft ausgefüllten Formularfeld positioniert sind (aber nicht Teil des Labels sind) müssen die Fehlermeldungen programmatisch ermittelbar sein, etwa durch die Verknüpfung mittels aria-labelledby oder aria-describedby.

    Die Identifizierung der betroffenen Felder kann aber abhängig von der Länge des Formulars auch auf andere Weise geschehen. Folgende weitere Möglichkeiten stehen Ihnen zur Verfügung:

    • Bei Neuanzeige des Formulars werden am Seitenbeginn fehlerhaft ausgefüllte Felder identifiziert.
    • Fehlerhaft ausgefüllte Felder werden zusätzlich deutlich hervorgehoben.
    • Die Labeltexte fehlerhaft ausgefüllter Felder ändern sich, um auf die Fehler darstellungsunabhängig hinzuweisen.
    • Fehlermeldungen werden mit Hilfe von Live-Regionen oder Benachrichtigungen (alertdialog) bereitgestellt.
    Seite 2: nicht BITV-konform

    Sie allgemeine Anmerkungen. Betrifft alle Rückmeldungen.

    • Im Formular wäre sicherlich eine Neuanzeige des Formulars mit einer Auflistung aller fehlerhaft ausgefüllten Felder optimal – inklusive Sprunglinks zu den jeweiligen Formularfeldern.
    Seite 3: nicht BITV-konform

    Sie allgemeine Anmerkungen. Betrifft alle Rückmeldungen.

    • Im Formular wäre sicherlich eine Neuanzeige des Formulars mit einer Auflistung aller fehlerhaft ausgefüllten Felder optimal – inklusive Sprunglinks zu den jeweiligen Formularfeldern.
    Seite 1: BITV-konform

    Siehe allgemeine Anmerkungen. Betrifft die Rückmeldung "Das Kennwort darf nicht leer sein".

    Seite 4: nicht anwendbar
  • Prüfschritt 9.3.3.2 - Beschriftungen von Formularelementen vorhanden

    Seite 2: nicht BITV-konform

    Hier gibt die Pseudo-Skala "sehr zufrieden / sehr unzufrieden" (Versorgung mit Ärzten und Krankenhäusern). Das Hauptproblem ist dabei die nicht-visuelle Nutzung, denn die Inputs der Zwischenschritte sind technisch und visuell unbeschriftet. Besonders bei stärkerer Vergrößerung mit Programmen wie Zoomtext ist das ein Problem. Das Einfachste wäre die klare Beschriftung der Optionen z. B. von "sehr sauber" bis "sehr schmutzig", ähnlich für "sehr modern" bis "sehr altmodisch" – also zum Beispiel "sehr zufrieden / zufrieden / weniger zufrieden / unzufrieden / sehr unzufrieden".

    Seite 3: nicht BITV-konform

    Hier gibt es die Pseudo-Skala "sauber, schmutzig" ohne Beschriftung der Zwischenschritte. Das Hauptproblem ist dabei die nicht-visuelle Nutzung. Sorgen Sie für eine klare Beschriftung – also zum Beispiel "sehr sauber / sauber / eher schmutzig / schmutzig / sehr schmutzig".

    Seite 1: BITV-konform
    Seite 4: nicht anwendbar
  • Prüfschritt 9.4.1.1 - Korrekte Syntax

    Erläuterung: Die verwendete Markup-Sprache HTML muss korrekt eingesetzt werden. Dabei muss jedes Element vollständige Start- und End-Tags besitzen, korrekt verschachtelt sein und darf keine doppelten Attribute enthalten. ID-Attribute müssen eindeutig sein, es sei denn die Spezifikationen erlauben etwas anderes.

    Seite 3: nicht BITV-konform

    Sie allgemeine Anmerkungen. Hier gibt es noch Probleme mit dem Attribut "Step" das Laut Spezifikationen nicht auf einem Input-Element verwendet werden darf.

    Seite 1, 2, 4: BITV-konform
  • Prüfschritt 9.4.1.2 - Name, Rolle, Wert verfügbar

    Seite 2: nicht BITV-konform
    • Der Fortschrittsbalken ist derzeit nur visuell als solcher erkennbar. Für Screenreader-Nutzer*innen steht hier relativ "kommentarlos" ein 50% bzw. 100% im Raum. Verwenden Sie HTML Technologien, um die Fortschrittsanzeige maschinenlesbar zu machen, sodass auch Screenreader den Kontext verstehen. Siehe Beispiel: https://www.w3.org/WAI/tutorials/forms/multi-page/#indicating-progress
    • Die Buttons "Daten löschen" und "Später weitermachen" öffnen jeweils eine Art Popup. Vom Design-Pattern her handelt es sich um einen Dialog. Siehe ausführliche Beschreibung unter: https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html und Best Practice: https://adrianroselli.com/2020/10/dialog-focus-in-screen-readers.html. Siehe auch Prüfschritt 9.2.4.3).
    Seite 3: nicht BITV-konform

    Siehe Erläuterung unter "Seite 2 - Beispielumfrage Schritt 1"

    Seite 1, 4: BITV-konform

Erfüllt sind 26 von 92 Prüfschritten:

Nicht anwendbar sind 52 von 92 Prüfschritten:

Blättern: zum nächsten Test zum letzten Test