Re: [WSG] So this is *the* good accessible keyboard supported dropdown menu?
Hi Steve, > The linked example provided by tee i belive was taken from here: > http://www.html5accessibility.com/index-aria.html Yes, indeed I found the aegisdemo from your site . Sorry if a credit of the source is expected and I neglected it. I thought it was a reference of html5accessibility. > the example: http://hanshillen.github.com/aegisdemo/ is provided as an > alternative to the HTML5 menu control. > > The HTML5 menu control has not been implemented yet, but will almost > certainly have the same or similar behaviour on each browser and interaction > keystrokes will be same or similar to platforms standards for menu controls. > The example uses standard interaction keystrokes for menu controls, it also > exposes the correct semantics roles/states/properties for a menu widget, much > like the menu control in HTML5 will when implemented. Thanks for the explanation! When I think of drop-down menu, my instant reaction is, it's a collection of navigational elements for a web page, or an application. I am pretty sure this is how most people think whether they are web developers or website users. That being said, I actually had just looking up the HTML5 menu element the day before I learned about the html5accessibility which I found from "Some links for light reading " from Russ's email. HTML5 Specs define Nav element as a section of a page that links to other pages or to parts within the page: a section with navigation links whereas the menu represents a list of commands. and belongs to "Interactive elements". ARIA defines 'menu' as a type of widget that offers a list of choices to the user, and 'menubar' as a presentation of menu that usually remains visible and is usually presented horizontally., and 'navigation' as a collection of navigational elements (usually links) for navigating the document or related documents. Dropdown menu in this regard fits nicely to the Nav (for HTML5) and Navigation (ARIA) elements. Not seeking an answer from you or anybody here, as I am just thinking out loud in attempt to articulate my thought on many things about HTML5 and Accessibility, but feel free to elaborate on this topic or point out any flaw of my thought. Having said that, Dropdown menu does not appear to be "a list of commands" whether it be an application or a (conventional) website (that consists of HTML markups and hyperlinks). I get that HTML5 provides a new meaning for structure and semantics and can/will help users who rely on AT and improve the accessibility in many areas without the extended help from AT, and we as web developers will have to abandon some old habits, to adapt/learn the new approach so to take advantage of what HTML5 brings; regardlessly the end result is to provide a more usable and accessible site to end users regardless of their disability with the minimum or no extended help from AT for larger audiences. Yet in terms of accessibility, there are fundamental aspects that shall never required users to learn new trick or abandon the convention (I call it common sense) whether a site is built on HTML5 or HTML6 30 years later (ok, with the way the technology advancing, maybe not); whatever enhancement/improvement the new technology brings, should based upon the principle and fundamental aspect, not cut it off and ask the user to learn the new in order to keep using the 'old' . If the dropdown menu is strictly defined, or well-recongnized as Nav/Navigation based on HTML5 and ARIA specs, the menubar example behaves like cutting off the old (good way), forces user to to learn the new in order to keep using the 'old'. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] So this is *the* good accessible keyboard supported dropdown menu?
> On Behalf Of Al Sparber
>
> From: "Thierry Koblentz"
> > What is the solution you're talking about?
> > That link you posted does not tell us much about your "own
> simplistic,
> > unsophisticated way", nor what is your "different view of menu
> > Accessibility".
>
> It must be so simple it went over your head :-)
ok, you made me curious so I read the whole thing.
I didn't find a live example to test and I'm not sure that page uses the
same menu structure as the one you discuss (since you have sub menus
double-wrapped in DIVs after the UL rather than nested in the top level
items like your markup example shows). But to *me*, this is a bad approach
regarding performance, usability, and maintenance (I may forget something).
1. the use of descendant selectors (going through *8* elements here):
.p7PMMnoscript li li li li li li:hover div {}
2. the "screen-reader link" that says: "Jump to Main Menu and expand all of
its hidden submenu items. Once expanded you can tab through all links or
open your screen reader's link list." Keyboard users should not have to go
through all menu items to navigate a site.
3. creating "fallback" pages that authors may fail to see as "landing pages"
As a side note, I'd be interested to check a live example as I am wondering
how you expose that "screen reader" link to keyboard users who do not rely
on a assistive device.
> Perhaps someone else would be interested in engaging in a debate or
> raising other accessibility solutions - but mine was a one-way
> post and I am only replying to you to clarify that.
Same here, I'm only replying to you because you suggested I didn't
understand your "solution".
Have a great day
--
Regards,
Thierry
www.tjkdesign.com | www.ez-css.org | @thierrykoblentz
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] So this is *the* good accessible keyboard supported dropdown menu?
Hi all The linked example provided by tee i belive was taken from here: http://www.html5accessibility.com/index-aria.html the example: http://hanshillen.github.com/aegisdemo/ is provided as an alternative to the HTML5 menu control. The HTML5 menu control has not been implemented yet, but will almost certainly have the same or similar behaviour on each browser and interaction keystrokes will be same or similar to platforms standards for menu controls. The example uses standard interaction keystrokes for menu controls, it also exposes the correct semantics roles/states/properties for a menu widget, much like the menu control in HTML5 will when implemented. regards Stevef On 15 October 2010 03:09, Al Sparber wrote: > From: "tee" > > At Menubar, try tab through the link using your keyboard, right after you >> hit "File", the next link it headed is the download link below the Source. >> >> http://hanshillen.github.com/aegisdemo/ >> >> As a Superfish script and a frequent keyboard navigation user, I expect >> the second tabbing destination to be the "Edit" menu because of many >> comments and articles I read which were written by accessibility >> practitioners and those who never missed the opportunity to stone Superfish >> every time they see a chance. >> >> I was a bit lost when I didn't see the orange focus color for "Edit" after >> I tabbed through the "File"; first I thought it behaves like Superfish >> (which heads for 2nd level). Then I realized I must use the 'right arrow' to >> navigate to "Edit", is this the absolute way for keyboard user to expect >> that a an accessible keyboard supported dropdown menu will only work like >> this using arrow keys? >> > > Probably. I think there is a faction in the accessibility community that > believes a web page menu should work like a desktop application or OS menu. > The problem is that web surfing civilians who use the keyboard are > accustomed to the tab key (or equiv) and not the arrow keys for navigating a > web page. Complicating the matter now, of course, are smart phones. In our > own simplistic, unsophisticated way, we've taken a much different view of > menu accessibility. While most experienced standards and accessibility > experts seem to disagree with us, our testing lab, consisting of real people > with real disabilities, seems to think it makes sense. > > > http://www.projectseven.com/products/menusystems/pmm2/ug-examples/accessible/ > > I'm sure some here will disagree, so just consider it one possible > solution. > > -- > Al Sparber - PVII > http://www.projectseven.com > Dreamweaver Menus | Galleries | Widgets > http://www.projectseven.com/go/hgm > The Ultimate Web 2.0 Carousel > > > > > > > *** > List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm > Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm > Help: memberh...@webstandardsgroup.org > *** > > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] So this is *the* good accessible keyboard supported dropdown menu?
> On Behalf Of Al Sparber > > From: "Thierry Koblentz" > > What is the solution you're talking about? > > That link you posted does not tell us much about your "own > simplistic, > > unsophisticated way", nor what is your "different view of menu > > Accessibility". > > It must be so simple it went over your head :-) My apologies for trying to make sense of your post. -- Regards, Thierry www.tjkdesign.com | www.ez-css.org | @thierrykoblentz *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] So this is *the* good accessible keyboard supported dropdown menu?
From: "Thierry Koblentz" What is the solution you're talking about? That link you posted does not tell us much about your "own simplistic, unsophisticated way", nor what is your "different view of menu Accessibility". It must be so simple it went over your head :-) I'm not here to argue, debate, or press my views. Consider my post a statement about a system that works for us and our customers. Perhaps someone else would be interested in engaging in a debate or raising other accessibility solutions - but mine was a one-way post and I am only replying to you to clarify that. Ours works for us and for our testers - and that's all that matters to us. Read it and understand or simply present or use another solution. Cheers and adios. -- Al Sparber - PVII http://www.projectseven.com Dreamweaver Menus | Galleries | Widgets http://www.projectseven.com/go/hgm The Ultimate Web 2.0 Carousel *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] So this is *the* good accessible keyboard supported dropdown menu?
> Probably. I think there is a faction in the accessibility community > that believes a web page menu should work like a desktop > application or OS menu. The problem is that web surfing civilians who > use the keyboard are accustomed to the tab key (or equiv) and > not the arrow keys for navigating a web page. Complicating the matter > now, of course, are smart phones. In our own simplistic, > unsophisticated way, we've taken a much different view of menu > accessibility. While most experienced standards and accessibility > experts seem to disagree with us, our testing lab, consisting of real > people with real disabilities, seems to think it makes sense. > > I'm sure some here will disagree, so just consider it one possible > solution. What is the solution you're talking about? That link you posted does not tell us much about your "own simplistic, unsophisticated way", nor what is your "different view of menu Accessibility". -- Regards, Thierry www.tjkdesign.com | www.ez-css.org | @thierrykoblentz *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] So this is *the* good accessible keyboard supported dropdown menu?
From: "tee" At Menubar, try tab through the link using your keyboard, right after you hit "File", the next link it headed is the download link below the Source. http://hanshillen.github.com/aegisdemo/ As a Superfish script and a frequent keyboard navigation user, I expect the second tabbing destination to be the "Edit" menu because of many comments and articles I read which were written by accessibility practitioners and those who never missed the opportunity to stone Superfish every time they see a chance. I was a bit lost when I didn't see the orange focus color for "Edit" after I tabbed through the "File"; first I thought it behaves like Superfish (which heads for 2nd level). Then I realized I must use the 'right arrow' to navigate to "Edit", is this the absolute way for keyboard user to expect that a an accessible keyboard supported dropdown menu will only work like this using arrow keys? Probably. I think there is a faction in the accessibility community that believes a web page menu should work like a desktop application or OS menu. The problem is that web surfing civilians who use the keyboard are accustomed to the tab key (or equiv) and not the arrow keys for navigating a web page. Complicating the matter now, of course, are smart phones. In our own simplistic, unsophisticated way, we've taken a much different view of menu accessibility. While most experienced standards and accessibility experts seem to disagree with us, our testing lab, consisting of real people with real disabilities, seems to think it makes sense. http://www.projectseven.com/products/menusystems/pmm2/ug-examples/accessible/ I'm sure some here will disagree, so just consider it one possible solution. -- Al Sparber - PVII http://www.projectseven.com Dreamweaver Menus | Galleries | Widgets http://www.projectseven.com/go/hgm The Ultimate Web 2.0 Carousel *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
