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

Hello David,
Here is an example of radio buttons with dependent controls placed
within / after radiogroup. This is on the lines of your example #2.
They pose no problem  usability / accessibility wise except  as noted
after form #1.

http://mars.dequecloud.com/demo/Form_RadioChoice.htmThanks,
Sailesh





On 6/27/14, 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]
>>> >>
>>> >
>>>
>>>
>>
>

Received on Monday, 7 July 2014 13:44:25 UTC