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

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

Received on Friday, 27 June 2014 15:43:15 UTC