RE: Javascript fallbacks for drop down menus

Thanks Bruce... my thinking is along the same lines. The niggly issue for me
is in Conformance Criteria 2. That the "entire page" must be accessible, and
traditionally I believe the group has interpreted that a Conforming
Alternative page, is a replacement for the entire page, rather than a widget
or part of the page. Conformance is based on a "web page" and a web page is
defined in the spec as a single URL.

 

http://www.w3.org/TR/2008/REC-WCAG20-20081211/#webpagedef 

 

To my knowledge, at least on the calls I've been on since 2002, we've never
really articulated a bright line on putting a conforming bit of
functionality at another URL ... (except longdesc of course). Maybe that's
for the better that we haven't made a statement on it ... because we
wouldn't want to see web sites forcing AT users to constantly bounce to
another page for conforming pieces of content, but on the other hand we
don't want to handcuff them to the URL of the original content because we'd
have no explanation for longdesc... etc...

 

I also appreciate Richard's comment about dropdown menus and magnifiers.
Just yesterday, a magnification user was showing me how difficult it was for
him to follow the flyouts on a drop down javscript menu...  but
interestingly, he did not feel comfortable going to the destination page of
the top menu item, to see the dropdown as regular links... he'd rather
wrestle with the menu.

 

We'd have to keep any advice avoid dropdowns as a best practice, I'd say...
because forbidding it, may be a bit too dogmatic and would represent a
change to our current WCAG.

 

Cheers

David MacDonald

 

CanAdapt Solutions Inc.

  "Enabling the Web"

 <http://www.can-adapt.com/> www.Can-Adapt.com

 

From: Bailey, Bruce [mailto:Bailey@Access-Board.gov] 
Sent: April-19-12 7:28 AM
To: David MacDonald
Cc: 'WCAG'
Subject: 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!