- From: Matt King <a11ythinker@gmail.com>
- Date: Thu, 26 Oct 2017 12:43:09 -0700
- To: "'Sean Murphy \(seanmmur\)'" <seanmmur@cisco.com>, <w3c-wai-ig@w3.org>
Sean wrote: > The ARIa best practise standards 1.1 in the keyboard section discuss the use of tab and arrow keys > within menus. Historically (before the Web) menus used the arrow keys to navigate between the menu items > and tab was not used. Not sure of the history or reasoning behind why the ARIA best practise refers to tab. > One possibility is the thinking keyboard users within browsers > are used to use the tab key and reduces confusion. The ARIA Practices do not suggest that tab should move focus inside of a menu. Keep in mind, we are talking here about an element that is understood to work like a desktop menu because it has an ARIA menu role. There is a lot of confusion around this topic because many people refer to a simple list of links as a menu. And, while it may serve as a menu in everyday vernacular, a list of links is not a menu in GUI design terms nor in accessibility API land. In other words, not everything that everyone thinks of as a menu is actually a menu after you jump into GUI design or accessibility land. The editor's draft of the ARIA practices is at: http://w3c.github.io/aria-practices/ Matt -----Original Message----- From: Sean Murphy (seanmmur) [mailto:seanmmur@cisco.com] Sent: Monday, October 23, 2017 12:15 PM To: Steve Green <steve.green@testpartners.co.uk>; Jim Homme <jhomme@benderconsult.com>; Schafer, Carmen <schafercg@missouri.edu>; w3c-wai-ig@w3.org Subject: RE: tab vs. arrow keys with NVDA and Firefox This just demonstrates different behaviour between screen readers where there should be standards. The ARIa best practise standards 1.1 in the keyboard section discuss the use of tab and arrow keys within menus. Historically (before the Web) menus used the arrow keys to navigate between the menu items and tab was not used. Not sure of the history or reasoning behind why the ARIA best practise refers to tab. One possibility is the thinking keyboard users within browsers are used to use the tab key and reduces confusion. Sean Murphy ENGINEER.CUSTOMER SUPPORT seanmmur@cisco.com Tel: +61 2 8446 7751 Cisco Systems, Inc. The Forum 201 Pacific Highway ST LEONARDS 2065 Australia cisco.com Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. http://www.cisco.com/c/en/us/about/legal/terms-sale-software-license-agreeme nt/company-registration-information.html -----Original Message----- From: Steve Green [mailto:steve.green@testpartners.co.uk] Sent: Tuesday, 24 October 2017 3:04 AM To: Jim Homme <jhomme@benderconsult.com>; Schafer, Carmen <schafercg@missouri.edu>; w3c-wai-ig@w3.org Subject: Re: tab vs. arrow keys with NVDA and Firefox NVDA does this with horizontal lists of links, which means that the main menu of just about every website is affected. I don't know why it has been designed this way, but it has always done it. It means that you can arrow down to the menu but you have to use the Tab key to navigate through the horizontal list of links. It is not a WCAG non-compliance because there is nothing wrong with your code. The links should ideally be in a list element rather than a paragraph, but that would not change the behaviour with NVDA. If you test it with JAWS and pretty much any other screen reader it will work fine. Regards, Steve Green Managing Director Test Partners Ltd ________________________________________ From: Jim Homme <jhomme@benderconsult.com> Sent: 23 October 2017 16:22 To: Schafer, Carmen; w3c-wai-ig@w3.org Subject: RE: tab vs. arrow keys with NVDA and Firefox Hi, This does not answer your question, but the user needs to be able to read all of the content on the page. This means that most of the time they will arrive at the buttons by arrowing onto them. Second, NVDA is probably looking for a true control, such as what you would get with a button tag or an input control. Without knowing what your page is like, I am guessing that you have a span or div with a button role, and this is what is causing the problem. Thanks. Jim ========== Jim Homme, Team Lead and Accessibility Consultant, Bender HighTest Accessibility Team Bender Consulting Services, Inc., 412-787-8567, jhomme@benderconsult.com http://www.benderconsult.com/our%20services/hightest-accessible-technology-s olutions E+R=O From: Schafer, Carmen [mailto:schafercg@missouri.edu] Sent: Monday, October 23, 2017 10:51 AM To: w3c-wai-ig@w3.org Subject: tab vs. arrow keys with NVDA and Firefox Hi all, I have question regarding arrow keys vs. the tab key using NVDA and Firefox. When I use the tab key on three buttons (see screenshot below), NVDA announces each one individually as I tab and they are accessible using the enter key. I believe this is called focus mode. However, when using arrow keys it announces the heading level and a clickable list (see speech output below). I believe this is called browse mode. Using the arrow keys, NVDA doesn't announce each button individually and I cannot access the link with the enter key. Is this a WCAG 2.0 violation since the buttons can be comprehended and accessed using the tab key, but not with arrow keys? [cid:image001.jpg@01D34BF1.3139CEF0] NVDA Speech Output Tab Key used: PHYSICIANS link NURSING link ALL OPENINGS link Arrow Keys Used: Banner banner landmark heading level 3 FIND A JOB clickable list Code <h3 class="open">Find a Job</h3> <div> <p> <a class="btn btn-yellow" href="/jobseeker/physician" tabindex="0">Physicians</a> <a class="btn btn-yellow" href="/jobseeker/nursing" tabindex="0">Nursing</a> <a class="btn btn-yellow external" href="/jobseeker/allopenings " target="_blank" tabindex="0">All Openings</a> </p> </div> I appreciate anyone's insight into this. Regards, Carmen
Received on Thursday, 26 October 2017 19:43:38 UTC