Fw: How to Generate Automatically Accessible ARIA Tabs and Menu Controls
"Bryan Garaventa" <[email protected]> Sun, 18 Sep 2011 12:47:00 -0700
| Newsgroups | gmane.comp.mozilla.accessibility |
|---|---|
| Message-ID | <CE7870CD7B054F0EBBEF1B1B68C3CD6D@WAMPAS> |
In case it's of interest. ----- Original Message ----- To: [email protected] Sent: Thursday, September 15, 2011 9:54 PM Subject: How to Generate Automatically Accessible ARIA Tabs and Menu Controls I've written two modules that will automatically convert standard DOM elements into interactive ARIA Tabs and Menu controls. CSS Selectors are used to identify specified DOM nodes, and the ARIA Menu module supports recursive processing to configure interactive submenus. The functionality of each module should be easy to understand from the code. ARIA Tab functionality simulates the software browsing experience within standard Windows applications. Keystrokes: . Using a screen reader, press Tab or Arrow to a tab and press Enter to activate. . Use the arrow keys to select and activate successive tabs. . Press Tab or Shift+Tab or Escape to move out of the tab selector field. ARIA Menu functionality simulates the context menu experience within standard Windows applications. . Using a screen reader, activate the Options button. . Use the Up and Down Arrow keys to traverse available menu options. . Press the Right Arrow or Enter key to open a submenu, or to activate a menu item. . Press the Left Arrow key to close the currently open menu and return to a previously open menu (if present). . Press Escape, Tab, or Shift+Tab to close all currently open menus and submenus. Interactive Demo: http://whatsock.com/modules/aria_tabs_menu_modules/demo.htm Packaged Download: http://whatsock.com/modules/aria_tabs_menu_modules.zip Enjoy, Bryan www.WhatSock.com ----- Original Message ----- From: Michael Schidlowsky To: [email protected] Sent: Thursday, September 15, 2011 10:20 AM Subject: Re: Google Docs Hi Kevin, Thanks so much for giving our new accessibility improvements a try. It sounds like NVDA with google docs is not giving you a great experience. Have you had the chance to try JAWS or ChromeVox with google docs? Do you find the experience to be any better? These are the two screenreaders we've worked the hardest to support in our initial efforts, so I'd be curious if you have a better experience with either product. And if they don't work for you we'd certainly like to know why. There are many issues that we are aware of but basic functionality should work, as described in our blog post here: http://googledocs.blogspot.com/2011/09/improved-accessibility-in-google-docs.html If you find that to not be the case please let us know. Thanks! -Michael On Wed, Sep 14, 2011 at 7:01 PM, Kevin Chao <[email protected]> wrote: Google announced and took the wraps off what's been dubbed "enhanced accessibility in Google Docs". I certainly applaud, appreciate, and praise Google in their accessibility efforts, but there seems to be this level of accessibility, which includes efficiency, effectiveness, and equal access that Google is far from with all attempts, which Docs is no exception. Visiting Docs.Google.Com using Firefox and NVDA, either classic or new look/UI, ladder is much worst from an accessibility point, but all is relative, including "enhanced accessibility". Google is always in in a race with itself, changing elements, such as looks/UI's. Often there are different views to pick from, and it's often the one that is "basic" or "classic" that is more accessible, which leaves screen readers with a dumb downed experience than and equal experience compared to the full "standard" or "new" UI/look that everyone else who does not need to use a screen has the luxury of using. There should not be more than one view, if there has to be an experimental/ enhanced view, it should be accessible, and it's very degrading that Google by only putting accessibility resources into the dumbed UI/ look implies that all blind screen reader users are unable to perceive, understand, and work with advance, complex, and rich UI/ looks. Now, let's move onto the main focus, which is the enhanced accessibility in Google docs. Using Firefox, NVDA, and looking at Docs.Google.com in classic view Main UI/Look * navigating by form fields or line will reveal lots of unlabeled controls, such as "button", clickable, expanded, checkboxes, and and clickable list. It's bad enough from a user interface, experience, and accessibility standpoint that all these controls do not have proper labels, making them accessible, but there's more. * Instructions indicate to get started, activate create new or upload button, but these are identified as clickables, which do not do anything when pressing ENTER. However, with enough attempts of everything under the sun such as NVDA+CTRL+SPACE, SPACE, mouse click, etc; it will be possible to activate these buttons. It should not be this difficult, frustrating, and require all these work-arounds to activate buttons (no, no, they are not buttons, but clickables). * When navigating to the expand button, pressing ENTER, NVDA is silent. The new status, which is collapsed is not conveyed from Docs via ARIA or any accessibility event. In addition, arrowing down does not show any additional content. ARIA Live-regions should be used to alert user of updated dynamic content. * Navigating to unlabeled button, pressing ENTER, reviewing contents on screen does not show that anything changed. * Lots of items are identified as menus and submenus, which when activated do not work as ARIA jQuery menus, but instead do not do anything, cannot track focus/read, and/or it's not possible to exit menu/submenu. * Effective and efficient navigation is lacking greatly, which could be improved by use of ARIA Landmarks and headings. Creating/Editing Docs * Browse/upload process does not work by simply using arrows/TAB and ENTER/SPACE, but requires the same level of fighting, frustration, and work-around that were required to get into the upload page. * Creating a new doc/opening an uploaded one will open it in a new tab, which is idenitifed with: docuemnt title, app, javascript, file type, and editable". While all this is great, arrowing in document reads absolutely nothing and same goes for tabbing around. Please, Google, there really needs to be real accessibility present, which includes effectiveness, efficiency, and equal level of access. No more of this Google accessibility. Kevin Chao Twitter: @KevinChao89 -- You received this message because you are subscribed to the Google Groups "accessible" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/accessible?hl=en. -- You received this message because you are subscribed to the Google Groups "accessible" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/accessible?hl=en.