Fw: How to Generate Automatically Accessible ARIA Tabs and Menu Controls
In case it's of interest.
----- Original Message -----
To: [hidden email] 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.
. 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.
----- Original Message -----
From: Michael Schidlowsky
To: [hidden email] Sent: Thursday, September 15, 2011 10:20 AM
Subject: Re: Google Docs
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:
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
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/
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
* navigating by form fields or line will reveal lots of unlabeled
controls, such as "button", clickable, expanded, checkboxes, and and
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
* Effective and efficient navigation is lacking greatly, which could
be improved by use of ARIA Landmarks and headings.
* 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
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.