Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
jQuery Accessibility
Home
+ new post
About this group
Join this group
Message from discussion Screen-readers and UI modal dialog
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
E.J. Zufelt  
View profile  
 More options Feb 18 2010, 2:14 pm
From: "E.J. Zufelt" <li...@zufelt.ca>
Date: Thu, 18 Feb 2010 14:14:59 -0500
Local: Thurs, Feb 18 2010 2:14 pm
Subject: Re: Screen-readers and UI modal dialog
Print | View thread | Show original | Report this message | Find messages by this author
On 2010-02-18, at 1:52 PM, Colin Clark wrote:

> This makes perfect sense. Thanks for the clarification, Everett.

> Okay, so at risk of making you repeat yourself again, can you  
> explain what happens in both JAWS and VoiceOver when we have  
> role=application set somewhere around the dialog? I assume JAWS  
> works correctly, but VoiceOver doesn't because it ignores the  
> application role?

* I haven't tested this thoroughly.  From my experience it appears that.

NVDA almost always respects role=application
JAWS sometimes respects role=application
VoiceOver never respects role=application

> Assuming this is the case, it opens up an interesting issue that  
> I've been pondering for awhile in context of Fluid Infusion. When is  
> it appropriate for a widget to set an application role? In other  
> words, a widget is just a little atomic thing that can be embedded  
> into any number of types of pages or contexts of use. Is it really  
> appropriate for the widget to set role=application, or should the  
> application developer do this as required?

* Again this is something that needs further research.  I will quote  
Steve Faulkner "The role of application does something quite specific,  
it tells the AT to switch modes (if the AT uses them)" (http://www.paciellogroup.com/blog/?p=106#comment-6492
).
  So, although I believe that the ARIA 1.0 spec suggests that  
application be used only once on a document, and ATs may not like to  
see application more than once in the DOM (I have not tested), it is  
clear that either; 1. there needs to be a rol=widget as a mini  
application within a document or 2. application should be supported  
multiple times in one document.

The obvious use-case for this is a page with textual content (like  
search results or blog entries, but with several independent widgets  
(weather, calendar) docked in sidebars.

HTH,
Everett

> Colin

> On 2010-02-18, at 1:44 PM, E.J. Zufelt wrote:

>> JAWS: This is due to being able to navigate the DOM using the  
>> virtual buffer, which doesn't pass the tab key to the browser.

>> VoiceOver: This is due to being able to navigate the DOM through  
>> the VoiceOver object interaction model, which doesn't require the  
>> user to tab to focusable elements, but allows the user to  
>> transverse the DOM using VO specific commands.

> ---
> Colin Clark
> Technical Lead, Fluid Project
> http://fluidproject.org

> --
> You received this message because you are subscribed to the Google  
> Groups "jQuery Accessibility" group.
> To post to this group, send email to jquery-a11y@googlegroups.com.
> To unsubscribe from this group, send email to jquery-a11y+unsubscribe@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en
> .


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google