RE: Javascript fallbacks for drop down menus

Thanks for the feedback Sailesh...

Cheers
David MacDonald

CanAdapt Solutions Inc.
  "Enabling the Web"
www.Can-Adapt.com


-----Original Message-----
From: Sailesh Panchang [mailto:spanchang02@yahoo.com] 
Sent: April-20-12 11:42 AM
To: w3c-wai-gl@w3.org
Subject: RE: Javascript fallbacks for drop down menus

David,
1. About longdesc:
The 'longdesc' attribute was especially crafted to provide for needs of VI users. 
The URI it links to pretty much contains a detailed description of the image. That's it.
Only AT used by VI users can get to it.
Now it is a different matter that  the accessibility community believes that the description can help other users too and the content should be available to a wider audience.
So arguments are going around and new techniques are being proposed (ARIA, HTML5, etc.).
Then these new methods were neither in existence nor did user agents support them and the best alternative was the d-link ... remember? 
I do not think longdesc is an exception for the conformance rule and is fine for the purpose it was designed.
Well if goals are being redefined, then perhaps new techniques too can be designed.  
Oh and by the way, if the page already contains enough details (in text or a table etc.) for a complex graph image, then no longdesc is required.
So longdesc is simply one of the  techniques to make such graphs accessible. And a technique is not 'required' I am always reminded. 
2. About the mouseover menus:
I too strongly  object to activating the top menu link to go to a complete different page and wading around in the content there.
The linked page from the top menu link is not provided simply for accessibility like the page linked to from longdesc but is a regular page.
Note, some menus display brief non-linked text content too besides links when moused over.
And one cannot wish the menus away.
While VI users cannot even perceive  this functionality and content, sighted keyboard-users too just cannot get to them if they are able to determine that there is such functionality.
I have other objections too but I'll hold them for now.
So I have never passed these based on the argument one can click the top link to get to a different page ... for S508 or WCAG reviews. 

And there are good implementations that work:
- convey that the UI element is a menu (at least for AT users, but with a little more effort, to all users)
- one can navigate through top menu items by tabbing (or sometimes by arrow keys)
- one can operate the down arrow to open[if it does not open on focus] / navigate through submenu links and also determine when it ends

And this can be done with HTML, JS and CSS pretty much.
Some ARIA too can be used if user base is not likely to be using older user agents.
Check bankofamerica.com (bank, borrow, invest, etc.  menus) ... it works for VI - AT users and keyboard users  I believe fairly well. Maybe has scope for a few improvements. 
I used to see one on mozilla.org too till early last year ... not there now.
So if one uses such menus, one should insist they should be coded in a manner that they are accessible to all.
 Sailesh Panchang
Deque Systems

--- On Thu, 4/19/12, David MacDonald <david100@sympatico.ca> wrote:


From: David MacDonald <david100@sympatico.ca>
Subject: RE: Javascript fallbacks for drop down menus
To: "'Bailey, Bruce'" <Bailey@Access-Board.gov>
Cc: "'WCAG'" <w3c-wai-gl@w3.org>
Date: Thursday, April 19, 2012, 8:29 AM







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"
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!

Received on Sunday, 29 April 2012 01:31:25 UTC