Radioboxen und Checkboxen barrierefrei gestalten

[NinaG]

Radioboxen und Checkboxen haben jeweils ein eigenes Label für jede Box. Zusätzlich kann man in TYPOlight noch einen übergreifenden "Titel" eingeben, der den "Verwendungszweck" der Boxen beschreibt. Dieser wird momentan ebenfalls als Label (ohne zugehöriges Eingabefeld) ausgegeben. Das Label hat zwar eine FOR-Angabe, aber diese bezieht sich auf eine ID die auf dem DIV liegt. Das funktioniert so nicht für Screenreader.

<label for="ctrl_27">Unterlagen auswählen</label> 
<div id="ctrl_27" class="checkbox_container">
<span><input type="checkbox" name="Funktionstest[]" id="opt_18_0" class="checkbox" value="Option A" /> <label id="lbl_18_0" for="opt_18_0">Option A</label></span>
<span><input type="checkbox" name="Funktionstest[]" id="opt_18_1" class="checkbox" value="Option B" /> <label id="lbl_18_1" for="opt_18_1">Option B</label></span>
<span><input type="checkbox" name="Funktionstest[]" id="opt_18_2" class="checkbox" value="Option C" /> <label id="lbl_18_2" for="opt_18_2">Option C</label></span>
</div>

Für blinde Nutzer macht dieses konstrukt keinen Sinn, weil die assistive Technologie das übergreifende Label nicht den dazu gehörenden Radioboxen/Checkboxen zuordnet.

Korrekt wäre stattdessen dieses Konstrukt:

<fieldset>
<legend>Unterlagen auswählen</legend> 
<div id="ctrl_27" class="checkbox_container">
<span><input type="checkbox" name="Funktionstest[]" id="opt_18_0" class="checkbox" value="Option A" /> <label id="lbl_18_0" for="opt_18_0">Option A</label></span>
<span><input type="checkbox" name="Funktionstest[]" id="opt_18_1" class="checkbox" value="Option B" /> <label id="lbl_18_1" for="opt_18_1">Option B</label></span>
<span><input type="checkbox" name="Funktionstest[]" id="opt_18_2" class="checkbox" value="Option C" /> <label id="lbl_18_2" for="opt_18_2">Option C</label></span>
</div>
</fieldset>

Marco Zehe (blinder Nutzer, erfahrener Mitarbeiter bei Mozilla am NVDA-Screenreader) erklärte das so: _"Nur das Fieldset baut eine gruppenbezogene Abhängigkeit zwischen der Frage und den Auswahlmöglichkeiten bei Radio-/Checkboxen auf, mit denen Screen Reader klarkommen."

Ich möchte daher darum bitten, dass bei Checkboxen und Radioboxen per Default ein Fieldset-Konstrukt geschaffen wird. So haben wir dann endlich damit und mit den anderen Änderungen die in der 2.8 enthalten sind die Umbauten für Barrierefreiheit in den Formularen erfolgreich abgeschlossen. :-)

--- Originally created on December 9th, 2009, at 10:27am (ID 1257)

[leofeyer]

Das dürfte ziemlich schwierig bis unmöglich werden, denn die Fieldsets nutzen wir bereits für die einklappbaren Paletten. Fieldsets für Checkboxen würden also bedeutet, dass man diese auch einklappen könnte - und das ist wohl kaum im Sinne des Erfinders. Zudem erwartet das CSS ein Label für die Feldüberschrift und keine Legend (die sich nebenbei bemerkt auch nicht wirklich gut formatieren lässt).

Sollten wir das umsetzen, wären damit viele Änderungen verbunden, die nicht nur den Core, sondern auch Erweiterungen und alternative Backend-Themen beträfen. Deswegen am liebsten im Rahmen eines Major- oder Minor-Release.

--- Originally created on December 9th, 2009, at 11:18am

[NinaG]

Sollten wir das umsetzen, wären damit viele Änderungen verbunden, die nicht nur den Core, sondern auch Erweiterungen und alternative Backend-Themen beträfen. Deswegen am liebsten im Rahmen eines Major- oder Minor-Release.

Danke fürs Annehmen. Ich steh dir dann gerne mit Rat und Tat zur Seite, sobald du das angehst. Wir finden da sicher einen guten Weg. Und ja, das geht natürlich nur für einen größeren Sprungwechsel. Wenn es für die 2.8 nicht mehr zeitlich klappt, dann wäre es schön, wenn wir das für die 2.9 anvisieren könnten. Ich helfe dann wie gesagt gerne, dass wir da einen guten Kompromiss hinbekommen :)

--- Originally created on December 9th, 2009, at 11:26am

[leofeyer]

Wie gesagt müsste aus Kompatibilitätsgründen auf jeden Fall das Label oberhalb des DIVs bleiben (das FOR-Attribut lässt sich natürlich herausnehmen). Eventuell könnte man ein Fieldset mit einer unsichtbaren Legende darum herum bauen?

--- Originally created on December 9th, 2009, at 11:41am

[NinaG]

Wenn ich dich richtig verstehe, schlägst du das so vor?

<fieldset>
<legend class="invisible">Unterlagen auswählen</legend> 
<label class="lbl_18">Unterlagen auswählen</label> 
<div id="ctrl_18" class="checkbox_container">
<span><input type="checkbox" name="Funktionstest[]" id="opt_18_0" class="checkbox" value="Option A" /> <label id="lbl_18_0" for="opt_18_0">Option A</label></span>
<span><input type="checkbox" name="Funktionstest[]" id="opt_18_1" class="checkbox" value="Option B" /> <label id="lbl_18_1" for="opt_18_1">Option B</label></span>
<span><input type="checkbox" name="Funktionstest[]" id="opt_18_2" class="checkbox" value="Option C" /> <label id="lbl_18_2" for="opt_18_2">Option C</label></span>
</div>
</fieldset>

Wichtig wäre hier imho, dass dieses Label auf jeden Fall eine eigene Klasse hat, damit man es (unabhängig von den anderen Labels per CSS ansprechen kann).

Dumm wäre halt, dass man eine inhaltliche Dopplung der selben Aussage hätte. Weshalb möchtest du dieses Label an der Stelle unbedingt behalten? Wo wird es überall genutzt, so dass man es hier unbedingt behalten muss? Oder missverstehe ich dich? :)

--- Originally created on December 9th, 2009, at 11:49am

[leofeyer]

Wenn das Label wegfällt, müssen sämtliche CSS-Dateien, alternative Backend-Themes und evtl. auch Erweiterungen angepasst werden. Das steht auf gar keinen Fall dafür! Lieber würde ich die Legende weglassen, aber erkennt der Screenreader die Zusammenhänge dann noch?

--- Originally created on December 9th, 2009, at 11:59am

[leofeyer]

Nebenbei gefragt: Dasselbe Problem besteht im Frontend auch, oder?

--- Originally created on December 9th, 2009, at 12:01pm

[NinaG]

Wir sollten dem Fieldset selbst auf jeden Fall noch eine Klasse wie "checkbox_fieldset" oder etwas in der Art geben. So lassen sich einfach Referenzierungen per CSS auf diese spezielle Legend einstellen, wenn das benötigt wird.

--- Originally created on December 9th, 2009, at 12:02pm

[NinaG]

Ich spreche die ganze Zeit vom Frontend, während du wohl vom Backend gesprochen hast. Jetzt kapier ich auch endlich, von welchem Klappmechanismus du gesprochen hast lach

--- Originally created on December 9th, 2009, at 12:02pm

[NinaG]

Wenn das Label wegfällt, müssen sämtliche CSS-Dateien, alternative Backend-Themes und evtl. auch Erweiterungen angepasst werden. Das steht auf gar keinen Fall dafür! Lieber würde ich die Legende weglassen, aber erkennt der Screenreader die Zusammenhänge dann noch?

Nein, damit geht der Sinn verloren. Dann bin ich dafür, dass wir diesen Kompromiss nutzen:

<fieldset class="checkbox_fieldset">
<legend class="invisible">Unterlagen auswählen</legend> 
<label class="lbl_18">Unterlagen auswählen</label> 
<div id="ctrl_18" class="checkbox_container">
<span><input type="checkbox" name="Funktionstest[]" id="opt_18_0" class="checkbox" value="Option A" /> <label id="lbl_18_0" for="opt_18_0">Option A</label></span>
<span><input type="checkbox" name="Funktionstest[]" id="opt_18_1" class="checkbox" value="Option B" /> <label id="lbl_18_1" for="opt_18_1">Option B</label></span>
<span><input type="checkbox" name="Funktionstest[]" id="opt_18_2" class="checkbox" value="Option C" /> <label id="lbl_18_2" for="opt_18_2">Option C</label></span>
</div>
</fieldset>

So kann man das Fieldset durch seine individuelle Klassenart anders ansprechen, als "normale" Fieldsets. Das Legend ist für blinde Nutzer da, aber zerfetzt keine Layouts, weil es aus dem sichtbaren Bereich verschoben wird. Das Label bleibt bestehen (wenn auch ohne FOR, dafür mit Klasse um es bei Bedarf stylen zu können).

Das ist - denke ich - im Rahmen der Wünsche nach Rückwärtskompatibilität eine akzeptable Lösung, die den Webdesignern alle Möglichkeiten lässt:

Der Standard-Webdesigner hat keinen Stress wegen dem Label, unterstützt aber "unabsichtlich" blinde Nutzer durch eine korrekte Gruppierung mit Fieldset und Legend.

Für Projekte bei denen Barrierefreiheit wichtig ist, kann man dann so rangehen, dass man bei Bedarf das Label auf display: none stellt und somit ganz aus dem Projekt rauskappt um die Dopplung zu vermeiden.

Ich denke, das kann man als Kompromiss nehmen.

--- Originally created on December 9th, 2009, at 12:07pm

[leofeyer]

Und was machen wir im Backend?

--- Originally created on December 9th, 2009, at 12:08pm

[NinaG]

Und was machen wir im Backend?

da die Fieldset ne eigene Klasse hat, könnten wir doch dem Klappmechanismus vielleicht mitteilen, dass Fieldsets mit dieser Klasse nicht betrifft?

Die invisible-Klasse greift auch im Backend soweit ich weiß, so dass das auch dort funktioniert. Muss man nur noch mit CSS zuweisen, dass dieses Fieldset keinen Rahmen hat.

--- Originally created on December 9th, 2009, at 12:28pm

[leofeyer]

Ja, aber dort kann ich das Label nicht ausblenden, oder? Gibt es nicht eine CSS-Anweisung für "nicht vorlesen"?

--- Originally created on December 9th, 2009, at 12:37pm

[NinaG]

Ja, aber dort kann ich das Label nicht ausblenden, oder? Gibt es nicht eine CSS-Anweisung für "nicht vorlesen"?

Wenn man will, dass die Techniken so tun, als gäbe es ein Element gar nicht (es also auch nicht z. B. vorlesen): display: none;

Wenn man ein Element nur aus dem sichtbaren Bereich verschieben will, aber z. B. Screenreader es weiter erkennen und vorlesen sollen: deine invisible-Klasse aus der typolight.css

--- Originally created on December 9th, 2009, at 12:52pm

[leofeyer]

Wir brauchen aber genau den anderen Fall: Anzeigen aber nicht vorlesen!

--- Originally created on December 9th, 2009, at 12:58pm

[NinaG]

Wir brauchen aber genau den anderen Fall: Anzeigen aber nicht vorlesen!

Dann könnte man es so machen, dass man über den Mediatype geht http://www.w3.org/TR/CSS2/aural.html#aural-media-group

Für media aural undmedia speech wird dann festgelegt, dass es display: none ist, also dort gar nicht erst ausgegeben wird.

--- Originally created on December 9th, 2009, at 01:14pm

[NinaG]

Das funktioniert nich 100% in allen Programmen, aber wenn man beides angibt, sollte die Chance schon höher sein.

--- Originally created on December 9th, 2009, at 01:16pm

[NinaG]

Das funktioniert nich 100% in allen Programmen, aber wenn man beides angibt, sollte die Chance schon höher sein.

Selbst das ist eigentlich noch übertrieben. Es wird von User-Agents leider noch nicht hinreichend oder teilweise schlichtweg gar nicht unterstützt. Allerdings sollte das wiederum imho nicht unser Problem sein, denn die Definition gibt es und da sind die UA-Hersteller in der Pflicht, nicht TL.

--- Originally created on December 9th, 2009, at 01:19pm

[NinaG]

Mit CSS3 ist media-type speech der Ersatz für Aural und wird z. B. vom Opera UA wohl schon schön unterstützt.

Hab noch das hier gefunden: http://lab.dotjay.co.uk/notes/css/aural-speech/

--- Originally created on December 9th, 2009, at 01:27pm

[NinaG]

Ich muss dazu sagen, dass ich mich mit diesem media-type bisher noch gar nicht befasst habe. Nur damit du dich nicht wunderst, weshalb ich hier so viele kleine Zwischenschritte bei den Antworten gemacht habe :)

--- Originally created on December 9th, 2009, at 01:31pm

[NinaG]

Vergiss das mit dem Aural/Spech. Das HTML von Kommentar #9 ist ok so. Daran würde ich dann nix mehr schrauben. So bekommen blinde Nutzer den Hinweis zwar doppelt, aber können ihn immerhin eindeutig zuweisen, was sie vorher gar nicht konnten. Nicht perfekt, aber deutlich besser als vorher.

--- Originally created on December 9th, 2009, at 01:59pm

[NinaG]

Man könnte ergänzend die CSS3-Anweisung speak: none hinzuweisen. Die entspricht der angedachten Sache, ist allerdings (wie allgemein große Teile von CSS3) noch im Draft-Stadium. Das wäre eine nette Geste für moderne UAs, die das interpretieren und dann auch fachlich korrekt (im Gegensatz zum Einsatz des media-types speech, der für den Zweck gar nicht passt; hatte das vorhin anfangs falsch interpretiert).

http://www.w3.org/TR/css3-speech/#speak

--- Originally created on December 9th, 2009, at 06:35pm

[leofeyer]

Die Änderung ist leider auch im Frontend nicht problemlos umsetzbar, da bei allen *_grouped-Templates ebenfalls Fieldsets verwendet werden und somit auf jeden Fall das Stylesheet angepasst werden muss. Daher verschiebe ich das Ticket auf das nächste Minor-Release.

--- Originally created on December 16th, 2009, at 04:27pm

[NinaG]

Schade, aber solange es dann zumindest mit der 2.9 kommt und nicht ganz rausfliegt, ist es für mich ok :)

--- Originally created on December 16th, 2009, at 04:30pm

[leofeyer]

Es gibt leider noch ein Problem: Legends lassen sich nicht mittels der Klasse "invisible" ausblenden. Die einzige Möglichkeit wäre "display:none", was aber auch für den Screenreader bedeutet, dass das Element nicht existiert. Insofern lässt sich das so also gar nicht umsetzen :(

--- Originally created on December 16th, 2009, at 06:20pm

[NinaG]

Ich teste gerade Alternativen.

--- Originally created on December 16th, 2009, at 08:58pm

[NinaG]

Hab die Lösung. Das Problem tauchte nur im Firefox auf und ist dort ein leider schon lange bekannter Bug in der Engine. Die Lösung ist, dass man nicht dem legend die invisible-Klasse zuweist, sondern den Text darin mit einem span ummantelt und diesem die Klasse gibt.

<fieldset class="checkbox_fieldset">
<legend><span class="invisible">Unterlagen auswählen</span></legend>
<label class="lbl_18">Unterlagen auswählen</label> 
<div id="ctrl_18" class="checkbox_container">
<span><input type="checkbox" name="Funktionstest[]" id="opt_18_0" class="checkbox" value="Option A" /> <label id="lbl_18_0" for="opt_18_0">Option A</label></span>
<span><input type="checkbox" name="Funktionstest[]" id="opt_18_1" class="checkbox" value="Option B" /> <label id="lbl_18_1" for="opt_18_1">Option B</label></span>
<span><input type="checkbox" name="Funktionstest[]" id="opt_18_2" class="checkbox" value="Option C" /> <label id="lbl_18_2" for="opt_18_2">Option C</label></span>
</div>
</fieldset>

Zusätzlich habe ich noch diese Anweisung hinterlegt, damit es an der Stelle in keinem Browser einen unerwünschten Abstand durch die Legend gibt:

.checkbox_fieldset legend{height:0px;margin:0;padding:0;}

--- Originally created on December 16th, 2009, at 09:53pm

[leofeyer]

Dieser Workaround funktioniert, allerdings bin ich mit der Lösung wenig zufrieden, weil sie das eigentliche Problem mit der fehlenden Label-Zuordnung auch nicht löst.

<tr>
  <td>
    <label for="ctrl_1">Options</label>
  </td>
  <td>
    <div id="ctrl_1">
      <input type="checkbox" id="opt_1" … /> <label for="opt_1">Option 1</label>
      <input type="checkbox" id="opt_2" … /> <label for="opt_2">Option 2</label>
    </div>
  </td>
</tr>

Egal, ob nun ein Fieldset verwendet wird oder nicht, der Bezug zum Label "Options" fehlt und darum geht es doch eigentlich. Ein zusätzliches Fieldset um die Checkboxen hilft da nicht weiter.

--- Originally created on December 17th, 2009, at 12:46pm

[NinaG]

Ich glaube, du missverstehst da etwas. Das Label "Options" bleibt ja nur als Kompromiss erhalten, damit bisherige TL-Nutzer keinen Stress mit ihren Formularen bekommen. Inhaltlich gesehen ist es völlig überflüssig und war es in der Konstellation bei den Checkboxen/Radioboxen schon immer, da es schon bisher keinerlei echte Zuordnung (für blinde Nutzer) bewirkte.

Stattdessen gibt es in der benannten Lösung das Fieldset mit dem Legend "Options" das nun endlich eine Zuordnung zu den einzelnen Checkboxen bzw. Radioboxen herstellt.

--- Originally created on December 17th, 2009, at 01:06pm

[leofeyer]

Ich verstehe das sehr wohl, nur sehe ich keinen Vorteil darin, ein Fieldset umständlich einzubauen und wieder auszublenden, wenn das Problem der nicht zugeordneten Bezeichnung dadurch nicht gelöst wird und gleichzeitig doppelte Inhalte generiert werden. Da das Fieldset nicht verpflichtend ist, kann man es also genauso gut weglassen. Die einzelnen Checkboxen haben ja ein Label und sind somit barrierefrei.

Die neue Lösung ist nicht weniger fehlerhaft, als die bestehende. Die eine hat keine Gruppenüberschrift, die andere generiert doppelte Inhalte und benötigt umständliche CSS-Workarounds. Solange wir aber nur eine Krücke gegen die andere tauschen, steht es nicht dafür, allen bestehenden TYPOlight-Nutzern eine CSS-Anpassung aufzuzwingen.

--- Originally created on December 17th, 2009, at 01:57pm

[NinaG]

Doch, du verstehst es immer noch falsch: Für blinde Nutzer haben die einzelnen Checkboxen zueinander keine Verbindung. Es ist für sie nicht offensichtlich, dass diese gemeinsam zu einer Thematik gehören! Die jeweilige Checkbox zu ihrem Label: ja das ist klar. Aber die Checkboxen zueinander: vollkommen unklar. Und genau das löst das Fieldset mit der Legend. Dadurch wird ihnen klar zugewiesen (via Screenreader) dass diese Checkboxen zueinander gehören und welcher Thematik (Legend) sie zugewiesen sind. DAS ist die Verbesserung um die ich hier kämpfe.

Die "Dopplung" nehme ich nur in Kauf, weil du das unbedingt wegen der Altlasten haben willst. Für Blinde hat sie keinerlei Nutzen, aber ist aushaltbar, da sie durch das Fieldset eine deutliche Verbesserung zum bisherigen Status haben.

--- Originally created on December 17th, 2009, at 08:24pm

[NinaG]

Wird dieses wichtige Feature in der 2.9 umgesetzt?

--- Originally created on February 18th, 2010, at 12:01pm

[leofeyer]

Ein erster Entwurf für Radio-Button-Menüs ist in der c484ef93aaf2719c4c9c58453f560134 zu finden. Bitte überprüf das mal (z.B. im Backend -> Benutzer -> h.lewis -> Rechtevererbung) und sag mir Bescheid, ob das so funktioniert.

--- Originally created on April 15th, 2011, at 09:17pm

[NinaG]

Das mache ich gerne. Heute wird das nichts mehr, aber ich werde es mir dieses WE anschauen und auch versuchen von ein paar "echten" Screen Reader Nutzern eine Meinung dazu einzuholen.

--- Originally created on April 15th, 2011, at 09:21pm

[ghost]

Worauf ich letztens in der HTML5 Draft gestoßen bin: http://www.w3.org/TR/html5/Overview.html#the-label-element

Dort wird vorallem folgende syntax für label und input benutzt:

<label><input type="checkbox" name="lost"> Lost</label>

Es wird gesagt, dass man sich da sogar das for-Attribut sparen kann... Inwiefern das dann aber kompatibel mit älteren Browsern ist, kA. (Ich würd das for einfach mit setzen.) Für Mausbenutzer hat es den Vorteil, das der Klickbereich für ein Radiobutton/Checkbox ein konsistent zusammenhängender Bereich ist und nicht es ein Leerzeichen gibt, welches gar nichts macht.

--- Originally created by backbone on April 17th, 2011, at 03:00pm

[leofeyer]

Gibt es hierzu schon Feedback?

--- Originally created on April 27th, 2011, at 02:25pm

[NinaG]

Ach verdammt, vergiss meine Aussage. Ich hatte irrtümlich den 2.9er Branch ausgecheckt, nicht den 2.10er. Sorry, ich zieh mir gerade den richtigen und melde mich dann nochmal.

--- Originally created on April 28th, 2011, at 01:03pm

[NinaG]

So, jetzt habe ich mir das mal im richtigen SVN-Branch angesehen und kann sagen: Es sieht gut aus! :-)

--- Originally created on April 28th, 2011, at 01:13pm

[leofeyer]

Sieht es nur gut aus oder haben Deine Kontakte auch bestätigt, dass es funktioniert?

--- Originally created on April 29th, 2011, at 06:28pm

[leofeyer]

Die ad894cbefb70594bae5ee8b76ef7f096 enthält jetzt auch die barrierefreien Checkbox-Gruppen im Backend. Das Frontend wurde noch nicht angepasst.

--- Originally created on April 29th, 2011, at 07:34pm

[NinaG]

Es wurde mir bestätigt (habe den Code rauskopiert und gezeigt). Bei einem verschachtelten Fieldset wird an der Stelle natürlich nur die

vom inneren Fieldset (also nicht vom grünen, außeren Klapp-Legend) vorgelesen, aber das ist auch völlig in Ordnung so.

--- Originally created on May 3rd, 2011, at 12:08pm

[leofeyer]

Die fehlenden Frontend-Änderungen wurden in 596e8cb9d40412f2241c00150ac9d09c nun auch implementiert.

--- Originally created on May 26th, 2011, at 03:41pm

[leofeyer]

--- Originally completed on May 26th, 2011, at 03:41pm