*>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.
----- Original Message ----- From: "E.J. Zufelt" <li...@zufelt.ca> To: <jquery-a11y@googlegroups.com> Sent: Thursday, February 18, 2010 4:15 PM Subject: Re: Screen-readers and UI modal dialog - modified test page
> 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.
>> 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" >> <feat...@furtherahead.com
>> To: <jquery-a11y@googlegroups.com> >> Sent: Thursday, February 18, 2010 3:33 PM >> Subject: Re: Screen-readers and UI modal dialog
>>>> 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?
>>> -- >>> 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 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 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.
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: <jquery-a11y@googlegroups.com> Sent: Thursday, February 18, 2010 4:30 PM Subject: Re: Screen-readers and UI modal dialog
> 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.
> On 2010-02-18, at 4:18 PM, Rich Caloggero wrote:
>>> 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.
>> ----- Original Message ----- From: "E.J. Zufelt" <li...@zufelt.ca> >> To: <jquery-a11y@googlegroups.com> >> Sent: Thursday, February 18, 2010 4:07 PM >> Subject: Re: Screen-readers and UI modal dialog
>>> 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.
>>>> 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: <jquery-a11y@googlegroups.com> >>>> Sent: Thursday, February 18, 2010 2:53 PM >>>> Subject: Re: Screen-readers and UI modal dialog
>>>>> 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.
>>>>> On 2010-02-18, at 2:24 PM, Derek Featherstone wrote:
>>>>>> 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?
>>>>>> -- >>>>>> 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 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 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 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,
> *>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
> ----- Original Message ----- From: "E.J. Zufelt" <li...@zufelt.ca> > To: <jquery-a11y@googlegroups.com> > Sent: Thursday, February 18, 2010 4:15 PM > Subject: Re: Screen-readers and UI modal dialog - modified test page
>> 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.
>>> 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" <feat...@furtherahead.com
>>> To: <jquery-a11y@googlegroups.com> >>> Sent: Thursday, February 18, 2010 3:33 PM >>> Subject: Re: Screen-readers and UI modal dialog
>>>>> 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?
>>>> -- >>>> 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 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 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 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 > .
> 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.
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?
> 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: <jquery-a11y@googlegroups.com> > Sent: Thursday, February 18, 2010 4:30 PM > Subject: Re: Screen-readers and UI modal dialog
>> 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.
>> On 2010-02-18, at 4:18 PM, Rich Caloggero wrote:
>>>> 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.
>>> ----- Original Message ----- From: "E.J. Zufelt" <li...@zufelt.ca> >>> To: <jquery-a11y@googlegroups.com> >>> Sent: Thursday, February 18, 2010 4:07 PM >>> Subject: Re: Screen-readers and UI modal dialog
>>>> 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.
>>>>> 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: <jquery-a11y@googlegroups.com> >>>>> Sent: Thursday, February 18, 2010 2:53 PM >>>>> Subject: Re: Screen-readers and UI modal dialog
>>>>>> 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.
>>>>>> On 2010-02-18, at 2:24 PM, Derek Featherstone wrote:
>>>>>>> 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?
>>>>>>> -- >>>>>>> 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
*>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>
----- Original Message ----- From: "E.J. Zufelt" <li...@zufelt.ca> To: <jquery-a11y@googlegroups.com> Sent: Thursday, February 18, 2010 5:30 PM Subject: Re: Screen-readers and UI modal dialog
> 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?
> 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.
>> ----- Original Message ----- From: "E.J. Zufelt" <li...@zufelt.ca> >> To: <jquery-a11y@googlegroups.com> >> Sent: Thursday, February 18, 2010 4:30 PM >> Subject: Re: Screen-readers and UI modal dialog
>>> 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.
>>> On 2010-02-18, at 4:18 PM, Rich Caloggero wrote:
>>>>> 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.
>>>> ----- Original Message ----- From: "E.J. Zufelt" <li...@zufelt.ca> >>>> To: <jquery-a11y@googlegroups.com> >>>> Sent: Thursday, February 18, 2010 4:07 PM >>>> Subject: Re: Screen-readers and UI modal dialog
>>>>> 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.
>>>>>> 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: <jquery-a11y@googlegroups.com> >>>>>> Sent: Thursday, February 18, 2010 2:53 PM >>>>>> Subject: Re: Screen-readers and UI modal dialog
>>>>>>> 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.
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? http://tinyurl.com/yegdmgh
> *>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
> ----- Original Message ----- From: "E.J. Zufelt" <li...@zufelt.ca> > To: <jquery-a11y@googlegroups.com> > Sent: Thursday, February 18, 2010 5:30 PM > Subject: Re: Screen-readers and UI modal dialog
>> 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?
>> 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.
>>> ----- Original Message ----- From: "E.J. Zufelt" <li...@zufelt.ca> >>> To: <jquery-a11y@googlegroups.com> >>> Sent: Thursday, February 18, 2010 4:30 PM >>> Subject: Re: Screen-readers and UI modal dialog
>>>> 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.
>>>> On 2010-02-18, at 4:18 PM, Rich Caloggero wrote:
>>>>>> 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.
>>>>> ----- Original Message ----- From: "E.J. Zufelt" <li...@zufelt.ca> >>>>> To: <jquery-a11y@googlegroups.com> >>>>> Sent: Thursday, February 18, 2010 4:07 PM >>>>> Subject: Re: Screen-readers and UI modal dialog
>>>>>> 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.
>>>>>>> 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: <jquery-a11y@googlegroups.com> >>>>>>> Sent: Thursday, February 18, 2010 2:53 PM >>>>>>> Subject: Re: Screen-readers and UI modal dialog
>>>>>>>> Derek wrote:
>>>>>>>>> Ultimately a role of application or widget on a containing
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.
On Fri, Feb 19, 2010 at 12:10 AM, E.J. Zufelt <li...@zufelt.ca> wrote: > 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 > http://zufelt.ca > Follow me on Twitter > http://twitter.com/ezufelt
> On 2010-02-18, at 4:47 PM, Rich Caloggero wrote:
> *>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
> ----- Original Message ----- From: "E.J. Zufelt" <li...@zufelt.ca> > To: <jquery-a11y@googlegroups.com> > Sent: Thursday, February 18, 2010 4:15 PM > Subject: Re: Screen-readers and UI modal dialog - modified test page
> 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
> -- > 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 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.
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.zaeffe...@googlemail.com> To: "jquery-a11y" <jquery-a11y@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
On Fri, Feb 19, 2010 at 12:10 AM, E.J. Zufelt <li...@zufelt.ca> wrote: > 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 > http://zufelt.ca > Follow me on Twitter > http://twitter.com/ezufelt
> On 2010-02-18, at 4:47 PM, Rich Caloggero wrote:
> *>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
> ----- Original Message ----- From: "E.J. Zufelt" <li...@zufelt.ca> > To: <jquery-a11y@googlegroups.com> > Sent: Thursday, February 18, 2010 4:15 PM > Subject: Re: Screen-readers and UI modal dialog - modified test page
> 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
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.
On Tue, Mar 30, 2010 at 10:19 PM, Rich Caloggero <r...@mit.edu> wrote: > 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.zaeffe...@googlemail.com> > To: "jquery-a11y" <jquery-a11y@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
> On Fri, Feb 19, 2010 at 12:10 AM, E.J. Zufelt <li...@zufelt.ca> wrote:
>> 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 >> http://zufelt.ca >> Follow me on Twitter >> http://twitter.com/ezufelt
>> On 2010-02-18, at 4:47 PM, Rich Caloggero wrote:
>> *>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
>> ----- Original Message ----- From: "E.J. Zufelt" <li...@zufelt.ca> >> To: <jquery-a11y@googlegroups.com> >> Sent: Thursday, February 18, 2010 4:15 PM >> Subject: Re: Screen-readers and UI modal dialog - modified test page
>> 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
>... , 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.
----- Original Message ----- From: "J rn Zaefferer" <joern.zaeffe...@googlemail.com> To: "jquery-a11y" <jquery-a11y@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
On Tue, Mar 30, 2010 at 10:19 PM, Rich Caloggero <r...@mit.edu> wrote: > 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.zaeffe...@googlemail.com> > To: "jquery-a11y" <jquery-a11y@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
> On Fri, Feb 19, 2010 at 12:10 AM, E.J. Zufelt <li...@zufelt.ca> wrote:
>> 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 >> http://zufelt.ca >> Follow me on Twitter >> http://twitter.com/ezufelt
>> On 2010-02-18, at 4:47 PM, Rich Caloggero wrote:
>> *>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,
