- From: Schnabel, Stefan <stefan.schnabel@sap.com>
- Date: Wed, 15 Dec 2010 14:27:34 +0100
- To: Hans Hillen <hans.hillen@gmail.com>
- CC: Steve Faulkner <faulkner.steve@gmail.com>, W3C WAI-XTECH <wai-xtech@w3.org>
Hi Hans, ok. For the sake of completeness, I'd like to add that there are methods/ API's available to EXTEND the default Browser Context Menu (and it will still open with Shift + F10). So, not always a custom context menu is needed. But AFIK all these methods require local additional browser/os environment mods (please correct me if I'm wrong). See e.g. - IE: http://msdn.microsoft.com/en-us/library/aa753589%28v=VS.85%29.aspx, http://blogs.msdn.com/b/oldnewthing/archive/2004/05/24/140283.aspx - respective Firefox-Extensions, e.g. https://jetpack.mozillalabs.com/, https://addons.mozilla.org/de/firefox/addon/4554/ The reason why CUSTOM context menus came into attention are therefore a) You cannot currently use JS to add entries to a default browser context menu without a modded client environment b) not many HTML elements (especially custom) support a browser context menu c) The product team wants some extended functionality not covered by default browser context menus .. d) The visual department wants some additional styling .. And in real web apps, mostly all of above applies :) .. I'm sure you can easily extend the list. Regarding the future and HTML 5: Well, we have now http://dev.w3.org/html5/spec/interactive-elements.html#context-menus. I suppose the invocation key combination will be also Shift + F10 .. Hopefully ... I'm looking forward to first support in Browsers, seems not to be there yet (http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28HTML5%29) do you know about it yet? Meanwhile we can refer e.g. to http://www.html5accessibility.com/index-aria.html. Best Regards Stefan -----Original Message----- From: Hans Hillen [mailto:hans.hillen@gmail.com] Sent: Mittwoch, 15. Dezember 2010 13:09 To: Schnabel, Stefan Cc: Steve Faulkner; W3C WAI-XTECH Subject: Re: indicating a context menu Hi Stefan, Yes, all of this relates to custom context menus. Generic browser generated context menus are common, but they only contain low level options applicable to the browser, web page or html element (such as "copy", "open in new window", "view page source", etc.). They don't have high level options specifically applicable to a web application (e.g. options like "move to inbox", "mark as unread", "move to cart", "change contact properties"). Custom context menus are especially important to screen reader users (as well as other keyboard users) because they often provide alternative access to mouse based actions (e.g. dragging an item in a treeview or resizing a dialog window). So a screen reader user would generally know the shift + 10 shortcut (or equivalent method provided by the assistive technology) can be used to trigger a context menu, but not that this will be a special, custom menu instead of the the standard browser options. Since custom context menus are not THAT common, you can't expect users to trigger a context menu on every element just to see if the developer implemented a custom one here. Hence my remark of the custom menu likely to go unnoticed by the screen reader user. I don't have any statistics to back up that assumption, but perhaps screen reader users on this list can share their opinion. I definitely agree with you that browser generated context menus are a user agent matter, not an ARIA one. Regards, Hans Hillen On Dec 15, 2010, at 9:20 AM, Schnabel, Stefan wrote: > Hi Hans, > > thanks a lot for clarification. > >>>> Most screen reader users will not know they can try out Shift + F10 to find out relevant options through the context menu. > > Well, I think you mean "... find out relevant options through the CUSTOM context menu.", right? > And to indicate CUSTOM context menu you propose a "aria-hascontext" property, right? > > It was new to me that "Most screen reader users will not know Shift + F10 to open (browser) context menu". Is it so? Are there statistics about that? You know I want to avoid a situation where design proposals are made based on personal opinions (we have this too often). Understand me right, I don't doubt your statement, just want to have some broader ack on this. > > But if so, I stil feel for browser-provided context menus still the UA-AT interoperability should take care. > > For custom context menus like in > > <span role="link" aria-hascontext="true"> > > would come in handy (more typed) > > and > > <span role="button" aria-haspopup="true"> > <span role="textbox" aria-haspopup="true"> > <input type="text" aria-haspopup="true"> > > could then be denoted e.g. to indicate an associated a DIALOG-like tooltip or a input helper dialog (e.g. date picker) that will be opened when the respective action is executed. > > For > > <input role="combo"> > > aria-hascontext="true" canbe ommitted but > > <input role="combo" aria-haspopup="true"> > > would be an option to indicate an associated a DIALOG as described above. > > Opinions? > > Bonus Question: > > How to make clear the relationship between the two individual buttons of combo button element in > http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_Button.html ? > (It is ONE single element). Is there a good pattern for such cases? > > > Best Regards > Stefan > > > -----Original Message----- > From: Hans Hillen [mailto:hans.hillen@gmail.com] > Sent: Montag, 13. Dezember 2010 22:24 > To: Schnabel, Stefan > Cc: Steve Faulkner; W3C WAI-XTECH > Subject: Re: indicating a context menu > > Hi Stefan, > > The problem is that you can't distinguish between a widget having a dropdown (such as a menubutton) or a context menu (which really could be any widget or element). For one, this could be a problem for a widget that has both. But even if aria-haspopup is used to only indicate a context menu, it's not very effective because the presence of a custom context menu is still likely to to go unnoticed by the screen reader user. Setting aria-haspopup will at best cause a screen reader to announce something like "submenu" or "pulldown", even though this is not a correct description for triggering a context menu. But there is no way for the screen reader to know whether the developer meant haspopup as in dropdown or aria-haspopup as in context menu (which is why screen readers always announce it as a dropdown, if it announces it at all. > > A web app developer might have implemented a custom DHTML context menu for a particular control to provide widget or application specific options. Traditionally context menus are generated by the browser, and do not contain any useful options for the web application itself. Most screen reader users will not know they can try out Shift + F10 to find out relevant options through the context menu. > > What we really need is an aria-hascontext attribute that indicates a custom context menu is provided by the application developer. The screen reader could then announce that with something like "has context" or "context menu" (screen reader behavior should depend on verbosity settings in this case), making it clear to the user the menu can be opened with the appropriate shortcut. > > Regards, > > Hans Hillen > > > On Dec 13, 2010, at 6:16 PM, Schnabel, Stefan wrote: > >> Hi Steve, >> >> context menu: Shift+F10 >> popup (menu): Alt + Arrow Down >> >> and your question is what to use when? >> >> This seems to be not so clear for spec says >> >> "aria-haspopup (property): Indicates that the element has a popup context menu or sub-level menu" >> >> So the clash is that we have (in case of link elements) contradicting keyboard specs for invoking context menu, right? >> >> Regards >> Stefan >> >> >> >> -----Original Message----- >> From: Steve Faulkner [mailto:faulkner.steve@gmail.com] >> Sent: Montag, 13. Dezember 2010 17:59 >> To: Schnabel, Stefan >> Cc: W3C WAI-XTECH >> Subject: Re: indicating a context menu >> >> Hi Stefan, >> >> it being on a link is not the issue, what is is that there is no clear >> way to indicate that there is a context menu available as a against a >> popup menu each of which have different keyboard interactions >> associated with them. >> >> best regards >> steve >> >> On 13 December 2010 16:43, Schnabel, Stefan <stefan.schnabel@sap.com> wrote: >>> Steve, >>> >>> Well, AFIK the context menu is a service by the User Agent for that particular HTML element, >>> shouldn't be this discussed between UA and AT? >>> >>> UA should announce to the AT, that it has stuffed the link element with a context menu. >>> Maybe a clear case for some of the AIA members http://www.atia.org/i4a/pages/index.cfm?pageid=3752 to discuss.. >>> >>> Regards >>> Stefan >>> >>> >>> -----Original Message----- >>> From: Steve Faulkner [mailto:faulkner.steve@gmail.com] >>> Sent: Montag, 13. Dezember 2010 17:37 >>> To: Schnabel, Stefan >>> Cc: W3C WAI-XTECH >>> Subject: Re: indicating a context menu >>> >>> Hi Stefan, >>> what I have is a link that has a custom context menu. >>> >>>> <a aria-haspopup="true"> >>>> >>>> Here, aria-haspopup is superfluous for every <A> has a context menu (invoked with Shift+F10 in e.g. IE and FF) >>> >>> is it superfluous? as there is no indication via accessibility APIs >>> that a standard link has a context menu. >>> >>> >>> regards >>> stevef >>> >>> On 13 December 2010 16:27, Schnabel, Stefan <stefan.schnabel@sap.com> wrote: >>>> Hi Steve, >>>> >>>> do you mean >>>> >>>> <span role="link"> >>>> >>>> Here, I suppose, we need >>>> >>>> <span role="link" aria-haspopup="true"> >>>> >>>> To indicate a (custom) context menu .. >>>> >>>> >>>>>>> how does one let users know that they have tu use a particular keystroke >>>> >>>> This could be e.g. an ARIA 2.0 extension, we call this "Tutor Messages". Could use an (to be invented) "aria-help" property for that or role extensibility. >>>> >>>> >>>> Or do you mean >>>> >>>> <a aria-haspopup="true"> >>>> >>>> Here, aria-haspopup is superfluous for every <A> has a context menu (invoked with Shift+F10 in e.g. IE and FF) >>>> >>>> Regards >>>> Stefan >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On Behalf Of Steve Faulkner >>>> Sent: Montag, 13. Dezember 2010 15:20 >>>> To: W3C WAI-XTECH >>>> Subject: indicating a context menu >>>> >>>> What is the mest way to indicate the presence of a context menu on a >>>> link using ARIA? >>>> >>>> aria-haspopup seems inadequate for the task. >>>> >>>> how does one let users know that they have tu use a particular >>>> keystroke (http://dev.aol.com/dhtml_style_guide#popupmenu) >>>> >>>> -- >>>> 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 >>>> >>>> >>> >>> >>> >>> -- >>> 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 >>> >> >> >> >> -- >> 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 >> >
Received on Wednesday, 15 December 2010 13:28:30 UTC