W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2012

Re: Javascript fallbacks for drop down menus

From: Gregg Vanderheiden <gv@trace.wisc.edu>
Date: Wed, 18 Apr 2012 22:17:29 -0500
To: David MacDonald <david100@sympatico.ca>
Cc: 'WCAG' <w3c-wai-gl@w3.org>, 'Loretta Guarino Reid' <lorettaguarino@google.com>, 'Joshue O Connor' <joshue.oconnor@cfit.ie>, 'John Foliot' <john@foliot.ca>, 'Cynthia Shelly' <cyns@microsoft.com>, 'Richard Schwerdtfeger' <schwer@us.ibm.com>, 'James Nurthen' <james.nurthen@oracle.com>, 'Janina Sajka' <janina@rednote.net>
Message-id: <7B3106A6-BEB6-4E38-BA74-A2F2389893E0@trace.wisc.edu>

	I see what you are getting at. 

	But Longdesc is a viable technique and puts the alternate form of information in a graph on another page - linked to from the first page. 
	If we adopt that strict approach then longdesc was always a violation.   

	So having the menu on another page would not (to me) look like it was totally unprecedented.  	



On Apr 18, 2012, at 4:12 PM, David MacDonald wrote:

> Wondering about other's opinions on fallbacks for inaccessible Javascript
> drop down menus, where the top of the menu is a normal link, but the
> dropdown items below them are not accessible. However, all the links in the
> dropdown are repeated as normal links on the destination page. 
> Strictly speaking WCAG Conformance criteria 2 requires the entire page be
> accessible, 
> http://www.w3.org/TR/WCAG/#conformance-reqs
> Success Criteria 2.1.1 requires "all content is operable through a keyboard
> interface."
> So placing fallbacks for specific widgets at a separate URL raises
> questions. It appears we have not addressed this type of fallback explicitly
> in WCAG ... But of course Longdesc provides an alternative for the image on
> another page and in that respect is a precedent for providing a fallback at
> a separate URL ... in WCAG we didn't say longdesc is an exception. So I'm
> torn on the Javascript dropdown fallback.
> Do we fail these dropdowns (which have a fallback at other URL) and require
> them to make the dropdown accessible (which is now possible)? Or do would we
> say it's sufficient alternative?
> Cheers
> David MacDonald
> CanAdapt Solutions Inc.
>  "Enabling the Web"
> www.Can-Adapt.com 
> -----Original Message-----
> From: Janina Sajka [mailto:janina@rednote.net] 
> Sent: April-18-12 4:27 PM
> To: Laura Carlson
> Cc: Joshue O Connor; John Foliot; Cynthia Shelly; Judy Brewer;
> david100@sympatico.ca; Richard Schwerdtfeger; James Nurthen; Leif Halvard
> Silli
> Subject: Re: WAIT, hang on... (was RE: Revised Issue-204 Draft from Cynthia)
> Hi, Laura:
> I think we're now crossing emails as we actively look at this. I've just
> sent an email that addresses much of what you say here, so I won't repeat
> that other than to suggest that your points #3 and #4, while absolutely
> important and correct, are really I-30 points, and not necessarily I-204
> points.
> We have previously complained, all of use have variously complained to the
> HTML Chairs that they only complicated and postponed the resolution of I-30
> when they created I-204. While they were wrong to do that, we need to be
> particularly careful to stay on topic, lest we lose out for out of scope
> argument.
> But, please see my other email.
> Janina
> Laura Carlson writes:
>> Hi Janina,
>>> Also, you should know that PF spent the entire weekly telecon 
>>> perfecting Cynthia's CP today. There may be more tweaks this 
>>> afternoon, so please refresh.
>> I have reread Cynthia's CP. The main point is lost in the added 
>> verbiage from Matt T's proposal and UAIG.
>> I recommend:
>> 1. Removing Matt T's use case text. He has already said it in his own 
>> proposal. No point in repeating it.
>> 2. Moving the UAIG info to a sub-page as I did or just link to the page I
> made.
>> http://www.w3.org/html/wg/wiki/ChangeProposals/CorrectHidden/UAIG
>> Sub-pages were great for focusing the longdesc CP. If there are other 
>> sub-points they can be linked to too.
>> 3. Emphasizing repercussions in the spec text.  Flat out say:
>> "This technique should not be used for longer descriptions that have 
>> structured text (e.g., headings, anchors, list markup, table markup, 
>> etc.), as rich text is stripped to string text, resulting in all 
>> semantic structure being lost."
>> 4. Emphasizing repercussions in the risks section. Flat out say:
>> "It will lead to a very poor user experience if this technique is used  
>> for longer descriptions, as reading keys will not work. Users will not 
>> be able to interact with the content. All links will be dead."
>> In short clear out the baggage. And don't sweep number 3 and 4 under 
>> the rug. For everyone's sake keep 3 and 4 prominent.
>> These changes would be consistent with my CP.
>> Thanks.
>> Best Regards,
>> Laura
> -- 
> Janina Sajka,	Phone:	+1.443.300.2200
> 		sip:janina@asterisk.rednote.net
> Chair, Open Accessibility	janina@a11y.org	
> Linux Foundation		http://a11y.org
> Chair, Protocols & Formats
> Web Accessibility Initiative	http://www.w3.org/wai/pf
> World Wide Web Consortium (W3C)
Received on Thursday, 19 April 2012 03:18:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:34:09 UTC