Javascript fallbacks for drop down menus

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 Wednesday, 18 April 2012 21:13:28 UTC