Re: ARIA and HTML seem to conflict on nested forms in a label

Hi dave,

comments:

1, "I filed bugs on HTML next" please file a bug on the html5 spec.
2. I don't think the use of the term 'label 'in the ARIA spec section you
cited is the same as the HTML label element.

The HTML label element has established interoperably implemented
interaction behaviours that the conformance requirements in the HTML spec
stem from.

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>


On 27 June 2014 17:58, David MacDonald <david100@sympatico.ca> wrote:

> WAI ARIA Spec gives example of form field in a label, http://www.w3.org/TR/wai-aria/roles#textalternativecomputation
> under 2B
> "Authors sometimes embed a control within the label of another widget, where the user can adjust the embedded control's value. For example, consider a check box label that contains a text input field: "Flash the screen [input] times". If the user has entered "5" for the embedded text input, the complete label is "Flash the screen 5 times". For such cases, ....
>
> html5 says:http://www.w3.org/html/wg/drafts/html/CR/forms.html#the-label-element
> "Content model: Phrasing content, but with no descendant labelable elements unless it is the element's labeled control, and no descendant label elements"
>
> There appears to be a discrepancy between wai aria and html 5. Suggest investigation into them. One should change...
> Perhaps the wai aria doc can change it's text to... "Authors sometimes embed a control within the label of another widget, where the user can adjust the embedded control's value. <add>as an "willful violation" of HTML."</add>
>
> I filed bugs on HTML next and WAI ARIA, but thought I should post it for discussion.
>
> Cheers,
>
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902
>
> LinkedIn <http://www.linkedin.com/in/davidmacdonald100>
>
> www.Can-Adapt.com
>
>
>
> *  Adapting the web to all users*
> *            Including those with disabilities*
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
>
> On Fri, Jun 27, 2014 at 11:20 AM, Sailesh Panchang <
> sailesh.panchang@deque.com> wrote:
>
>> David,
>> Placing form controls with / without their  individual labels within a
>> label element may be alright in certain situations such as  referred
>> to in rule 2B of
>> http://www.w3.org/TR/wai-aria/roles#textalternativecomputation
>> In example 1 of your test page, clearly, the presence of the SELECT
>> causes a problem for tab order. Even if one selects radio#1, one can
>> still tab to the SELECT. This happens for all users (including
>> keyboard/and SR users).
>> The SELECT should not be operable if radio#1 is selected.
>> It is bad UI.
>>
>> Besides, the SELECT control does not have a label / title and fails SC
>> 4.1.2.
>> The SELECT  also fails W3C validation: Any select descendant of a
>> label element with a for attribute must have an ID value that matches
>> that for attribute.
>> In example #2, I do not see any reason for the start/end date fields
>> to be within the label for date range. As I said in my first email,
>> those fields should be disabled  and not in the tab order till that
>> radio is selected. Now it fails SC 2.4.3. And this impacts all users.
>> The example page does not validate right because of duplicate id too.
>>
>> Regards,
>> Sailesh Panchang
>>
>>
>> On 6/26/14, David MacDonald <david100@sympatico.ca> wrote:
>> > Thanks for the response. How will the screen reader know there is a
>> > dependent form control? When it is inside the label there is no
>> > announcement of the form control as the user arrows through the list, at
>> > least not in NVDA or JAWS and that is not allowed in html 5 anyway.
>> > http://www.w3.org/html/wg/drafts/html/CR/forms.html#the-label-element
>> > "Content model
>> > <
>> http://www.w3.org/html/wg/drafts/html/CR/dom.html#element-dfn-content-model
>> >
>> > :
>> > Phrasing content
>> > <http://www.w3.org/html/wg/drafts/html/CR/dom.html#phrasing-content-1>,
>> but
>> > with no descendant labelable elements
>> > <http://www.w3.org/html/wg/drafts/html/CR/forms.html#category-label>
>> unless
>> > it is the element's labeled control
>> > <http://www.w3.org/html/wg/drafts/html/CR/forms.html#labeled-control>,
>> and
>> > no descendant label
>> > <http://www.w3.org/html/wg/drafts/html/CR/forms.html#the-label-element>
>> > elements"
>> >
>> > If it is outside the label, but in the middle of the radio list. One
>> would
>> > have to know there in a form field in order to hit the tab to put focus
>> > there, even though you are half way through arrowing down the list. If
>> one
>> > leaves the list, and tab focus throws him back into into the dependent
>> > control that would be confusing, wouldn't it...
>> >
>> > My examples are here:
>> > http://davidmacd.com/test/form-field-nested-in-radio-list.html
>> >
>> > Cheers,
>> >
>> > David MacDonald
>> >
>> >
>> >
>> > *Can**Adapt* *Solutions Inc.*
>> >
>> > Tel:  613.235.4902
>> >
>> > LinkedIn <http://www.linkedin.com/in/davidmacdonald100>
>> >
>> > www.Can-Adapt.com
>> >
>> >
>> >
>> > *  Adapting the web to all users*
>> > *            Including those with disabilities*
>> >
>> > If you are not the intended recipient, please review our privacy policy
>> > <http://www.davidmacd.com/disclaimer.html>
>> >
>> >
>> > On Thu, Jun 26, 2014 at 4:33 PM, Sailesh Panchang <
>> > sailesh.panchang@deque.com> wrote:
>> >
>> >> Hello David,
>> >> Do you mean dependent form controls? i.e. Controls that are applicable
>> >> when a particular radio option is selected?
>> >> For instance, in that example, I suppose the start/end date text
>> >> fields only apply to date range radio. So those text fields should be
>> >> in the tab order only when that radio is selected.
>> >> At other times they should not be in the tab order or should be
>> >> disabled. Else it is a problem for all users and one could flag SC
>> >> 2.4.3.
>> >> In the backend, the text fields will be programmatically processed
>> >> only for that radio I expect.
>> >> Secondly, one should be able to arrow up/down the radiogroup (in forms
>> >> mode) automatically selecting the radio that is currently focussed
>> >> without triggering SD 3.2.1.
>> >> I mean it should not force one into the edit box via an onchange when
>> >> one is still reviewing radio choices and making up ones mind.
>> >> The dependent form controls should be the next tab stop  as one tabs
>> >> out of the radio group ...now one may place the dependent controls
>> >> after the radio group or right after the particular radio.
>> >> I too have seen such design not infrequently causing me to flag 2.4.3
>> >> or 3.2.1 when not done right.
>> >> Else, there's no problem and no reason for a general failure at all.
>> >> Regards,
>> >> Sailesh Panchang
>> >>
>> >>
>> >> On 6/26/14, David MacDonald <david100@sympatico.ca> wrote:
>> >> > I had an action item to articulate a discussion about 5.1 next
>> >> > regarding nesting form fields in radio groups.
>> >> >
>> >> > Recently during WCAG evaluations I've been finding quite a few radio
>> >> groups
>> >> > with nested form fields.
>> >> >
>> >> > I have a couple of mock up examples here
>> >> > http://davidmacd.com/test/form-field-nested-in-radio-list.html
>> >> >
>> >> >  It is very difficult for screen readers users to navigate this.
>> Let's
>> >> > assume developers don't want to place the nested elememt below the
>> >> > radio
>> >> > group either dynamically via show/hide (when the pertinent radio
>> button
>> >> is
>> >> > selected) or statically (always visible). Placing an aria-label on
>> the
>> >> drop
>> >> > down doesn't seem to help either.
>> >> >
>> >> > I'd argue it is a very bad UI design to do this and that it should be
>> >> > redesigned with the nested fields below the radio group.
>> Unfortunately,
>> >> > many devs seem to like it. Currently, I would fail it in WCAG. Do we
>> >> > need
>> >> > an explicit failure technique in WCAG or in the HTML 5.1 spec. Is
>> there
>> >> > something we can do using existing accessibility structures to fix it
>> >> > (create a positive technique), while keeping the layout.
>> >> >
>> >> > Cheers,
>> >> >
>> >> > David MacDonald
>> >> >
>> >> >
>> >> >
>> >> > *Can**Adapt* *Solutions Inc.*
>> >> >
>> >> > Tel:  613.235.4902
>> >> >
>> >> > LinkedIn <http://www.linkedin.com/in/davidmacdonald100>
>> >> >
>> >> > www.Can-Adapt.com
>> >> >
>> >> >
>> >> >
>> >> > *  Adapting the web to all users*
>> >> > *            Including those with disabilities*
>> >> >
>> >> > If you are not the intended recipient, please review our privacy
>> policy
>> >> > <http://www.davidmacd.com/disclaimer.html>
>> >> >
>> >> >
>> >> > On Thu, Jun 26, 2014 at 11:53 AM, Shane McCarron <shane@aptest.com>
>> >> wrote:
>> >> >
>> >> >> The minutes for the HTML Accessibility Task Force Teleconference 26
>> >> >> June
>> >> >> 2014 are available in HTML and plain text below:
>> >> >>
>> >> >> HTML:
>> >> >> http://www.w3.org/2014/06/26-html-a11y-minutes.html
>> >> >>
>> >> >> Text:
>> >> >>
>> >> >> W3C
>> >> >> - DRAFT -
>> >> >>
>> >> >> HTML Accessibility Task Force Teleconference
>> >> >>
>> >> >> 26 Jun 2014
>> >> >>
>> >> >> See also: IRC log
>> >> >>
>> >> >> Attendees
>> >> >>
>> >> >> Present
>> >> >> Mark_Sadecki, [IPcaller], Adrian_Roselli, paulc, David_MacDonald,
>> >> >> LWatson,
>> >> >> Cynthia_Shelly, McCarron, Judy
>> >> >> Regrets
>> >> >> Chair
>> >> >> Mark
>> >> >> Scribe
>> >> >> ShaneM
>> >> >> Contents
>> >> >>
>> >> >> Topics
>> >> >> Identify Scribe
>> >> >> Longdesc
>> >> >> Canvas Sub Group
>> >> >> WAI-ARIA in HTML
>> >> >> Media Sub Group
>> >> >> Bug Triage
>> >> >> HTML 5.1 Next Steps
>> >> >> Other Business
>> >> >> Summary of Action Items
>> >> >> <trackbot> Date: 26 June 2014
>> >> >> <MarkS> Meeting: HTML-A11Y Task Force Teleconference
>> >> >> <MarkS>
>> http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Scribe_List
>> >> >> Identify Scribe
>> >> >>
>> >> >> <MarkS> ShaneM, are you still interested in being our scribe today?
>> >> >> <scribe> ScribeNick: ShaneM
>> >> >> Longdesc
>> >> >>
>> >> >> MarkS: unfortunate series of events. just before close we discovered
>> >> >> there
>> >> >> was a bug with a comment left on it. a change was accepted and was
>> >> >> supposed
>> >> >> to be in the editors draft but was not.
>> >> >>
>> >> >> <MarkS> Extension of deadline for longdesc CfC
>> >> >> MarkS: upon further reflection we decided to only partially accept
>> the
>> >> >> change and implement it. This meant the CfC was extended to review
>> the
>> >> >> additional change.
>> >> >>
>> >> >> <MarkS> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24168
>> >> >> MarkS: CfC is open until tomorrow.
>> >> >>
>> >> >> Canvas Sub Group
>> >> >>
>> >> >> no meeting this week. still getting progress updates about fixing
>> >> >> hitregion support in chromium. should have a patch.
>> >> >>
>> >> >> scribe: last call comment period for the canvas 2d spec closes
>> today.
>> >> >> no
>> >> >> comments or new bugs filed.
>> >> >>
>> >> >> Actually last call period closed on 20 June. There were no bugs
>> >> >> reported
>> >> >> in that time.
>> >> >>
>> >> >> Next step is to get the editors to prep a draft CR and offer it up
>> to
>> >> the
>> >> >> chairs to get a CfC done.
>> >> >>
>> >> >> WAI-ARIA in HTML
>> >> >>
>> >> >> <MarkS> Using WAI-ARIA in HTML Working Draft published
>> >> >> MarkS: received consensus from TF and PF to publish a heartbeat
>> draft.
>> >> It
>> >> >> is live now.
>> >> >> ... announcement is not yet up.
>> >> >>
>> >> >> Media Sub Group
>> >> >>
>> >> >> MarkS: no meeting this week for the subgroup.
>> >> >> ... are working on drafting comment responses and preparing a new
>> >> >> heartbeat draft. Hope to have it out in two weeks (8 July or 10
>> July).
>> >> >>
>> >> >> Judy: whats up with tv?
>> >> >>
>> >> >> MarkS: they had a meeting recently. drafting up their uses cases for
>> >> >> round
>> >> >> 2. Once those are done the media subgroup will review the use cases
>> >> >> again.
>> >> >> ... sounds like they may have taken some of our use cases verbatim.
>> >> >>
>> >> >> Bug Triage
>> >> >>
>> >> >> LJWatson: met yesterday. all 5.0 bugs for a11y are completely
>> cleared.
>> >> >>
>> >> >> <LJWatson> https://www.w3.org/Bugs/Public/show_bug.cgi?id=13449
>> >> >> LJWatson: a handful of bugs have been reassigned to task force
>> members
>> >> >> for
>> >> >> tracking.
>> >> >>
>> >> >> <MarkS> 13449 Don't allow blank alt text on area elements
>> >> >> Chaals had offered to put together a test case, but is very busy.
>> Task
>> >> >> Force will relook at it to see if it is still an issue or if there
>> >> >> could
>> >> >> be
>> >> >> a test case prepared.
>> >> >>
>> >> >> aardrian: I can try to create a test case but have never done so
>> >> >> before.
>> >> >> Will take a little while. I am tied up for the next few days.
>> >> >>
>> >> >> Judy: no one should feel shy about volunteering. Everyone has to do
>> >> >> something for the first time.
>> >> >>
>> >> >> <LJWatson> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23027
>> >> >> aardrian: I will probably reach out to Mark as things progress.
>> >> >>
>> >> >> <MarkS> 23027 select and option should allow role overrides of menu
>> >> >> and
>> >> >> menuitem
>> >> >> MarkS: one of the reasons this was considered for 5.0 was that
>> during
>> >> the
>> >> >> PF closer look at the native aria semantics section the group
>> >> >> discovered
>> >> >> some omissions from that section.
>> >> >> ... this is another of those. If the others are being considered for
>> >> roll
>> >> >> into 5.0, then this should be as well.
>> >> >> ... will ping Steve about this bug.
>> >> >>
>> >> >> ShaneM: is there danger this wont make it into the spec?
>> >> >>
>> >> >> cyns: some people will not think this is editorial.
>> >> >>
>> >> >> paulc: task force should track this. The TF should ask for it if
>> that
>> >> >> is
>> >> >> what we want.
>> >> >>
>> >> >> <LJWatson> https://www.w3.org/Bugs/Public/show_bug.cgi?id=13572
>> >> >> <MarkS> 13572 4.10.19 aborting autofocus based on user choice not
>> >> >> optional
>> >> >> LJWatson: Is there anything relating to this in UAAG?
>> >> >>
>> >> >> cyns: I don't think so (not at a computer right now).
>> >> >> ... I don't think there are browser settings to override autofocus.
>> >> >> ... there might have been a feature request for this. If so, it
>> would
>> >> >> have
>> >> >> been a 5.1 feature request. It is not necessary for 5.0.
>> >> >> ... reassign to Cynthia
>> >> >>
>> >> >> MarkS: (someone) thinks that UAAG section 2.2.4 might apply -
>> separate
>> >> >> focus from selection. Could use that as an argument that user agents
>> >> >> should
>> >> >> have this feature.
>> >> >> ... I do think this is a valid bug for 5.1
>> >> >>
>> >> >> This has been moved out of the HTML component and into the HTML a11y
>> >> >> component. What is the process when it moves back?
>> >> >>
>> >> >> LJWatson: We have done that - but the assignee has been Steve so it
>> >> >> has
>> >> >> not been awkward.
>> >> >>
>> >> >> <MarkS> ACTION: cyns to add more information to
>> >> >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=13572 [recorded in
>> >> >> http://www.w3.org/2014/06/26-html-a11y-minutes.html#action01]
>> >> >> <trackbot> Created ACTION-274 - Add more information to
>> >> >> https://www.w3.org/bugs/public/show_bug.cgi?id=13572 [on Cynthia
>> >> Shelly -
>> >> >> due 2014-07-03].
>> >> >> HTML 5.1 Next Steps
>> >> >>
>> >> >> <MarkS> http://www.w3.org/WAI/PF/HTML/wiki/51wishlist
>> >> >> <paulc> Using WAI-ARIA in HTML publication: see
>> >> >> http://www.w3.org/blog/news/archives/3933
>> >> >> cyns: I do have an internal meeting scheduled about menus. When we
>> >> >> come
>> >> >> back on the 10th I should be able to talk about it.
>> >> >>
>> >> >> David: seeing radio buttons with sub groups with nested text boxes.
>> >> >> Confuses screen readers.
>> >> >>
>> >> >> cyns: if the text box is inside the label does that work?
>> >> >>
>> >> >> David: no. Then you have a nested label.
>> >> >>
>> >> >> cyns: we need to figure out the right A11Y pattern to support this -
>> >> >> it
>> >> >> is
>> >> >> widespread.
>> >> >>
>> >> >> MarkS: is there not a technique where you use enabled / disabled
>> >> >> manipulating the DOM? dynamically enable the additional form field?
>> >> >>
>> >> >> David: put the text field after the radio buttons and shift focus?
>> >> >>
>> >> >> cyns: there should be something we can do with labelling. This is a
>> >> >> sentence where a secondary control forms the end of the sentence.
>> >> >> ... it feels like there is a labelling solution but it is going to
>> be
>> >> >> complicated.
>> >> >>
>> >> >> MarkS: it sounds like more of a technique.
>> >> >>
>> >> >> David: we need to forbid it or design a way to do it accessibly.
>> >> >>
>> >> >> MarkS: there is no way to do it with ARIA?
>> >> >>
>> >> >> David: I have done a lot of experimenting and cannot come up with a
>> >> >> good
>> >> >> pattern.
>> >> >>
>> >> >> cyns: can you send the examples to the list?
>> >> >>
>> >> >> David: Sure - I need to clean them up a little bit. Next week.
>> >> >>
>> >> >> MarkS: Maybe there is a web components solution.
>> >> >>
>> >> >> David: it is not forbidden to put another form element inside a
>> label,
>> >> >> right?
>> >> >>
>> >> >> cyns: no. and forbidding it wouldn't work. people will do it anyway.
>> >> >>
>> >> >> David: the other thing we need to solve is placeholder text...
>> >> >> objection
>> >> >> is that the label disappears after someone starts typing.
>> >> >>
>> >> >> cyns: I think we can come up with something.
>> >> >>
>> >> >> MarkS: I think the placeholder text becomes an accessible
>> description,
>> >> >> but
>> >> >> users with cognitive issues may find it challenging that the text
>> >> >> disappears
>> >> >>
>> >> >> <paulc> See
>> >> >> http://lists.w3.org/Archives/Public/public-html/2014Jun/0055.html
>> for
>> >> >> info on "editing TF"
>> >> >> MarkS: moving the text into a tooltip might be a way.
>> >> >>
>> >> >> paulc: at the html f2f meeting in april was the contenteditable
>> >> >> feature
>> >> >> in
>> >> >> HTML. There was a feeling that some of that feature should be turned
>> >> into
>> >> >> an API instead of the mechanism that is in HTML5 today.
>> >> >> ... there is a task force about it.
>> >> >>
>> >> >> cyns: some overlap with that and IndieUI.
>> >> >>
>> >> >> MarkS: I was at the f2f and I did hear a lot of people discussing
>> >> >> contenteditable. The TF should keep an eye on this in 5.1. Thanks
>> for
>> >> >> bringing this to our attention.
>> >> >>
>> >> >> Other Business
>> >> >>
>> >> >> LJWatson: I can scribe next week.
>> >> >>
>> >> >> MarkS regrets for next week as I will be on vacation. paulc is at
>> >> >> risk.
>> >> >> cyns will be away on the 10th.
>> >> >>
>> >> >> Summary of Action Items
>> >> >>
>> >> >> [NEW] ACTION: cyns to add more information to
>> >> >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=13572 [recorded in
>> >> >> http://www.w3.org/2014/06/26-html-a11y-minutes.html#action01]
>> >> >>
>> >> >> [End of minutes]
>> >> >> Minutes formatted by David Booth's scribe.perl version 1.138 (CVS
>> log)
>> >> >> $Date: 2014-06-26 15:50:09 $
>> >> >> Scribe.perl diagnostic output
>> >> >>
>> >> >> [Delete this section before finalizing the minutes.]
>> >> >> This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11
>> >> >> Check for newer version at
>> >> >> http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
>> >> >>
>> >> >> Guessing input format: RRSAgent_Text_Format (score 1.00)
>> >> >>
>> >> >> Found ScribeNick: ShaneM
>> >> >> Inferring Scribes: ShaneM
>> >> >> Default Present: Mark_Sadecki, [IPcaller], Adrian_Roselli, paulc,
>> >> >> David_MacDonald, LWatson, Cynthia_Shelly, McCarron, Judy
>> >> >> Present: Mark_Sadecki [IPcaller] Adrian_Roselli paulc
>> David_MacDonald
>> >> >> LWatson Cynthia_Shelly McCarron Judy
>> >> >> Found Date: 26 Jun 2014
>> >> >> Guessing minutes URL:
>> >> http://www.w3.org/2014/06/26-html-a11y-minutes.html
>> >> >> People with action items: cyns
>> >> >>
>> >> >> [End of scribe.perl diagnostic output]
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>>
>>
>>
>