WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Bryan Garaventa
Date: Sep 16, 2011 9:15PM

In case it's of interest.

----- Original Message -----
From: "Bryan Garaventa" < <EMAIL REMOVED> >
To: < <EMAIL REMOVED> >
Sent: Friday, September 16, 2011 7:01 PM
Subject: Re: How to Generate Automatically Accessible ARIA Tabs and Menu
Controls


Got it. I used the CSS method to style a right-arrow that doesn't impact
accessibility. You are right, it does sound better now.

The following declaration was added to global.css:
ul.menu > li.submenu:after {
content: '2192';
}

The same links apply:
http://whatsock.com/modules/aria_tabs_menu_modules/demo.htm
http://whatsock.com/modules/aria_tabs_menu_modules.zip

Does this appear to stop the TTS choking issue that you were experiencing?


----- Original Message -----
From: "Bryan Garaventa" < <EMAIL REMOVED> >
To: < <EMAIL REMOVED> >
Sent: Friday, September 16, 2011 12:46 PM
Subject: Re: How to Generate Automatically Accessible ARIA Tabs and Menu
Controls


Actually it may be possible to do this using CSS instead from the file
global.css.

E.G.

ul.menu > li.submenu:after {
content: '9654';
}

----- Original Message -----
From: "Bryan Garaventa" < <EMAIL REMOVED> >
To: < <EMAIL REMOVED> >
Sent: Friday, September 16, 2011 12:23 PM
Subject: Re: How to Generate Automatically Accessible ARIA Tabs and Menu
Controls


Strange. I wonder if removing the symbol altogether will change this.
If you would like to test this using the download,
http://whatsock.com/modules/aria_tabs_menu_modules.zip
The unicode symbol can be deleted from each menu instance in
filesmenus.htm. I'll update the sample later though to convert these to
images on the live site.

----- Original Message -----
From: "David Tseng" < <EMAIL REMOVED> >
To: < <EMAIL REMOVED> >
Sent: Friday, September 16, 2011 12:03 PM
Subject: Re: How to Generate Automatically Accessible ARIA Tabs and Menu
Controls


It behaves better in webkit nightlywith the results below.


Via accessibility inspector: (webkit nightly)
AXTitle: "Account ▶ SubMenu"

(Safari 5):
AXTitle: "Account ▶"

The "▶" (the right arrow) appears to be confusing the TTS so all one
hears is the substring after; "submenu" when arrowing in WebKit;
Safari 5 appears to drop submenu entirely in the translation of aria
properties.

On 9/16/11, Bryan Garaventa < <EMAIL REMOVED> > wrote:
> About the menu not working, is it rendering at all?
>
> AccDC is pulling each menu in full from "menus.htm", then appending part
> of
> the id on the resource locator per "setup.js" to pull in related submenus.
> I'm wondering if something in Snow Leopard may not be processing the AJAX
> request. I'll look more into it if this is the case.
>
>
> ----- Original Message -----
> From: "David Tseng" < <EMAIL REMOVED> >
> To: < <EMAIL REMOVED> >
> Sent: Friday, September 16, 2011 9:50 AM
> Subject: Re: How to Generate Automatically Accessible ARIA Tabs and Menu
> Controls
>
>
> Great job Bryan! :).
>
> I'm actually seeing the tablist example working on Snow Leopard
> 10.6.7. However, the menu does not appear to be working.
>
> The next challenge is probably to come up with a modular/isolated way
> to apply aria and keyboard accessibility to DOM objects created
> dynamically. Unfortunately, people violate good MVC rules and don't
> specify all of their UI in markup.
>
> - David
>
> On 9/16/11, Kevin Chao < <EMAIL REMOVED> > wrote:
>> Wow! Excellent job Bryan. This is working very well with NVDA 2011.3
>> Snapshot on:
>> Windows 7 x64: IE8, Firefox 6.0.2, and Google Chrome Canary
>> Windows 8 x64 developer preview 1: Internet Explorer 10 developer preview
>>
>> Hopefully, this idea of using CSS selectors to apply ARIA will be used
>> in all the areas, where it makes sense, EG: Google Docs, Calendar,
>> Gmail, etc. What a great example!
>>
>> Kevin
>> On 9/16/11, Dominic Mazzoni < <EMAIL REMOVED> > wrote:
>>> Thanks, Bryan! I just tested them out and your demos work great in
>>> Firefox,
>>> IE, and Chrome with JAWS and NVDA, and with ChromeVox. Nice job! I like
>>> the
>>> idea of using CSS selectors to apply ARIA. I've seen it applied for
>>> simpler
>>> controls before but you did a good job of making it work for more
>>> complex
>>> ARIA controls like nested submenus.
>>>
>>> Two ideas:
>>> 1. Screen readers describe the black triangle you're using as a visual
>>> indication that there's a submenu, which is redundant because they also
>>> announce there's a submenu. Maybe use aria-hidden or aria-label to make
>>> the
>>> triangle invisible to screen readers?
>>> 2. Could you make your example work on Mac OS X with Safari and
>>> VoiceOver
>>> too? It's possible to make ARIA tabs and menus work on Mac OS X but the
>>> current ARIA markup you have doesn't work for some reason. If you don't
>>> have
>>> access to that platform I can try to figure out what's needed to make it
>>> work.
>>>
>>> - Dominic
>>>
>>> On Thu, Sep 15, 2011 at 9:54 PM, Bryan Garaventa <
>>> <EMAIL REMOVED> > wrote:
>>>
>>>> **
>>>> 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 < <EMAIL REMOVED> >
>>>> *To:* <EMAIL REMOVED>
>>>> *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 REMOVED> >
>>>> 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 REMOVED> .
>>>>> To unsubscribe from this group, send email to
>>>>> accessible+ <EMAIL REMOVED> .
>>>>> 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 REMOVED> .
>>>> To unsubscribe from this group, send email to
>>>> accessible+ <EMAIL REMOVED> .
>>>> 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 REMOVED> .
>>>> To unsubscribe from this group, send email to
>>>> accessible+ <EMAIL REMOVED> .
>>>> 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 REMOVED> .
>>> To unsubscribe from this group, send email to
>>> accessible+ <EMAIL REMOVED> .
>>> 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 REMOVED> .
>> To unsubscribe from this group, send email to
>> accessible+ <EMAIL REMOVED> .
>> 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 REMOVED> .
> To unsubscribe from this group, send email to
> accessible+ <EMAIL REMOVED> .
> 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 REMOVED> .
> To unsubscribe from this group, send email to
> accessible+ <EMAIL REMOVED> .
> 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 REMOVED> .
To unsubscribe from this group, send email to
accessible+ <EMAIL REMOVED> .
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 REMOVED> .
To unsubscribe from this group, send email to
accessible+ <EMAIL REMOVED> .
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 REMOVED> .
To unsubscribe from this group, send email to
accessible+ <EMAIL REMOVED> .
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 REMOVED> .
To unsubscribe from this group, send email to
accessible+ <EMAIL REMOVED> .
For more options, visit this group at
http://groups.google.com/group/accessible?hl=en.