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

What I’m reading here is this would be an invalid code failure, which should be sufficient to indicate to folks that it’s a failure, regardless of the actual effects.


From: David MacDonald [mailto:david100@sympatico.ca]
Sent: Friday, June 27, 2014 10:00 AM
To: Hoffman, Allen
Cc: Sailesh Panchang; HTML A11Y TF Public; WCAG; Mark Sadecki
Subject: 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



CanAdapt Solutions Inc.

Tel:  613.235.4902

LinkedIn<http://www.linkedin.com/in/davidmacdonald100>

www.Can-Adapt.com<http://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<mailto: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<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<tel:613.235.4902>

LinkedIn<http://www.linkedin.com/in/davidmacdonald100>

www.Can-Adapt.com<http://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<mailto: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<mailto: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<tel:613.235.4902>
>
> LinkedIn <http://www.linkedin.com/in/davidmacdonald100>
>
> www.Can-Adapt.com<http://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<mailto: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]
>>
>