search

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.4.12 Textabstände anpassbar bei nativen Elementen #325

Closed Dottopia closed 1 year ago

Dottopia commented 1 year ago

Hallo Zusammen,

ich habe eine Frage bezüglich dem Prüfschritt 9.1.4.12 Textabstände anpassbar in Bezug auf native HTML-Elemente. Denn es ist aufgefallen, dass der Text innerhalb einem Button von einem Input type="file" Element nicht angepasst wird, bei der Verwendung von dem Bookmarklet. Da nach Möglichkeit HTML-Standard-Elemente verwendet werden soll, führt dies entweder zur Abwertung des Prüfschrittes oder das benutzerdefinierte Elemente nachgebaut werden müssen, was eventuell zu anderen/weiteren Barrieren führen kann.

Wie ist dies zu händeln? Im folgenden Issue wurde eine gleiche Thematik zu einem anderen Prüfschritt gestellt: https://github.com/BIK-BITV/BIK-Web-Test/issues/317

HTML-Element ohne Textabstand: 2023-03-22_07h49_34

HTML-Element mit Textabstand: 2023-03-22_07h49_42

Vielen Dank und Grüße Marc

detlevhfischer commented 1 year ago

Hallo Marc Ich denke, natives (user-agent-gesteuertes) Verhalten, auf dass Autoren keinen Einfluss nehmen können, ist von den WCAG-Anforderungen für Autoren grundsätzlich ausgenommen, auch wenn diese Ausnahme hier nicht explizit im normativen Text steht. Ein Zwang zum "Selbstbasteln" wäre schädlich. Die Anforderung selbst geht ja hauptsächlich auf Fließtexte, die für manche Nutzenden gespreizt bzw. mit größerem Zeilenabstand besser lesbar werden. Für isolierte Elemente wie ein button input type="file" ist der Mehrwert also ohnehin gering.

detlevhfischer commented 1 year ago

@mardot können wir dieses Issue schließen?

MarcHaunschild commented 1 year ago

Wir haben ja begründet an anderen Stellen die Verwendung von nativen Elementen erlaubt. Ich würde nicht einmal pauschal sagen, dass native Elemente besser sind. Sie sind es aber in vielerlei Hinsicht, so dass ich hier persönlich der Meinung bin, sie sind mindestens gleichwertig gegenüber vollkommen konformen Lösungen, weil standardisiertes und deshalb den Nutzern bekanntes Verhalten an sich schon die Zugänglichkeit einer Komponente erhöht. Allein schon dass ein Button aussieht wie gewohnt, dass das gesamte Element einen Gesamteindruck macht, den ich wiedererkenne macht es in den meisten Fällen unnötig die Beschriftung überhaupt zu lesen. Ich erkenne dieses bestimmte File-Upload-Ding bereits beim öffnen der Seite aus dem Augenwinkel, weil ich es schon tausend mal gesehen habe. Mein Vorschlag: Wir sollten die Aussage zu nativen Elementen und die Begründung vielleicht aus den einzelnen Prüfschritten raus nehmen und statt dessen übergreifend ablegen. Aus den Prüfschritt kann man dann darauf verweisen. Ein bisschen wie die sufficient techniques in den WCAG. Auch wenn es erst mal nur diese einzige ist, macht es vielleicht auch an anderer Stelle Sinn zentral Informationen bereit zu stellen. Kontraste fallen mir da spontan ein.

Dottopia commented 1 year ago

@MarcHaunschild Ich finde die Idee, die Aussage zu nativen Elementen und deren Begründung aus den Prüfschritte raus zu nehmen und zu zentralisieren, sehr gut.

@detlevhfischer Wenn schriftlich fixiert ist, dass solche Ausnahmen erlaubt sind, kann dieses Issue gerne geschlossen werden.

Vielen Dank!

detlevhfischer commented 1 year ago

Wir sollten die Aussage zu nativen Elementen und die Begründung vielleicht aus den einzelnen Prüfschritten raus nehmen und statt dessen übergreifend ablegen. Aus den Prüfschritt kann man dann darauf verweisen.

@MarcHaunschild Das ist schwierig, wir haben (zurzeit) keine passende Struktur im Prüftool für übergeordnete Anmerkungen über Verlinkungen. Kann man aber für die Zukunft überlegen (ebenso für Hinweise zur Screnreader-Nutzung u. ä,).

detlevhfischer commented 1 year ago

Habe Hinweis auf nicht anpassbare Elemente hinzugefügt (und einen Abeschnitt "Bewertung": https://github.com/BIK-BITV/BIK-Web-Test/pull/326