accessibility issues with select widget

73 views
Skip to first unread message

Jean-Pierre Rivière

unread,
Apr 21, 2021, 6:04:34 AM4/21/21
to TiddlyWiki
As far as WCAG 2.1 is concerned, a "select" elements should better have an "id" tag in order that a "label" element could point to it witg its "for" tag. Alternatives are a "title" tag or WAI-ARIA roles for the "select" element.

Alas, none of this is possible with the current "select" widget.

The "button" widget can have aria labels but sill cannot get an "id" tag.

Neither can have a "name" tag which can also be helpful in this respect (as a poor man's workaround).

I think it would be time to address this a11y issues that prevents to make a fully accessible document or site with tiddlywiki.

I propose to help in this endeavour in listing the accessibility problems with forms  widgets. And propose some fixes (if I'm successfull).

My interest in the quest: I am using tiddliwiki to build a tool for recording scores and minutes at accessibility tests for web sites. It would also be better if the tool was as WCAG compliant as it could be.

Regards.

-- 
Jean-Pierre

Jeremy Ruston

unread,
Apr 21, 2021, 4:27:39 PM4/21/21
to tiddl...@googlegroups.com
Hi Jean-Pierre

Using HTML IDs is awkward in TiddlyWiki because of the way that fragments of HTML can be displayed more than once. But it is also possible to nest the select element inside the label element:


For example:

<label>
This is the label
<$select tiddler=<<qualify 'select-demo'>> default='HelloThere'>
<$list filter='[all[shadows+tiddlers]tags[]sort[title]]'>
<option value=<<currentTiddler>>><$view field='title'/></option>
</$list>
</$select>
</label>

Best wishes

Jeremy


On 21 Apr 2021, at 11:04, Jean-Pierre Rivière <jn.pierr...@gmail.com> wrote:

As far as WCAG 2.1 is concerned, a "select" elements should better have an "id" tag in order that a "label" element could point to it witg its "for" tag. Alternatives are a "title" tag or WAI-ARIA roles for the "select" element.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/ed0a3873-8007-4e15-932d-b99811308884n%40googlegroups.com.

Jean-Pierre Rivière

unread,
Apr 23, 2021, 11:14:13 AM4/23/21
to TiddlyWiki
Hi Jeremy. Thank you for your reply. I do appreciate it.

Your tw code renders an html code like

<label>This is my label<select><option value="one">one</option><option (...) </option></select></label>

This fails https://www.w3.org/WAI/WCAG21/Techniques/html/H44 because of lack of "id" tag.

https://www.w3.org/WAI/WCAG21/Techniques/html/H65 provides an alternative with the "title" tag but neither edit-text widget nor button widget provide a way to get a title tag. This solution would be a little out of touch (aka not very acceptable) if you provide a label element that fails only because of a lack of "id" tag.

on the contrary we are clearly within the wrong as shown in https://www.w3.org/WAI/WCAG21/Techniques/failures/F68

If we can't get WCAG conformity witg tiddlywiki, this mean the law will forbid any application in tw technology to be used as a web app for any major public (the public, corporate app, etc). This would really be a shame.

Is there really no way to properly handle id tags? Could we imagine a blue sky effort to imagine potential solutions? Where and how could interested parties be technically briefed and reports their own works about it afterwards?

regards.

-- 
Jean-Pierre

Jeremy Ruston

unread,
Apr 23, 2021, 11:27:40 AM4/23/21
to tiddl...@googlegroups.com
Hi Jean-Pierre

Your tw code renders an html code like

<label>This is my label<select><option value="one">one</option><option (...) </option></select></label>

This fails https://www.w3.org/WAI/WCAG21/Techniques/html/H44 because of lack of "id" tag.

https://www.w3.org/WAI/WCAG21/Techniques/html/H65 provides an alternative with the "title" tag but neither edit-text widget nor button widget provide a way to get a title tag. This solution would be a little out of touch (aka not very acceptable) if you provide a label element that fails only because of a lack of "id" tag.

on the contrary we are clearly within the wrong as shown in https://www.w3.org/WAI/WCAG21/Techniques/failures/F68

It’s very frustrating. My reading of the HTML spec is that the select element can be nested inside the label element instead of using the “for” attribute. There’s even an example in the spec:


Sometimes, a user has to select one or more items. This example shows such an interface.

<label>
 Select the songs from that you would like on your Act II Mix Tape:
 <select multiple required name="act2">
  <option value="s1">It Sucks to Be Me (Reprise)
  <option value="s2">There is Life Outside Your Apartment
  <option value="s3">The More You Ruv Someone
  <option value="s4">Schadenfreude
  <option value="s5">I Wish I Could Go Back to College
  <option value="s6">The Money Song
  <option value="s7">School for Monsters
  <option value="s8">The Money Song (Reprise)
  <option value="s9">There's a Fine, Fine Line (Reprise)
  <option value="s10">What Do You Do With a B.A. in English? (Reprise)
  <option value="s11">For Now
 </select>
</label>


If we can't get WCAG conformity witg tiddlywiki, this mean the law will forbid any application in tw technology to be used as a web app for any major public (the public, corporate app, etc). This would really be a shame.

I agree that WCAG conformity is essential, but in this case it appears to be a piece of bureaucracy divorced from both the HTML spec and browser implementations.

Is there really no way to properly handle id tags? Could we imagine a blue sky effort to imagine potential solutions? Where and how could interested parties be technically briefed and reports their own works about it afterwards?

We would need to use the “qualify” technique that we use to generate state tiddler titles. It would be hard to make things work without burdening authors with additional complexity.

Best wishes

Jeremy

Jean-Pierre Rivière

unread,
Apr 23, 2021, 1:23:07 PM4/23/21
to TiddlyWiki

The html spec is one thing. Taking into account what the currently available assistive technologies do is an other. I have not tested that for myself, but maybe they can associate things with id and not with an inclusion into the label element. If that inclusion is not very common, the assistive software may ignore that entirely. And the id way is clearly the way expressed when you look for howtos.

And the reality is also that the law is a bureaucratic process. We may wish whatever we want but we have to make do.


As for the tech soecs, I read them as you do. I quote https://html.spec.whatwg.org/multipage/forms.html#the-label-element

« The for attribute may be specified to indicate a form control with which the caption is to be associated. If the attribute is specified, the attribute's value must be the ID of a labelable element in the same tree as the label element. If the attribute is specified and there is an element in the tree whose ID is equal to the value of the for attribute, and the first such element in tree order is a labelable element, then that element is the label element's labeled control.

If the for attribute is not specified, but the label element has a labelable element descendant, then the first such descendant in tree order is the label element's labeled control. »

As for what a labelable element is, I quote https://html.spec.whatwg.org/multipage/forms.html#category-label

« Some elements, not all of them form-associated, are categorized as labelable elements. These are elements that can be associated with a label element.

Time for contacting WCAG. An uphill battle awaits the intrepidous developper!
Reply all
Reply to author
Forward
0 new messages