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

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]
> >> >>
> >> >
> >>
> >>
> >
>
>
>
>