BIK-BITV / BIK-Web-Test

Testverfahren zur Prüfung der Barrierefeiheit von Webanwendungen anhand der Kriterien der WCAG 2.1, EN 301 549 und BITV 2.0
67 stars 21 forks source link

9.1.3.1d Inhalt gegliedert - Anpassung bei Absatzauszeichnung und CSS generated content #394

Closed detlevhfischer closed 4 months ago

detlevhfischer commented 7 months ago

Screenreader behandeln div im Lesemodus i.d.R. nicht anders als p-Elemente, der praktische Nachteil ist gering oder nicht vorhanden: (ein denkbarer Nachteil wäre, wenn ein User-Stylesheet gezielt die Darstellung von p modifiziert, jedoch nicht von div. )

Einem sich abzeichnenden Konsens in der AGWG folgend (siehe zum Beispiel https://github.com/w3c/wcag/issues/1396 ) schlagen wir deshalb vor, die BIK-Bewertungspraxis, die auf p bei Textinhalten besteht und sonst mit "nicht konform" bewertet, anzupassen.

Die geänderte Prüfschrittbeschreibung hebt stattdessen auf tatsächliche Mängel für Screenreader-Nutzende ab, nämlich störende Ausgaben von "Leer" zwischen Absätzen, die mit doppelten br Elementen umgebrochen werden.

Über CSS content generierte Inhalte sind inzwischen in gängigen Browsern programmatisch zugänglich und bedeuten nicht automatisch Nicht-Konformität, sondern sind in der Regel zu akzeptieren. F87 gilt als veraltet. Die Prüfung auf CSS-generierte Textinhalte entfällt deshalb. Fälle, bei denen wichtige Inhalte bei Nutzung eigener Farbschemata verschwinden (etwa Custom-Checkboxen) werden in 11.7 erfasst.

anatom5 commented 7 months ago

Hallo Detlev, ich bin sehr dagegen <div> statt <p> zu erlauben. Es geht nach meinem Verständnis, darum dass semantische HTML-Elemente verwendet werden, die den visuellen Inhalt repräsentieren. Stichwort: "When no other element is suitable, the div element is used as an element of last resort." ... dabei geht es nach meinem Kenntnisstand nicht nur um Screenreader, sondern zum Beispiel auch um benutzerdefinierte Anpassungen, die für <p> Elemente ggf. einen höheren Zeilenabstand definieren oder visuell hervorheben (für Menschen mit Leseschwäche zum Beispiel). Auch die verschiedenen Reader-Modi in Browsern interpretieren nach meinem Kenntnisstand <div> nicht wie <p> Elemente. Und das sind nur die Beispiele, die mir gerade einfallen. Sind wir alle so sicher, dass das überhaupt keine Auswirkung auf Hilfsmittel hat? Kennen wir alle Hilfsmittel abseits von Screenreadern? Semantik ist ein hohes Gut. Es geht nicht nur um Screenreader, sondern auch um Anpassbarkeit. Ansonsten warte ich auf den nicht mehr fernen Tag, an Screenreader Pseudo-Überschriften anhand der Textgröße erkennen und als solche dann auch vorlesen oder Listen anhand von visuellen Merkmalen erkennen und diese dann korrekt vorlesen und anspringbar machen. Dann sind wir kurz davor der KI das Feld zu überlassen. Ich hoffe wirklich, dass das nochmal überdacht wird. Es geht doch nicht nur um Screenreader, denke ich.

stefanFarnetani commented 7 months ago

Ich finde die Änderung gut. Ich habe das schon lange bekrittelt. Mir wäre die Verhältnismäßigkeit wichtig. Das steht zum Teil bereits im geänderten Text. Man könnte es aber noch deutlicher machen. Wenn auf einem Internetauftritt konsequent nicht ein einziger Textabsatz als

-tag ausgezeichnet wurde und 100-mal doppelte
-Tags verwendet wurden, ist es ein Fehler. Wenn ein paar mal ein Textfragment (String) nicht als

-Tag, sondern "nur" als

-Tag ausgezeichnet wurde, ist das kein Fehler. Ebenso wenn an zwei Stellen ein doppeltes BR verwendet wurde, ist dies kein Fehler. Von @detlevhfischer bereits vorgebracht sind die Auswirkungen gering bis keine. Solche Situationen als Fehler einzustufen halte ich für pedantisch. Auch wenn du @anatom5 sowas gut einschätzen kannst, sehe ich viele Berichte von weniger erfahrenen Testern, die dann immer gleich draufhauen.

p3e7 commented 7 months ago

Hallo Detlev, ich kann mich Jörg (@anatom5) zum Thema <p>-Tags nur anschließen. Gerade in längeren Fließtexten sollte darauf geachtet werden, dass die einzelnen Absätze korrekt ausgezeichnet sind, um Texte beim Einsatz von assistiven Technologien beherrschbarer zu machen. Auch Mischformen aus <p>-Tag, <div>-Tag sollten vermieden werden, um die Navigation innerhalb längerer Textsegmente zu vereinfachen. Dazu gehört auch, dass leere <p>-Tags entfernt werden sollten. In Bezug auf Stefans (@stefanFarnetani) Beitrag stellt sich mir die Frage, wie wir eine möglichst objektive Bewertung erreichen können. Das Fehlen eines <p>-Tags sollte nicht direkt zu einem "nicht konform" führen, jedoch sollten wir als Prüfende stets darauf achten, dass Texte semantisch sinnvoll (wie zuvor beschrieben) strukturiert sind.

Dem Punkt zum CSS-Content stimme ich zu. Aus eigner Erfahrung kann ich bestätigen, dass die generierten Inhalte für gewöhnlich korrekt ausgegeben bzw. wiedergegeben werden.

MarcHaunschild commented 7 months ago

Ich schließe mich Jörg an. Ich kann dieses Argument „funktioniert in (m)einem Screenreader" überhaupt nicht nachvollziehen.

Genauso verstehe ich es nicht, wenn jemand abwerten möchte, wenn valides, semantisch korrektes HTML in seinem Lieblings-UA nicht funktioniert. Dann muss er sich an den Hersteller und nicht an den Webseitenbetreiber wenden.

Es muss darum gehen, sich an die Standards zu halten, damit jede Software, die sich ihrerseits an die Standards hält, darauf verlassen kann, dass dann alles wie gewünscht und vom Nutzer erwartet funktioniert.

Standards funktionieren nur, wenn die gesamte Kette - von der Website, über das OS, den Browser, das Hilfsmittel und alle verwendeten PlugIns - standardkonform arbeitet (oder zumindest nicht störend eingreift). Da schon bei der Basis, also dem Code drauf zu verzichten, kann nicht im Sinne von Nutzerinnen sein.

Was ist beispielsweise mit Textabstände anpassen? - Funktioniert das bei divs?

Und was wenn ein Nutzer sagt, ich möchte nicht die Abstände von den ohnehin großen Überschriften anpassen, sondern nur die von Absätzen (oder Zeilenhöhe oder Zeilenlänge oder was weiß ich was). Dann ist das mit einer Zeile CSS oder einem PlugIn, dass es einem erlaubt Absätze nach persönlichen Bedürfnissen zu modifizieren sehr einfach möglich. Funktioniert dann auf allen Webseiten, wenn man das für alle Webseiten festlegt. Aber bei manchen dann nicht. Und Nutzer sollen dann wissen, warum es manchmal nciht klappt? Die sollen dann das HTMl analysieren?

Absätze sind auch ein Sinnzusammenhang, divs dagegen nicht.

Kann man nicht mit manchen SR auch von Absatz zu Absatz navigieren? Werden dabei womöglich wichtige Inhalte in divs übersprungen?

Es geht ja um Info and Relationship und divs bilden nun mal absolut überhaupt gar keine Informationen oder Beziehungen ab. Sie sind erklärtermaßen vollkommen frei von Semantik und absolut ungeeignet irgendetwas auszuzeichnen.

Sie haben eigentlich nur einen einzigen Zweck: unabhängig von Semantik Dinge zusammenfassen zu können, um damit per JavaScript oder CSS etwas tun zu können, in der Regel visuell.

Ich kann auch überhaupt nicht verstehen, wie die WG auf diese Idee kommt. Die WCAG sind doch technik-agnostisch?!? - Schreiben die solche Ausnahmen auch für PDFs, Word- und Libre-Office-Dokumente?

Auszeichnungssprachen sind ja ohnehin schon mitunter von verzweigten (Pseudo-) Standards geplagt - siehe die ganzen Markdown-Geschmacksrichtungen. Da sieht man, was es heißt, wenn es nicht die eine Spezifikation gibt. Manche Editoren zeigen nur die mit sich selbst erstellten Dokumente korrekt an. Zumindest einfache Dokumente, die nur einen Kern-Satz an Elementen verwenden, werden von jedem MD-Editor/-Viewer korrekt angezeigt. Standards haben doch einen leicht begreifbaren Sinn!

Und dazu gehören natürlich Absätze. Wenn man sich nicht mal mehr darauf verlassen kann, dass die vorhanden sind, können wir auch wieder marquee zulassen - das hört sich in meinem SR (VO) auch wie ein Absatz an und hat auch keine Semantik. Und die Schrift läuft auch noch so lustig (Safari)!

Was ist denn ein Argument dafür, es nicht mehr abzuwerten? - Ich meine wir sind da eh nicht streng. Wenn da ein „AGB akzeptieren“ in einem div steht, stört das nicht weiter, aber längere Fließtexte? Wie gesagt geht es um Anpassbarkeit und Kompatibilität, die aufgrund von bestimmungsgemäßer Verwendung Individualisierte Darstellungen erlauben für Menschen die darauf angewiesen sind. Auch mit Hilfsmitteln, die es heute noch gar nicht gibt. Die müssen sich drauf verlassen können, dass barrierefreie Produkte standardkonform ausgezeichnet sind.

Link in Kontext kann man doch auch nicht als bestanden werten, wenn ein weiter-lesen Link in einem Element ohne Semantik steht (span oder div). In demselben p aber schon.

Weil ein p per Definition eben ein Sinnzusammenhang ist. Ob das nun ein SR auswertet oder nicht, kann hier keine Rolle spielen. Barrierefreie Webseiten sind nicht Webseiten, die im SR sondern mit jedem (zukünftigen) standardkonformem Hilfsmittel funktionieren! Wir sollten Entwicklern von neuen Tools nicht den Boden unter den Füßen wegziehen.

Zumal: wo ist das Problem das abzuwerten? Dann schreibt der Entwickler halt ein p dahin, wo er das div hat. Das ist eine Minute Arbeit. Es ist ja schon absurd, wie wenig viele Entwickler von HTML wissen, aber ein Absatz? Das ist heutzutage schon zu viel verlangt? - Puh. Da halten wir die aber für extrem dumm...

Ich bitte auch an Leute zu denken, die beraten. Was sollen wir denn dann noch den Entwicklern empfehlen zu tun, wenn sie sich hier an Standards halten müssen, dort aber nicht? Man stellt die Spec an sich ja in Frage damit. Die Empfehlung „haltet euch an den Standard“ ist einfach, klar, nachvollziehbar und sinnvoll.

Die Empfehlung: „haltet euch nur an die Spec, wenn es sonst nicht im SR funktioniert“ ist nicht hilfreich, sondern verwirrend, willkürlich, muss ständig an Fortschritte oder Rückschritte einzelner SR-Hersteller angepasst werden und macht sich über den Sinn und Zweck von Standards geradezu lächerlich...

Ich bitte auch zu berücksichtigen, dass mit Jörg und mir sich zwei Leute für Absätze aussprechen, die selber Webseiten entwickeln. Das ist kein Aufwand, den wir hier irgendwem ersparen. Ein p zu verwenden ist fast immer vollkommen unproblematisch möglich. Es ist gibt wirklich keinen praktischen Grund hierauf zu verzichten.

Und wenn es ein CMS mal nicht erlaubt einen einzelnen Hinweis unter einem form auszuzeichnen - dann sei's drum Handhaben wir doch jetzt auch schon so (so habe ich es jedenfalls verstanden), Dann besteht man halt mit einem "eher erfüllt".

Und es passt auch gar nicht zu anderen Forderungen, wie dem dämlichen blockquote. Zitate sind praktisch immer auch textlich erkennbar und angekündigt und folgen meist dem Pattern "Zitat - Quelle". Und zumindest VoiceOver sagt hier auch nichts an (kündigt es wie einen Absatz als "Textelement" an). Wieso dann blockquotes fordern, aber so etwas essenzielles wie Absätze nicht?

Oder Überschriftenebenen? - Blinde können - unabhängig von der Ebene - von Überschrift zu Überschrift springen. In der Regel ist das einfacher, als bestimmte Überschriftenebenen direkt anzuspringen, weil die nun mal auf fast allen Webseiten nicht korrekt ausgezeichnet sind und man kommt auch durch eine Seite, wenn man immer zur nächsten Überschrift springt, egal welche Ebene. Es gibt sogar Blinde, die nicht wissen, warum verschiedene Ebenen angesagt werden (war gerade gestern bei Joschi In der CPACC-Gruppe Thema). Da kann man auch gleich den Sinn in Frage stellen und wie viel das überhaupt bringt. Es ist nicht so, dass man ohne Angabe einer Ebene vollkommen aufgeschmissen wäre. Aber hier wendet man (zu Recht) nicht das Argument an: kommt man schon irgendwie mit klar. Ja da kommen dann sogar so überzogene, ebenfalls nicht mit dem Standard zu begründende Forderungen nach einer einzigen h1 - die sich vor allem aus der Vorliebe einiger prominenter blinder Poweruser herleitet.

Und wenn die nächste Generation andere Vorlieben hat, passen wir unser Testverfahren wieder an?

Nein, ich bin fest davon überzeugt, dass nur ein Test auf das Einhalten von Standards Sinn macht. Alles andere ist beliebig, nicht erklärbar und unnötig kompliziert.

Die Bewertung darf nicht von heute verfügbaren Hilfsmitteln, populären Meinungen oder einzelnen Herstellern abhängen.

Also wenn wir mit dem genannten Argument divs erlauben, müssen wir auch die Auszeichnung mit allen anderen Elementen erlauben, die sich in einem SR gleich anhören, egal wie blödsinnig: figure, marquee, blockquote, canvas. Jedes Argument muss(!) immer und für alle gelten. Alles andere ist willkürlich, unlogisch und nicht nachvollziehbar.

anatom5 commented 7 months ago

@stefanFarnetani: Wir (die Prüfer und Prüferinnen) haben ja schon die Möglichkeit über die Erfüllungsgrade "erfüllt, eher erfüllt oder teilweise erfüllt" zu differenzieren. Und wer ein "nicht erfüllt" oder "eher nicht erfüllt" abgibt, wenn irgend ein kleines C-Content-Element in einem <span> oder <div> steht, braucht halt Unterstützung von der QS, die hier ja genau regulierend eingreifen soll/kann. @MarcHaunschild hat mein Argument schön ausführlich erklärt. In der Sache sind wir uns einig. Aber das ist letztendlich nur ein Frage der Vereinheitlichung der Prüfbewertung und der Qualitätssicherung. Manchmal finde ich sogar ein <p> Element unangemessen, wenn da nur drei Worte drin stehen, wie "Letzte Aktualisierung 17.12.2020". Dann könnte man sogar sagen, dass es semantisch kein Paragraph ist. Und dann wäre ein <div> oder <span> sogar angemessen. Ich glaube, wir brauchen einfach Fingerspitzengefühl.

MarcHaunschild commented 7 months ago

Einem sich abzeichnenden Konsens in der AGWG folgend (siehe zum Beispiel w3c/wcag#1396 ) schlagen wir deshalb vor, die BIK-Bewertungspraxis, die auf p bei Textinhalten besteht und sonst mit "nicht konform" bewertet, anzupassen.

Hast du dich vertan mit dem issue, @detlevhfischer ? Die Diskussion die du referenzierst für einen sich abzeichnenden Konsens umfasst 7 Beiträge, die 3 Jahre alt sind und sich nicht auf 1.3.1 beziehen, sondern auf 1.4.12...

Meintest du vielleicht eine andere Diskussion?

detlevhfischer commented 7 months ago

Hast du dich vertan mit dem issue

Ich have in den AGWG Issues nach irgendwelchen Aussagen gesucht, die sich auf die Nutzung von p bzw div und die Sicht der WG bezügl. Bewertung der Konformität beziehen. Von "Konsens" zu sprechen ist immer schwer, da es zu vielem keinen abschließenden Konsens (über eine explizite Entscheidung) gibt. Die gefundene Diskussion schien mir schon relevant für die Bewertung von 1.3.1. Und genau lesen muss dann jeder selbst.

Mein Hauptgedanke bei diesem PR ist, die Bewertungspraxis des BIK BITV-Tests möglichst nahe an den (wie auch immer zu ermittelnden) internationalen Konsens der AGWG heranzuführen. Vielleicht ist es sinnvoll, dazu noch mal ein explizites AGWG issue zu machen (es gibt ja nur 600+ noch offene) - aber das Ergebnis wird wohl sein, dass das "Bestrafen" der Nutzung von div statt p in 1.3.1 (9.1.3.1) sich als deutscher Sonderweg (bzw. als Historie des BIK Tests) herausstellt.

Nochmal: Niemand empfiehlt die Nutzung von div für Textabsätze - aber wir müssen anhand klarer Nachteile für Nutzende mit Behinderungen (und hier bei 1.3.1., Nachteile bezügl. programmatischer Ausgabe) rechtfertigen können, warum wir 1.3.1 bei einem Angebot mit FAIL bewerten, wenn div statt p eingesetzt wird.

MarcHaunschild commented 7 months ago

Hast du dich vertan mit dem issue

Ich have in den AGWG Issues nach irgendwelchen Aussagen gesucht, die sich auf die Nutzung von p bzw div und die Sicht der WG bezügl. Bewertung der Konformität beziehen.

Ach so, verstehe. Nur die Diskussion zum SC 1.4.12 bezieht sich ja darauf, ob auch Absätze, die nicht als p ausgezeichnet sind, also Absätze im weiteren Sinne wie li, headings usw auch zu einem Fail bei 1.4.12 führen können

Das wurde dort bejaht, steht also für eine strenge Auslegung des SC und dürfte deinem Anliegen nach einer Lockerung der Bewertungspraxis sogar entgegenstehen - wenn ich das recht verstehe.

Mein Hauptgedanke bei diesem PR ist, die Bewertungspraxis des BIK BITV-Tests möglichst nahe an den (wie auch immer zu ermittelnden) internationalen Konsens der AGWG heranzuführen. Vielleicht ist es sinnvoll, dazu noch mal ein explizites AGWG issue zu machen (es gibt ja nur 600+ noch offene) - aber das Ergebnis wird wohl sein, dass das "Bestrafen" der Nutzung von div statt p in 1.3.1 (9.1.3.1) sich als deutscher Sonderweg (bzw. als Historie des BIK Tests) herausstellt.

Das will ja niemand. Ich halte die jetzige Praxis eines "eher bestanden" bei wenigen Verstößen aber für genau den nicht pedantischen Weg, den beispielsweise Patrick Laucke fordert (also keine allzu strenge Bewertung).

Ich möchte an den normativen Text von 1.3.1 erinnern:

"Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text."

Ein div ist nicht dafür geeignet visuell präsentierte Zusammenhänge und Strukturen für Software ermittelbar zu machen.

Einen längeren Text komplett mit falschen Elementen auszuzeichnen widerspricht der Intention des SC:

"The intent of this Success Criterion is to ensure that information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes."

Das geht in HTML ausschließlich mit den richtigen (impliziten oder expliziten) Rollen.

Nochmal: Niemand empfiehlt die Nutzung von div für Textabsätze - aber wir müssen anhand klarer Nachteile für Nutzende mit Behinderungen (und hier bei 1.3.1., Nachteile bezügl. programmatischer Ausgabe) rechtfertigen können, warum wir 1.3.1 bei einem Angebot mit FAIL bewerten, wenn div statt p eingesetzt wird.

Ich sehe das anders. Wir müssen die Forderung des normativen Texts prüfen. Da steht nicht, dass wir Nachteile von Nutzern beweisen müssen.

Die Nachteile sind vermutlich auch längst vorhanden. Ich würde keine Software bauen, die sich auf korrekte Auszeichnungen verlassen muss, denn wir alle wissen, dass es durchgängig korrekt ausgezeichnete Webseiten kaum gibt. Also wer sagt uns, ob wir nicht bessere ATs mit mehr Möglichkeiten hätten, wenn sauberes HTML die Regel wäre? Typisches Henne-Ei Problem und für mich dasselbe Argument wie es Betreiber von unzugänglichen Online-Shops bringen: bei uns kaufen behinderte Menschen nicht ein.

Logisch können die ja auch nicht und ATs können sich nicht auf korrekte Auszeichnung verlassen und der daraus entstehende Nachteil für Nutzer ist offensichtlich und muss nicht bei jeder Bewertung diskutiert werden.

Machen wir bei anderen Prüfschritten auch nicht. Das Fehlen von autocomplete hat auch keinen Nachteil für Nutzer, weil es überhaupt keine UAs gibt, die das auswerten und dennoch vergeben wir hier ein FAIL.

Weil es ein klarer Verstoß gegen ein SC ist, reale Welt hin oder her.

Der Existenzgrund für die zwei SCs ist jeweils derselbe: programmatische Ermittelbarkeit von Informationen. Ich fände es gut, hier konsistent zu bleiben.

Versteh mich nicht falsch. Es geht mir nicht darum, mich durchzusetzen. Ich sage nur, wie ich 1.3.1 verstehe. Und ich finde da keine Unklarheit. Der Code muss die visuell präsentierte Struktur wiedergeben. Also müssen Texte, die wie Überschriften aussehen, auch so ausgezeichnet werden, Texte, die wie Listen aussehen, müssen als Liste ausgezeichnet werden und Texte, die wie Absätze aussehen, müssen als Absätze ausgezeichnet werden.

Und wir drücken wie bisher hier und da mal ein Auge zu, um nicht in pedantische deutsche Rechthaberei abzudriften.

Mir scheint die aktuelle Praxis sehr sinnvoll und in Harmonie zur WCAG - da mag es bei anderen SCs mehr Diskrepanz geben. Aber Kollegen wie @cstrobbe oder @johannesFischer84 achten da eigentlich auch schon gut mit drauf.

Wenn sich die beiden mal zu Wort melden, fände ich das übrigens auch sehr interessant.

johannesFischer84 commented 7 months ago

Detlev, danke für deinen Anpassungs-Vorschlag. Aus meiner Sicht geht es vor allem um die häufige Frage, wie stark man darauf setzt, dass Inhalt/Content ohne Beachtung von bestimmter assistiver Technologie oder Nutzeragenten bzw. Browsern für sich selbst konform ist oder ob der Inhalt mit bestimmten häufig genutzten assistiven Technologien / Browsern barrierefrei funktioniert. Ich bin grundsätzlich eher für Konformität des Inhalts für sich allein, kann aber die andere Sichtweise auch nachvollziehen.

WCAG-Kriterium 1.3.1 bzw. die Forderung nach Nutzung der passenden Semantik für Dokumentstrukturen oder auch Trennung von Struktur/Darstellung/Verhalten (HTML/CSS/JavaScript) sehe ich als die wichtigste Basis für Barrierefreiheit an. Wie schon angedeutet wurde und worauf auch die Diskussion der WCAG Working Group verweist, kann die Darstellung von Textabständen nach WCAG 1.4.12 durch die Verwendung der Semantik ebenso beeinflusst werden.

Das angesprochenene Fingerspitzengefühl finde ich richtig. Wenn auf einer Seite jede Menge Fließtext vorkommt, aber nur <div> verwendet wird, würde ich die Bewertng schon auf teilweise erfüllt bzw. nicht konform herabsetzen. Wenn kaum wirklicher Fließtext vorkommt oder nur vereinzelt keine passende Semantik verwendet wurde, ist erfüllt oder eher erfüllt auch in Ordnung. Ebenso muss <p> nicht verwendet werden, wenn kurze Ausdrücke verwendet werden, Jörg Morsbach / @anatom5 hat als Beispiel dafür "Letzte Aktualisierung 17.12.2020" angegegeben.

Man kann es mit der Semantik natürlich sehr weit und vielleicht zu weit treiben. Zum Beispiel ist das <address>-Element für Kontaktinformationen nach HTML-Standard vorgesehen. Dass man dieses Element verwendet, würde ich nur empfehlen, aber nicht verpflichtend sehen. Ob ein Element verpflichtend zu nutzen ist, dabei würde ich mich daran orientieren, zu welchen HTML-Elementen in den WCAG Techniques vorhanden sind. Zum <p>-Element gibt es zwar meines Wissens keine direkte Technique, aber es ist ein absolutes Basis-Element für Text und daher als verpflichtend anzusehen. Wenn ein anderes Element noch bessere Semantik liefert wie <blockquote> für ein Blockzitat, dann braucht <p> natürlich nicht auch noch verwendet werden. Aber gar keine Semantik wie <div> halte ich für schlecht.

Wie ich beschrieben habe, kann man <div> in manchen Fällen aktzeptieren. Das Minimum wäre für mich, dass man in der Prüfschrittanleitung <p> bzw. passende Semantik aber eindringlich empfiehlt. Im Anleitungs-Entwurf steht z. B.

Prüfen, ob Absätze mit p ausgezeichnet sind. Da die Auszeichnung von Absätzen mit div statt mit p-Elementen für Screenreader-Nutzende im Lesemodus keinen wesentlichen Nachteil mit sich bringt, ist sie jedoch auch zu akzeptieren.

Ich würde das eher so formulieren:

Prüfen, ob Absätze mit p oder anderer passender Semantik ausgezeichnet sind. Da die Auszeichnung von Absätzen mit div statt mit p-Elementen für Screenreader-Nutzende im Lesemodus keinen wesentlichen Nachteil mit sich bringt, kann sie in bestimmten Fällen (z. B. wenig Fießtext oder optisch kein richtiger Textabsatz) akzeptiert werden.

Unter Hinweisen steht im Anleitungs-Entwurf:

Das für Absätze vorgesehene Element ist grundsätzlich p. Die Verwendung von div ist nicht empfehlenswert, hat aber in der Regel keine Nachteile für die programmatische Ausgabe, etwa durch Screenreader. Die Nutzung von div anstelle von p für Textabsätze sollte deshalb nicht zu einer Bewertung als "nicht erfüllt" führen.

Ich würde das eher so formulieren:

Korrekte Semantik wie in der Regel p für Absätze ist allgemein sehr zu empfehlen. Dennoch ist eine Nutzung von div anstelle von p zumindest in der programmatischen Ausgabe, etwa durch Screenreader, in der Regel nicht mit Nachteilen verbunden. Eine Bewertung mit "nicht erfüllt" ist meist zu streng.

Die Prüfung/Hinweise für echten Text mit dem CSS-Attribut content hast du ganz entfernt. Ich bin mir unsicher, wie sich die Verwendung abseits von Screenreader-Ausgaben auswirkt, z. B. bei EN-Kriterium 11.7 (Übernahme von Nutzereinstellungen). Zwar muss man die Verwendung in WCAG 1.3.1 nicht mit Abzug bestrafen. Aber ich würde mir wünschen, dass in den Hinweisen das Attribut noch erwähnt bzw. dass die konsequente Trennung von Semantik und optischer Darstellung (HTML / CSS) eindringlich empfohlen wird.

Andreas-Englisch commented 7 months ago

JAWS erkennt den Unterschied zwischen <p> und <div>. Ich kann mir z.B. mit EINF+STRG+P die Liste aller Textabsätze anzeigen lassen oder mit P zum nächsten Absatz navigieren (letzteres funktioniert nicht analog zu EINF+STRG+P, weil dabei auch andere Elemente erreicht werden). Ich kann aber nicht sagen, ob diese Absatz-Funktion von JAWS-NutzerInnen verwendet wird.

detlevhfischer commented 6 months ago

Ich habe den Text noch etwas angepasst und Formulierungsvorschläge von @johannesFischer84 dafür genutzt. Grundsätzlich bleibt es schwierig, eine Grenze zu ziehen, ab wann die Verwenduing von div statt p dann nicht mehr konform wäre (also "teilweise erfüllt" oder schlechter) - bei wievielen Absätzen ist es noch OK? Ich habe deshalb nicht Formulierungen wie "Eine Bewertung mit "nicht erfüllt" ist meist zu streng" übernommen, da hier die Grenze impliziert, jedoch nicht quantifiziert wird.

Das Minimum wäre für mich, dass man in der Prüfschrittanleitung <p> bzw. passende Semantik aber eindringlich empfiehlt.

Die Prüfschritte sind ja keine Anleitung für beste Praxis und werden mir Empfehlungen ohne klare Aussagen zur Konformitätsbewertung schnell überfrachtet. Wichtig ist aus Sicht der Prüfung, die sich an WCAG-Konformität und den normativen Vorgaben sowie dem Konsens der Working Group (soweit ermittelbar) orientiert -- was wir wollen -- , dass Prüfende wissen, was aus normativer Sicht ein FAIL sein muss. Natürlich bleibt immer ein subjektiver Spielraum, und am Ende gibt es eine Qualitätssicherung, die möglicherweise eine andere Sicht hat...

MarcHaunschild commented 6 months ago

Man kann ja überlegen, ob man für Fließtexte wie typische Artikel die Verwendung von Absätzen vorschreibt.

Nur so als Idee...

johannesFischer84 commented 6 months ago

@detlevhfischer Detlev, danke, ich bin persönlich mit deinen Änderungen zufrieden. Das "ist meist zu streng" aus meiner Formulierung hast du durch "in der Regel" ersetzt, was ich genauso gut finde. Mir gefällt auch, dass du das content-Attribut bzw. die HTML-/CSS-Trennung in den Hinweisen eingefügt hast.

@MarcHaunschild

Man kann ja überlegen, ob man für Fließtexte wie typische Artikel die Verwendung von Absätzen vorschreibt.

Marc, das wäre aber ein sehr spezieller Fall für die Erklärung in der Prüfanleitung. Bei Nachrichten-Artikel hast du in der Regel viel Fließtext in Absätzen gegliedert, die auch optisch so aussehen. Ich denke, dass dein Wunsch schon aus dem jetzigen Anleitungsentwurf herausgelesen werden kann: In der Prüfung Nummer 3 würde das "z. B. wenig Fießtext oder optisch kein richtiger Textabsatz" nicht gelten. Damit könnte man bei Nachrichten-Artikeln ein generelles Ersetzen von <p> durch <div> nicht akzeptieren, denke ich.

MarcHaunschild commented 6 months ago

Ich habe es absichtlich sehr vorsichtig formuliert "man könnte überlegen" - es gab ja eine Bitte um deutlichere Formulierung wann es wirklich nötig wäre, das p-Element zu nutzen. Die kam nicht von mir. Ich habe den Prüfschritt bisher ja auch so verstanden und bewertet.