RE: 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.



I would argue that this extra destination page is providing a conforming alternative version.



>    Strictly speaking WCAG Conformance criteria 2 requires the entire page be accessible,



Strictly speaking, WCAG requires that the original page *OR* the CAV be conformant.



>    Success Criteria 2.1.1 requires "all content is operable through a keyboard interface."



But all content (the submenu links) *are* operable through a keyboard interface.  Navigating from a top menu to a landing page that has the submenu links is about as fast as navigating a multi-level menu that is directly keyboard accessible, so I don't see a problem.



>    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.



I agree with you that it raises questions, but also that that there is precedence.  In addition to the longdesc comparison, this also reminds me of the discussion we had where we concluded that a text field was an acceptable (but not ideal) alternative to making a calendar widget directly accessible.



>    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?



I would like to see a survey question on this issue, but I personally will be arguing the latter position.  Thanks for raising this David!