- From: David MacDonald <david100@sympatico.ca>
- Date: Fri, 27 Jun 2014 10:00:01 -0400
- To: "Hoffman, Allen" <allen.hoffman@hq.dhs.gov>
- CC: Sailesh Panchang <sailesh.panchang@deque.com>, HTML A11Y TF Public <public-html-a11y@w3.org>, WCAG <w3c-wai-gl@w3.org>, Mark Sadecki <mark@w3.org>
- Message-ID: <BLU436-SMTP1469DA87289B699F33FA2A3FE1B0@phx.gbl>
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] > >> > > > > >
Received on Friday, 27 June 2014 14:00:32 UTC