--
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.
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/
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>
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
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
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
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>
>> 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
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.
---
> 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
>
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/
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?
---
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 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
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
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?
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
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
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.
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
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
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.
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.
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
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 scre