Re: HTML5.1 Should we forbid nesting form fields in radio groups

They could do it with an aria-label... but of course they usually, don't,
but I would still consider it a failure since it is not allowed in HTML to
provide anything that can have a label itself  as a child of a label.

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 8:03 AM, Hoffman, Allen <allen.hoffman@hq.dhs.gov>
wrote:

>  How is the label information exposed for assistive technology’s use for
> such nested fields?  If it isn’t than it only makes sense that this would
> be considered a failure, or invalid HTML.
>
>
>
>
>
> *From:* David MacDonald [mailto:david100@sympatico.ca]
> *Sent:* Thursday, June 26, 2014 5:26 PM
> *To:* Sailesh Panchang
> *Cc:* HTML A11Y TF Public; WCAG; Mark Sadecki
> *Subject:* Re: HTML5.1 Should we forbid nesting form fields in radio
> groups
>
>
>
> 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
>
>
>
> *CanAdapt* *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]
> >>
> >
>
>
>