Fw: How to Generate Automatically Accessible ARIA Tabs and Menu Controls

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Fw: How to Generate Automatically Accessible ARIA Tabs and Menu Controls

Bryan Garaventa-2
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.
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: [hidden email]
  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 <[hidden email]> 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 [hidden email].
    To unsubscribe from this group, send email to [hidden email].
    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 [hidden email].
  To unsubscribe from this group, send email to [hidden email].
  For more options, visit this group at http://groups.google.com/group/accessible?hl=en.
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility