Screen-readers and UI modal dialog

2,363 views
Skip to first unread message

E.J. Zufelt

unread,
Feb 18, 2010, 11:18:44 AM2/18/10
to jquer...@googlegroups.com
Good morning,

I have been working on Drupal 7 accessibility. One new feature in Drupal 7 is an administrative overlay, a modal dialog that overlays the current page of the site. I have tested this modal dialog, along with three others (http://build.fluidproject.org/infusion/demos/uiOptions/html/uiOptions.html , http://www.thewhyandthehow.com/jquery-modal-dialog/ and http://jqueryui.com/demos/dialog/).

I have tested with JAWS 11.0.756 (newest) and NVDA 2009.1 (newest), on Firefox 3.6. I have also tested with VoiceOver from OS X 1.6.0 and Safari 4.0.4, though I don't believe that support exists for dialogs at this time.

I receive inconsistent behaviour.

Modality:

NVDA almost always respects modality, JAWS often does not, VoiceOver never does.

Application mode

NVDA almost always enters application mode, JAWS often does not, VoiceOver does not have an application mode (it essentially always is in application mode).

Clearly these issues are related. A couple of questions I have.

1. Should respecting the modality of the dialog require the screen-reader to enter application mode? Is the definied in the ARIA spec?

2. Are there a11y bugs open against dialog / modal dialog?

3. Does anyone have any suggestions for best a11y practice when implementing a jquery UI modal dialog?

Thanks,
Everett Zufelt

Follow me on Twitter
http://twitter.com/ezufelt

View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt



Scott González

unread,
Feb 18, 2010, 1:05:22 PM2/18/10
to jquer...@googlegroups.com
Hey Everett,

Hopefully others can respond to the main questions, but there are not currently any open a11y bugs for dialog. We can file bugs as necessary based on the responses to this thread.
--
You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group.
To post to this group, send email to jquer...@googlegroups.com.
To unsubscribe from this group, send email to jquery-a11y...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.

Hans Hillen

unread,
Feb 18, 2010, 1:09:51 PM2/18/10
to jQuery Accessibility
Hi Everett,

I'm currently looking into the dialog's accessibility as well. It does
seem JAWS has some issues with consistently announcing ARIA dialogs.

As for modality, this is something that has to be maintained by the
developer, e.g. by ensuring the tab order does not spill out the
dialog. There is no programmatic state that conveys modality of a
DHTML dialog to assistive technology, so a screen reader will always
be capable of traversing the rest of the DOM using the virtual buffer.
This is why dialogs need to be accessed in application mode, which
should be defined by the developer using role="application". This
SHOULD trigger the screen reader into a non-virtual mode, which makes
it less likely (but never impossible) to access the main interface
that is temporarily disabled.

The closest we have to best practices on this subject at the moment is
http://dev.aol.com/dhtml_style_guide#dialogmodal and
http://www.w3.org/TR/wai-aria-practices/#dialog_modal


Hans


On Feb 19, 5:18 am, "E.J. Zufelt" <li...@zufelt.ca> wrote:
> Good morning,
>
> I have been working on Drupal 7 accessibility. One new feature in  
> Drupal 7 is an administrative overlay, a modal dialog that overlays  
> the current page of the site. I have tested this modal dialog, along  

> with three others (http://build.fluidproject.org/infusion/demos/uiOptions/html/uiOptions...,http://www.thewhyandthehow.com/jquery-modal-dialog/andhttp://jqueryui.com/demos/dialog/

E.J. Zufelt

unread,
Feb 18, 2010, 1:24:52 PM2/18/10
to jquer...@googlegroups.com
Good afternoon Hans,

Thanks for the response and resources.

It would seem to me then that using Dialog for anything that isn't really a dialog is a bad idea.  I differentiate here between a dialog, which I see as being a container with few UI options and messages, and an overlay, which may be a complete window or frame overlaying the UI from which it was launched.  If it is necessary to control modality by using application mode to keep screen-reader users inside the dialog, then it is undesirable to use dialog for complex UIs, or UIs that include very much text content.

I wonder if an aria-modal state would be of use, if set to true then the element and its children would be treated as modal by AT.

Thanks again,
Everett Zufelt

Follow me on Twitter
http://twitter.com/ezufelt

View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt



Rich Caloggero

unread,
Feb 18, 2010, 1:29:24 PM2/18/10
to jquer...@googlegroups.com
Have you read:
WAI-ARIA Authoring Practices 1.0
3.3. Making a Dialog Modal
http://www.w3.org/TR/wai-aria-practices/

A quick scan of this section seems to say nothing about requiring screen
readers to go into application mode. The only thing that is necessary is
that keyboard focus be trapped within the elements of the dialog. The above
document provides pseudo code to implement this.

Hope this helps.
-- Rich


----- Original Message -----
From: "Scott Gonz�lez" <scott.g...@gmail.com>
To: <jquer...@googlegroups.com>
Sent: Thursday, February 18, 2010 1:05 PM
Subject: Re: Screen-readers and UI modal dialog


> Hey Everett,
>
> Hopefully others can respond to the main questions, but there are not
> currently any open a11y bugs for dialog. We can file bugs as necessary
> based
> on the responses to this thread.
>
>
> On Thu, Feb 18, 2010 at 11:18 AM, E.J. Zufelt <li...@zufelt.ca> wrote:
>
>> Good morning,
>>
>> I have been working on Drupal 7 accessibility. One new feature in Drupal
>> 7
>> is an administrative overlay, a modal dialog that overlays the current
>> page
>> of the site. I have tested this modal dialog, along with three others
>> (http://build.fluidproject.org/infusion/demos/uiOptions/html/uiOptions.html
>> , http://www.thewhyandthehow.com/jquery-modal-dialog/ and

>> http://jqueryui.com/demos/dialog/<http://build.fluidproject.org/infusion/demos/uiOptions/html/uiOptions.html+%2C+http://www.thewhyandthehow.com/jquery-modal-dialog/+and+http://jqueryui.com/demos/dialog/>

>> jquery-a11y...@googlegroups.com<jquery-a11y%2Bunsu...@googlegroups.com>

Rich Caloggero

unread,
Feb 18, 2010, 1:33:45 PM2/18/10
to jquer...@googlegroups.com
>I wonder if an aria-modal state would be of use, if set to true then the
>element and its children would be treated as modal by AT.

This would be desirable. IT seems silly for the developer to have to
restrict keyboard focus by hand to the dialog when seemingly the assistive
technology could do this better and more consistently.
Restricting the screen reader to applications mode may help, but then you
lose the ability to easily read text within the dialog etc.

----- Original Message -----
From: "E.J. Zufelt" <li...@zufelt.ca>
To: <jquer...@googlegroups.com>
Sent: Thursday, February 18, 2010 1:24 PM
Subject: Re: Screen-readers and UI modal dialog

Colin Clark

unread,
Feb 18, 2010, 1:34:30 PM2/18/10
to jquer...@googlegroups.com
If I remember correctly, we have code in the Dialog that should prevent keyboard focus from straying outside of modal dialogs. Has this regressed, or is it another issue altogether?

A minor point here: keeping focus inside a modal dialog box isn't just an accessibility issue, it's a user experience thing for everyone. If it's modal, and it's in the foreground, Tab and Shift-Tab shouldn't allow the user to focus items that are outside the dialog's container.

Everett, can you describe the actual behaviour you're observing when you say JAWS and VoiceOver don't "respect modality?"

Colin

On 2010-02-18, at 1:29 PM, Rich Caloggero wrote:

> A quick scan of this section seems to say nothing about requiring screen readers to go into application mode. The only thing that is necessary is that keyboard focus be trapped within the elements of the dialog. The above document provides pseudo code to implement this.

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

Hans Hillen

unread,
Feb 18, 2010, 1:39:55 PM2/18/10
to jQuery Accessibility
Let me rephrase:

It's not a requirement for the screen reader to run in application
mode, but if it's running in virtual mode, there is nothing to stop it
from moving its virtual cursor out of the dialog which is supposed to
be modal.

Hans

E.J. Zufelt

unread,
Feb 18, 2010, 1:40:29 PM2/18/10
to jquer...@googlegroups.com
Good afternoon Rich,

I am not filled with a wealth of experience on this, but let me take a crack at answering why application mode is required.

Screen-readers that use a virtual buffer to display web content, like JAWS, use their own key bindings to allow navigation of the virtual buffer.  Using JAWS as the example, when a user is in virtual cursor (buffer) mode, which is the default, the tab key navigates through the focusable elements in the virtual buffer.  The tab key is not passed to the browser.  When the mode is switched to application mode the virtual buffer is disabled, and keystrokes like tab are passed through to the browser.

Therefore, if JAWS builds a virtual buffer of the DOM, including the dialog, users will be able to tab in and out of the modal dialog in the buffer, because the tab key is handled by JAWS / the virtual buffer. If application mode is invoked, and the buffer enabled, the tab key will be handled by the browser and users will not be able to tab out of the dialog, however they will lose the ability to interact with the dialog with all of the navigation and reading commands found in the virtual buffer.

HTH,

Everett Zufelt

Follow me on Twitter
http://twitter.com/ezufelt

View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt



On 2010-02-18, at 1:29 PM, Rich Caloggero wrote:

Have you read:
WAI-ARIA Authoring Practices 1.0
3.3. Making a Dialog Modal
http://www.w3.org/TR/wai-aria-practices/

A quick scan of this section seems to say nothing about requiring screen readers to go into application mode. The only thing that is necessary is that keyboard focus be trapped within the elements of the dialog. The above document provides pseudo code to implement this.

Hope this helps.
-- Rich


----- Original Message ----- From: "Scott González" <scott.g...@gmail.com>

E.J. Zufelt

unread,
Feb 18, 2010, 1:44:18 PM2/18/10
to jquer...@googlegroups.com
Good afternoon Colin,

I think I described this in the message I just sent (after yours).  However, in short, by not respecting modality I mean that the user is not confined to the modal dialog and can navigate and activate controls outside of the dialog.

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.

HTH, 

Everett Zufelt

Follow me on Twitter
http://twitter.com/ezufelt

View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt



E.J. Zufelt

unread,
Feb 18, 2010, 1:49:03 PM2/18/10
to jquer...@googlegroups.com
On 2010-02-18, at 1:33 PM, Rich Caloggero wrote:

>> I wonder if an aria-modal state would be of use, if set to true
>> then the element and its children would be treated as modal by AT.
>
> This would be desirable. IT seems silly for the developer to have to
> restrict keyboard focus by hand to the dialog when seemingly the
> assistive technology could do this better and more consistently.
> Restricting the screen reader to applications mode may help, but
> then you lose the ability to easily read text within the dialog etc.
>
>

* Forcing the AT to deal with modality would also be following the
accessibility principal of device independent interactions. Although
the common perspective is that all screen-reader users are keyboard
users, it is less commonly realized that screen-reader users are not
interacting with the browser / DOM / document using a keyboard. They
are interacting with AT using a keyboard (or other input device) and
the AT is interacting with the browser / DOM / document.

Thanks,
Everett


Colin Clark

unread,
Feb 18, 2010, 1:52:26 PM2/18/10
to jquer...@googlegroups.com
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?

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?

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.

---

E.J. Zufelt

unread,
Feb 18, 2010, 2:14:59 PM2/18/10
to jquer...@googlegroups.com
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
>

Derek Featherstone

unread,
Feb 18, 2010, 2:24:03 PM2/18/10
to jquer...@googlegroups.com
Hi everyone,

Just jumping in here -- this is a timely conversation. We're quite
busy with ARIA and dialogs right now and experienced this same issue.

Ultimately, even when we have a dialog present and we manage focus
correctly by physically limiting the tab order/focus control to just
those links/controls that are visible on the screen, the entire links
list in the virtual buffer in JAWS, for example, remains.

What Everett suggests is reasonable:

On Thu, Feb 18, 2010 at 2:14 PM, E.J. Zufelt <li...@zufelt.ca> wrote:
> 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.

Ultimately a role of application or widget on a containing <div> for
example, should trigger AT to react reasonably -- to limit the scope
of what is available to that particular context.

Does this cause any other issues outside of the context of that
widget/mini-application?

Derek.

--
Derek Featherstone fea...@furtherahead.com
tel: +1 613-599-9784 1-866-932-4878 (toll-free in North America)
Work: http://www.furtherahead.com
Blog: http://www.boxofchocolates.ca
Help: http://ironfeathers.ca/donate/

Colin Clark

unread,
Feb 18, 2010, 2:38:23 PM2/18/10
to jquer...@googlegroups.com
I guess the primary issue would be if there are any side effects to having potentially many role="application" declarations throughout a page. I'd be very curious to see if it works. Has anyone tested this, or is anyone willing to give it a try?

Assuming it works, I guess we'll recommend that all appropriate widgets, such as Dialog, wrap themselves in an element with role="application" set.
Colin

On 2010-02-18, at 2:24 PM, Derek Featherstone wrote:

> Ultimately a role of application or widget on a containing <div> for
> example, should trigger AT to react reasonably -- to limit the scope
> of what is available to that particular context.
>
> Does this cause any other issues outside of the context of that
> widget/mini-application?

---

E.J. Zufelt

unread,
Feb 18, 2010, 2:53:57 PM2/18/10
to jquer...@googlegroups.com
Derek wrote:

Ultimately a role of application or widget on a containing <div> for
example, should trigger AT to react reasonably -- to limit the scope
of what is available to that particular context.

Does this cause any other issues outside of the context of that
widget/mini-application?

* I can't think of any particular problems, when a user enters into the 'application' container using whatever navigation is available in their AT the AT should switch modes, it the AT supports modes.  ATs could also provide a function to users that would list the available applications (widgets) on a page for easier navigation.

Everett Zufelt

Follow me on Twitter
http://twitter.com/ezufelt

View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt



On 2010-02-18, at 2:24 PM, Derek Featherstone wrote:

E.J. Zufelt

unread,
Feb 18, 2010, 2:57:02 PM2/18/10
to jquer...@googlegroups.com
On 2010-02-18, at 2:38 PM, Colin Clark wrote:

> I guess the primary issue would be if there are any side effects to
> having potentially many role="application" declarations throughout a
> page. I'd be very curious to see if it works. Has anyone tested
> this, or is anyone willing to give it a try?
>

* I definitely haven't tested, would be happy to if someone setup a
quick demo page.

I would add that what I think should work (a widget role or support
for multiple application roles) and a optional aria-modal state for
widgets / applications is what I think * should * work, not what
actually does work. Perhaps stating the obvious here, but worth being
clear for anyone reading this conversation who isn't familiar with ARIA.

Thanks again,
Everett

Rich Caloggero

unread,
Feb 18, 2010, 3:22:48 PM2/18/10
to jquer...@googlegroups.com
Here's a quick test page:
http://www.mit.edu/~rjc/multipleAppRoles.html

Jaws is behaving strangely in this circumstance. Each div tagged with
role="application" is simply being announced as having a landmark role of
"application" (i.e. similar to tagging a div with role="search" or
role="main"). It seems that the only way to force Jaws into "application
mode" (where all virtual buffer processing is turned off) is to tag the body
element itself with role="application".

-- Rich

----- Original Message -----
From: "E.J. Zufelt" <li...@zufelt.ca>
To: <jquer...@googlegroups.com>
Sent: Thursday, February 18, 2010 2:57 PM
Subject: Re: Screen-readers and UI modal dialog

Derek Featherstone

unread,
Feb 18, 2010, 3:33:14 PM2/18/10
to jquer...@googlegroups.com
On Thu, Feb 18, 2010 at 3:22 PM, Rich Caloggero <r...@mit.edu> wrote:
> Here's a quick test page:
> http://www.mit.edu/~rjc/multipleAppRoles.html
>
> Jaws is behaving strangely in this circumstance.

I am not surprised. Would a better test be with NVDA?

Should this be some of an experimental use case where we should be
providing advice to AT vendors and feed this back into the ARIA spec
dev process? Particularly if we are saying that the current spec
allows for only one role="application" in a document?

Rich Caloggero

unread,
Feb 18, 2010, 3:35:51 PM2/18/10
to jquer...@googlegroups.com
http://www.mit.edu/~rjc/multipleAppRoles.html

As this test file shows, multiple application roles within a document are
not supported. I like the role="widgit" idea for this, or change the
semantics of role="application" to work for multiple containers within the
same document.

The issue in using this concept to implement dialog UIs is that its often
difficult to know what the dialog is about -- i.e. you need to have a sure
fire way of reading the bare text within a dialog. You could somehow use
aria-labelledby or aria-describedby or similar, but this isn't really the
semantically correct thing to do. For example, what would you attach the
label to? When would the label be read (i.e. if you say the the entire
dialog is describedby or labelledby some text, then when will this text be
read? Only when the dialog first appears? Each time you press tab when your
within the dialog's boundaries? None of this really makes sense...
It seems that the screen reader should be smart about how it handles dialog
roles - it should provide a standard way of reading bare text within
dialogs. This would suggest that we need another role for tagging such
text, or a set of conventions to deal with this situation. It also seems
logical for the screen reader to force focus back to the dialog itself if a
modal flag is present and not leave this to the application developer.

-- Rich


----- Original Message -----
From: "E.J. Zufelt" <li...@zufelt.ca>
To: <jquer...@googlegroups.com>
Sent: Thursday, February 18, 2010 2:53 PM
Subject: Re: Screen-readers and UI modal dialog

Rich Caloggero

unread,
Feb 18, 2010, 4:06:27 PM2/18/10
to jquer...@googlegroups.com
http://www.mit.edu/~rjc/multipleAppRoles.html

Jaws only switches modes if the body is the only element with
role="application"; NVDA will
switch modes each time you navigate into / out of a container with
role="application". Although the NVDA behavior seems reasonable, I think
there are some
caveats to be aware of. Especially for inexperienced users, changing the
rules on the fly (i.e. switching from virtual to nonvirtual mode
automatically)
could be very confusing. I'm a screen reader user with lots of experience
and I find it a bit confusing.


The problem is that as soon as we move back into application mode,
navigation will be limited to just tab and shift+tab. If we allow
autoswitching and multiple
application mode containers within the same document, then users could be
inadvertently trapped within document sections.

Imagine arrowing through this document. In virtual buffer mode this allows
you to read the document one virtual line at a time. You'd first read the h1
tag, then the first paragraph. Then, another press of the arrow key and app
mode would kick in and you'd be stuck on the first button. If we now tab
forward
(since this is all we can do), we will eventually pop back into virtual mode
when we hit the paragraph with tabindex=0 between the two div blocks.
However,
if we did not provide a focussable element in this section, then we'd never
be able to access it at all.

I believe this is why Jaws tags multiple role="application" blocks with a
typical landmark type annotation, but refuses to switch modes unless there
is
one and only one role="application" on the body element itself; then we can
safely assume that the entire webpage is to be navigated as an application
and the user should be aware of said consequences.

Interested to hear comments ...

----- Original Message -----
From: "Derek Featherstone" <fea...@furtherahead.com>
To: <jquer...@googlegroups.com>
Sent: Thursday, February 18, 2010 3:33 PM
Subject: Re: Screen-readers and UI modal dialog

E.J. Zufelt

unread,
Feb 18, 2010, 4:07:54 PM2/18/10
to jquer...@googlegroups.com
Good afternoon,

So, if I can be so bold as to synthesize the discussion up to this point:

1. Some method of using a role to identify 0 to many applications, or widgets, on a single document is required.

2. Some method of instructing ATs to switch to application mode, for ATs that support modes, to allow users to interact with a complex UI component is required. Note: I do not consider a dialog to be a complex UI component (some text and a couple of buttons being standard), although a dialog might contain 0 to many complex UI components.

3. Some method of communicating to AT that an element (container) and its children are to be treated as modal is required.

Would this seem to be accurate?

Thanks,

Everett Zufelt

Follow me on Twitter
http://twitter.com/ezufelt

View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt



E.J. Zufelt

unread,
Feb 18, 2010, 4:15:24 PM2/18/10
to jquer...@googlegroups.com
Good afternoon Rich,

I completely agree with you that even after having spent time around ARIA I get confused with using NVDA or JAWS in application mode.

What about a suggestion that ATs indicate by sound or announcement that the user has come across a widget / application, at which point the user can use a keystroke to switch modes.  This 1. makes the user aware of applications / widgets and the associated mode, 2. requires the user to decide to enter application mode, and 3. likely means that the user will have a greater chance of knowing how to get out of application mode.

Obviously these options could be customized, an advanced user may turn off the warning and have application mode be automatic on each object, a novice who is biased against ARIA like experiences may choose to disable the announcements and to never enter application mode, even if it means decreased functionality of a web app.

Thoughts?

Everett Zufelt

Follow me on Twitter
http://twitter.com/ezufelt

View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt



Rich Caloggero

unread,
Feb 18, 2010, 4:18:23 PM2/18/10
to jquer...@googlegroups.com
> 1. Some method of using a role to identify 0 to many applications, or
> widgets, on a single document is required.

Yes. I'd consider creating role="widgit" and leave role="application" for
the case where the entire body should be treated as one app. This allows
for more complex semantics - i.e. we can do something intelligent in the
case of multiple widgits embeded within a document.

> 2. Some method of instructing ATs to switch to application mode, for
> ATs that support modes, to allow users to interact with a complex UI
> component is required. Note: I do not consider a dialog to be a
> complex UI component (some text and a couple of buttons being
> standard), although a dialog might contain 0 to many complex UI
> components.

Yes.

> 3. Some method of communicating to AT that an element (container) and
> its children are to be treated as modal is required.

Yes.
I'd also consider modifying the concept of modal, at least interms of the
assistive technology is concerned. I'd suggest perhaps that if we mark up a
block with role="document" and aria-modal="true" (or some such), then the
virtual buffer should still be used, however the assistive technology would
only allow focus within the dialog, even though navigation was not
restricted to simply tabbing among focusable items. This would seem to
provide the best of both worlds, but would require the AT to be a lot
smarter.

E.J. Zufelt

unread,
Feb 18, 2010, 4:30:01 PM2/18/10
to jquer...@googlegroups.com
Good afternoon again Rich,

Let me first say thanks to everyone who has participated in this thread.  I didn't imagine making this much conceptual progress in this short of time.

From our discussion I think that the conclusion that I will take back to the Drupal community is that at the current time there is no way to code modal dialogs, that will be treated consistently by screen-readers.  In situations where a non-modal dialog will either 1. be significantly confusing to the end user or 2. open a risk for unintended actions by the user, dialogs should not be incorporated into a project, or an alternative UI should be provided for screen-reader (and perhaps other) users.

Thanks again,
Everett Zufelt

Follow me on Twitter
http://twitter.com/ezufelt

View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt



Rich Caloggero

unread,
Feb 18, 2010, 4:47:53 PM2/18/10
to jquer...@googlegroups.com
*>What about a suggestion that ATs indicate by sound or announcement that
the user has come across a widget / application, at which point the user can
use a keystroke to switch modes. This 1. makes the user aware of
applications / widgets and the associated mode, 2. requires the user to
decide to enter application mode, and 3. likely means that the user will
have a greater chance of knowing how to get out of application mode.

I think this makes sense, although both screen readers do voice an
announcement when they switch modes. I guess what they are lacking is the
key to switch back and forth. Jaws has insert+z and nvda has
insert+spaceBar, but they don't always seem to do the right thing.

I think changing the definition of modal as I suggested in my last message
could help. This would allow:
1. pure virtual buffer mode (role="document" or no role at all);
2. pure app mode (role="widgit");
3. virtual modal (role="document" and aria-modal="true");
4. app modal (role="widgit" and aria-modal="true").

For things like menus, I think the app modal paradigm makes sense. For
dialogs, I think the virtual modal paradigm might make more sense and be
more flexable.
In the case of menus, you have a definate interaction flow:
1. you activate the menu (maybe with a keystroke);
2. you navigate to the item you want;
3. you execute that command or whatever.

Now youre done with the menu and application modal mode is turned off.

With a dialog, you may have many different paths of navigation through the
dialog. Maybe you want to set some controls, then go back and re-read the
dialog text, switch some more values, then say ok. THis would require you to
be able to navigate unrestricted around the dialog; modal is helpful since
you don't want to stray outside the dialog, but app mode is much too
restrictive.

Maybe other people can think of more use cases?

-- Rich

Rich Caloggero

unread,
Feb 18, 2010, 4:51:59 PM2/18/10
to jquer...@googlegroups.com
I think that dialogs are a sort of expected part of a UI and should be
supported somehow.

I think the best approach is to:
1. do not use role="application"
2. force focus inside the dialog when tab and shift+tab navigation keys are
used;

This almost gives the user the virtual modal effect I talked about in my
other messages, and it avoids the inconsistencies and confusion of
application mode.

----- Original Message -----
From: "E.J. Zufelt" <li...@zufelt.ca>
To: <jquer...@googlegroups.com>
Sent: Thursday, February 18, 2010 4:30 PM
Subject: Re: Screen-readers and UI modal dialog

E.J. Zufelt

unread,
Feb 18, 2010, 5:10:12 PM2/18/10
to jquer...@googlegroups.com
Rich,

This sounds like an excellent recommendation to me.  What I was thinking, but you explained it with a lot of detail and clarity.

Thanks,

Everett Zufelt

Follow me on Twitter
http://twitter.com/ezufelt

View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt



E.J. Zufelt

unread,
Feb 18, 2010, 5:12:52 PM2/18/10
to jquer...@googlegroups.com
On 2010-02-18, at 4:51 PM, Rich Caloggero wrote:

I think that dialogs are a sort of expected part of a UI and should be supported somehow.

I think the best approach is to:
1. do not use role="application"
2. force focus inside the dialog when tab and shift+tab navigation keys are used;

This almost gives the user the virtual modal effect I talked about in my other messages, and it avoids the inconsistencies and confusion of application mode.

* Can you explain your second point here with a little more detail?  I'm not quite sure I understand what you are proposing here.

Thanks,
Everett


E.J. Zufelt

unread,
Feb 18, 2010, 5:30:43 PM2/18/10
to jquer...@googlegroups.com
Rich,

I think I understand what you're saying now.

Even with JAWS virtual buffer enable I cannot tab out of a jQuery UI modal dialog.  I can use the arrow keys, and many other navigation functions, to get out of the dialog, but I cannot tab out of the dialog.

I wonder how many screen-reader users typically use tab navigation as opposed to the other alternate navigation options presented by their AT and if this does not still leave a jQuery UI modal dialog to be a rather confusing UI component at this time?

Thanks for the continued discussion and ideas,

Everett Zufelt
On 2010-02-18, at 4:51 PM, Rich Caloggero wrote:

Rich Caloggero

unread,
Feb 18, 2010, 5:50:04 PM2/18/10
to jquer...@googlegroups.com
*>I wonder how many screen-reader users typically use tab navigation as
opposed to the other alternate navigation options presented by their AT and
if this does not still leave a jQuery UI modal dialog to be a rather
confusing UI component at this time?

I think the web, especially where there's lots of ajax / web-2.0 widgit
stuff going on, is a very confusing place for screen reader users. Its
almost like you have to both have a deep understanding of HTML and how it
interacts with your screen reader, and be a detective so you can figure out
how to navigate the many situations you encounter with the many
not-quite-so-useful tools you have in your screen reader. A sighted person
just looks - if it don't look right, then its probably not. A screen reader
user has to memorize many keystroke commands, have a good memory for various
UI configurations and how to navigate / extract info from each one, and know
enough about how the whole system works to be able to synthesize a new
method of attack when a web page / UI isn't conforming to something she's
seen before. For people with an inherrent interest in computers and
software, this might seem fun, but to the ordinary person who just wants the
computer as a simple tool, the web is a hostile place in deed. Oh, and
education level don't matter either - I've seen some very intelligent and
well educated people throw there hands up in disgust when it comes to
navigating websites via screen reader. Its almost as if each page is a
whole new landscape and you need to explore it with a magnifying glass in
excrutiating detail before you can do anything with it. OK, perhaps a bit
overstated, but not much! <smile>

-- Rich

>>>>>>> To post to this group, send email to jquery-
>>>>>>> a1...@googlegroups.com.

E.J. Zufelt

unread,
Mar 8, 2010, 3:34:15 AM3/8/10
to jquer...@googlegroups.com
Good morning,

I posted a blog article on my site this morning that may be of interest to people in this discussion.  It is basically a summary of what I've learned here.

Can a modal dialog be made to work properly for screen-reader users on the web? 

Thanks,
Everett Zufelt

Follow me on Twitter
http://twitter.com/ezufelt

View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt



Jörn Zaefferer

unread,
Mar 30, 2010, 3:07:47 PM3/30/10
to jquery-a11y
Hi,

I've had this thread in my inbox for a while, and am now trying to
figure out what to make of it. I still have only very limited
experience with screenreaders and ARIA...

I recently read Filament Group's Tooltip chapter from their new book,
and their they recommend to use role="application" on the body element
for the ARIA attributes on tooltips to be useful. I've been wondering
if we should do that only for jQuery UI's tooltip widget, or rather
for all widgets.

I tried to follow the discussion here, but can't extract a
recommendation to follow.

Regards
Jörn

Rich Caloggero

unread,
Mar 30, 2010, 4:19:34 PM3/30/10
to jquer...@googlegroups.com
OK, I'll try my best at describing how a screen reader works when reading
web pages. However, it is confusing, even to experienced users like myself.
Inexperienced users, or those who have no desire to delve under the hood and
just want to use the computer in an intuitive way have a lot of difficulty
with using the web via screen reader. Aria just complicates the issue
further...

Modern screen readers operate in two modes while interacting with web pages:
virtual mode (role = document or no role specified), and application mode
(role = application).

In document mode, the screen reader steals many keys including most of the
alphabetic characters and the arrow keys and control+arrows. It processes
the dom and generates a flat textual representation of it and presents it to
the user. Navigation is done via arrow keys as in most word processors
(next/previous line, next/previous character, etc). Added to this are
next/previous heading (h and shift+h), next/previous list, etc. In this
mode your not interacting with the browser at all, only the screen readers
cached transformed copy of what the browser sees. The screen reader must do
lots of juggling to keep these two in sync, especially when lots of dynamic
features are present (I click this button and a paragraph is added and
another button is un-hidden). Often times, the virtual view and live view
get out of sync and things don't show up or disappear when they should, etc.

In application mode, all keystrokes are passed directly to the browser,
including arrow keys. This mode is also called forms mode, because its the
only way one can enter information into a form. So, interacting with any
HTML form control like a select list, an input text field, or textarea is
done in application mode. In fact, early versions of screen readers didn't
even have document mode; everything was done in application mode (which is
in fact the way the rest of the windows GUI is presented). The problem with
this is that all you could do was tab through the controls; it was very
difficult to access the text of the web page (i.e. all the other
non-form-control elements in the dom). The only way to do this was by
activating the screen reader's mouse cursor. This allows you to crawl the
screen by moving the actual mouse pointer around (using the keyboard). The
issue here is that the screen reader was now not using the dom, but reading
from the rendered on-screen video. This means, for instance, that reading a
page with navigation down the left-hand side and body text to the right of
this would be problemmatic. The screen reader, when asked to read the next
line, would simply read across, and you'd hear a piece of the navigation,
then some paragraph text.

I know this is probably clear as mud, but not sure how else to say it...

In any case, ARIA seeks to rectify some of this by allowing the developer to
force the screen reader into one mode or the other. Of course, the screen
readers don't implement this consistently, and it doesn't solve all
problems.

The issue under discussion here is modal dialogs. We have a case where we
want to keep the user from straying outside the dialog, but we also want the
user to be able to read the dialog (not only tab to the controls, but read
the text - i.e. "Your upload failed due to insufficient resources; please
try again later."). If this message were presented in a modal dialog simply
containing an ok button, and it was presented with role="application", then
the user would only see the ok button; she would not be able to read the
message, so would most likely not know what the purpose of the dialog is.
If we use role="document", then the user could easily stray out of the
dialog because the screen reader sees the dialog as just part of the dom and
presents it in its virtual view right along with everything else in the
page; visual CSS stuff (putting one thing "on top of" another, etc) is not
dealt with by the screen reader.

I see a couple of ways to help eleviate this situation, but none are
perfect.

1. Clearly mark up the part of the dialog that is the "message" - i.e. the
text which should be read (or heard) when the dialog appears. Maybe this
should be a distinct option in the dialog API. The reason for this is that
then jQuery-ui could tag it with tabindex="0". This places it in the tab
order, so that whhe dialog appears and navigation is limited to just tab and
shift+tab, the text of the dialog will eventually be heard by the user when
she tabs to it. Of course, the screen reader should be smart enough to read
it when the dialog first appears, but neither Jaws nor NVDA do this
reliably.

2. Put a role="application" on the dialog container (this is already
implemented).

3. Since there is an issue with exactly how ARIA should behave in this
situation, petition the W3C to add role="widgit" which essentially does the
same thing as application, but can occur mulle times within a web page.
Otherwise, change the specification for role="application" to allow for
multiple instances within a page.

I hope this makes sense.
-- Rich Caloggero, MIT ATIC / WGBH NCAM

----- Original Message -----
From: "J�rn Zaefferer" <joern.z...@googlemail.com>
To: "jquery-a11y" <jquer...@googlegroups.com>
Sent: Tuesday, March 30, 2010 3:07 PM
Subject: Re: Screen-readers and UI modal dialog - modified test page


Hi,

I've had this thread in my inbox for a while, and am now trying to
figure out what to make of it. I still have only very limited
experience with screenreaders and ARIA...

I recently read Filament Group's Tooltip chapter from their new book,
and their they recommend to use role="application" on the body element
for the ARIA attributes on tooltips to be useful. I've been wondering
if we should do that only for jQuery UI's tooltip widget, or rather
for all widgets.

I tried to follow the discussion here, but can't extract a
recommendation to follow.

Regards
J�rn

Jörn Zaefferer

unread,
Mar 30, 2010, 4:33:36 PM3/30/10
to jquery-a11y
Thanks Rich, thats actaully a very good explanation, I had no trouble
following along.

But it also sounds to me like this is more of an unsolved problem.
Ignoring the modal dialog for a moment, what happens if we stick
role="application" on the body element as soon as the page loads?
Thats supposed to make tooltips accessiable when combined with the
right aria-attributes, but if that also makes any other text on the
page inaccessiable, you do more damage then actually improving
anything.

Jörn

> ----- Original Message ----- From: "Jörn Zaefferer"


> <joern.z...@googlemail.com>
> To: "jquery-a11y" <jquer...@googlegroups.com>
> Sent: Tuesday, March 30, 2010 3:07 PM
> Subject: Re: Screen-readers and UI modal dialog - modified test page
>
>
> Hi,
>
> I've had this thread in my inbox for a while, and am now trying to
> figure out what to make of it. I still have only very limited
> experience with screenreaders and ARIA...
>
> I recently read Filament Group's Tooltip chapter from their new book,
> and their they recommend to use role="application" on the body element
> for the ARIA attributes on tooltips to be useful. I've been wondering
> if we should do that only for jQuery UI's tooltip widget, or rather
> for all widgets.
>
> I tried to follow the discussion here, but can't extract a
> recommendation to follow.
>
> Regards

> Jörn

Rich Caloggero

unread,
Mar 30, 2010, 5:16:45 PM3/30/10
to jquer...@googlegroups.com
>... , but if that also makes any other text on the

page inaccessiable, you do more damage then actually improving
anything.

Agreed.

I think the role="application" on the body element would be for a true
stand-alone web application. For instance, a mail reader which emulated
outlook express. In windows guis, all controls are tabbable, and those which
need to be read are essentially textareas or equivalent on-line text
controls, or other focusable controls. You could conceivably build the same
sort of thing in HTML+ARIA+javascript.

For any page where you want mixed content (a web page where you might drop
in a widgit or two - which seems like the most common use case for any UI
library), then you'd need role="widgit" or different semantics on the
application role.

-- R

----- Original Message -----
From: "J�rn Zaefferer" <joern.z...@googlemail.com>
To: "jquery-a11y" <jquer...@googlegroups.com>
Sent: Tuesday, March 30, 2010 4:33 PM
Subject: Re: Screen-readers and UI modal dialog - modified test page


Thanks Rich, thats actaully a very good explanation, I had no trouble
following along.

But it also sounds to me like this is more of an unsolved problem.
Ignoring the modal dialog for a moment, what happens if we stick
role="application" on the body element as soon as the page loads?
Thats supposed to make tooltips accessiable when combined with the
right aria-attributes, but if that also makes any other text on the
page inaccessiable, you do more damage then actually improving
anything.

J�rn

> ----- Original Message ----- From: "J�rn Zaefferer"


> <joern.z...@googlemail.com>
> To: "jquery-a11y" <jquer...@googlegroups.com>
> Sent: Tuesday, March 30, 2010 3:07 PM
> Subject: Re: Screen-readers and UI modal dialog - modified test page
>
>
> Hi,
>
> I've had this thread in my inbox for a while, and am now trying to
> figure out what to make of it. I still have only very limited
> experience with screenreaders and ARIA...
>
> I recently read Filament Group's Tooltip chapter from their new book,
> and their they recommend to use role="application" on the body element
> for the ARIA attributes on tooltips to be useful. I've been wondering
> if we should do that only for jQuery UI's tooltip widget, or rather
> for all widgets.
>
> I tried to follow the discussion here, but can't extract a
> recommendation to follow.
>
> Regards

> J�rn

Reply all
Reply to author
Forward
0 new messages