- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Tue, 8 Jul 2014 11:40:26 -0400
- To: David MacDonald <david100@sympatico.ca>, w3c-wai-gl@w3.org
David, >>Are you are saying the first one is good and the second one doewn't work as well for >>you? Please can you say how you came to this conclusion. Both methods work exscept for the exception noted after Example 1. All my emails say that one may be able to use either approach as long as they do not triggerone of the two SCs referred in the emails. Regards, Sailesh On 7/1/14, David MacDonald <david100@sympatico.ca> wrote: > Hi Shailesh > > Thanks for putting up an example of what you like... the link got a bit > mangled by the mail server... so here it is again for those who want to > click on it. > http://mars.dequecloud.com/demo/Form_RadioChoice.htm > > Are you are saying the first one is good and the second one doewn't work as > well for you? > > > > 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 Tue, Jul 1, 2014 at 2:49 PM, Sailesh Panchang > <sailesh.panchang@deque.com >> wrote: > >> 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 Tuesday, 8 July 2014 15:40:54 UTC