E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 10 (In chronological order)

From: Sean Keegan
Date: Fri, Jul 03 2015 1:56AM
Subject: Time-out modal with alertdialog
No previous message | Next message →

I am working on a time-out modal that is triggered after 10 minutes of no
activity within an application. There is an empty parent <div> into which
the time out modal is loaded when the time limit is triggered. This modal
is comprised of a descendent <div> with role=alertdialog and tabindex=0.

During testing, I noticed JAWS and NVDA will announce the modal window if
focus is on an input field, the user is typing, or if there is no activity
by the user when the time period elapses. However, if navigating the page
using the virtual buffer commands (such as a Say All), there is no
notification to the user by the screen-reader that the modal has been
triggered.

A colleague and I are debating the role=alertdialog and if there may need
to be a more assertive notification when the time out modal is triggered.
Would adding aria-live=assertive to a <div> that already contains
role=alertdialog be redundant or should the aria-live property be applied
to the parent <div> so that it can monitor all descendents?

Take care,
Sean

From: Bryan Garaventa
Date: Fri, Jul 03 2015 5:31PM
Subject: Re: Time-out modal with alertdialog
← Previous message | Next message →

Technically the alertdialog role should fire a system alert when the container is added to the DOM via element.appendChild/replaceChild or element.innerHTML, or when switched into visibility by changing display:none to 'block' or 'inline'.

This might not be working properly though.

Try putting role="alert" on the parent Div, and change the dynamically added container from role="alertdialog" to role="dialog" and see what happens when this is added to the Alert container element.

It will be important to set all of the required attributes however, such as those documented at
http://whatsock.com/training/matrices/#dialog
And to follow the correct setting of focus when it opens.

There is no need to set tabindex="0" on the parent Dialog container, since it's the active elements within that should be focusable. E.G the OK button or whatever. If you need to set focus to a Dialog container, it works better to use tabindex="-1", then manage focus using forward and reverse circular tabbing within the dialog from that point on.

Hopefully this helps a bit.

Best wishes,
Bryan

From: _mallory
Date: Sun, Jul 05 2015 1:18PM
Subject: Re: Time-out modal with alertdialog
← Previous message | Next message →

Bryan, a (general, not specific to Sean's) question:
if I have a "popup" (client request) which contains almost exlusively
text (help text), with no OK button but we do add a "close" button,
is this the best thing to set focus to, or should in this case the
dialog itself be focussed on? All the other usual attributes etc are
set.

Sometimes based on language/country combinations there is a focusable
email link, but this is not reliably there for all users.

_mallory

From: Bryan Garaventa
Date: Sun, Jul 05 2015 6:42PM
Subject: Re: Time-out modal with alertdialog
← Previous message | Next message →

Yes, this would fit the paradigm of a standard platform dialog, which is what the role is meant to represent.

So the role of 'dialog' sets the API mapping, aria-label or aria-labelledby sets the associated dialog title, and aria-describedby sets the dialog static text, so when focus is set to the Close button, all of this information should be announced.

If the attributes are set correctly and this information is not announced, then it's worth reporting this as a bug to the AT vender though.

From: Sean Keegan
Date: Sun, Jul 05 2015 10:38PM
Subject: Re: Time-out modal with alertdialog
← Previous message | Next message →

Hi Bryan,

Thanks for replying. I did some further investigation with aViewer and
tracked how both NVDA and JAWS were responding. Using aViewer I watched for
what happens when the time out modal happens and the alertdialog role is
indeed triggered, so it is registering in the various interfaces.

Best I can tell, this may be the result when using this specific reading
command. Using NVDA with the Say All command, I found there is about a 40
second delay between when the time out modal happens and NVDA communicates
the alert even though the alert is recognized in aViewer when it happens.
Unfortunately, using JAWS with Say All command, does not communicate
anything about the presence of the alertdialog when it happens resulting in
the application automatically closing the session after the time out period
elapses.

I will suggest modifying the attributes on the parent Div and containers to
see what happens. With NVDA, there is the notification, but it can take 40
seconds for this to be communicated during this specific type of
reading/navigation.

Thanks for the info regarding the tabindex. I have found instances of
positive tabindex values in the application and suspect tabindex=0 was
included to force the focus. Lots to work on...

Take care,
Sean


From: Bryan Garaventa < = EMAIL ADDRESS REMOVED = >
> To: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
> Cc:
> Date: Fri, 3 Jul 2015 16:31:16 -0700
> Subject: Re: [WebAIM] Time-out modal with alertdialog
> Technically the alertdialog role should fire a system alert when the
> container is added to the DOM via element.appendChild/replaceChild or
> element.innerHTML, or when switched into visibility by changing
> display:none to 'block' or 'inline'.
>
> This might not be working properly though.
>
> Try putting role="alert" on the parent Div, and change the dynamically
> added container from role="alertdialog" to role="dialog" and see what
> happens when this is added to the Alert container element.
>
> It will be important to set all of the required attributes however, such
> as those documented at
> http://whatsock.com/training/matrices/#dialog
> And to follow the correct setting of focus when it opens.
>
> There is no need to set tabindex="0" on the parent Dialog container, since
> it's the active elements within that should be focusable. E.G the OK button
> or whatever. If you need to set focus to a Dialog container, it works
> better to use tabindex="-1", then manage focus using forward and reverse
> circular tabbing within the dialog from that point on.
>
> Hopefully this helps a bit.
>
> Best wishes,
> Bryan
>
>

From: Moore,Michael (HHSC)
Date: Mon, Jul 06 2015 7:33AM
Subject: Re: Time-out modal with alertdialog
← Previous message | Next message →

This is very likely because both screen readers are reading from a virtual buffer when in say all mode. The screen reader is going to read to the end of the buffer before adding any more content. The good news is that I have not observed any actual screen reader users working with a web application in say-all mode.

Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)
(512) 574-0091 (Cell)

From: Bryan Garaventa
Date: Mon, Jul 06 2015 10:09AM
Subject: Re: Time-out modal with alertdialog
← Previous message | Next message →

That's true, one thing to note though, if the browser is firing a system alert and the AT is processing that properly, then it should be interrupting speech regardless.

If they change the attributes with role=alert on the container and add the dialog container element to that, I'm curious to know what the outcome is for them in Firefox for example where this is working correctly.

From: Birkir R. Gunnarsson
Date: Mon, Jul 06 2015 4:10PM
Subject: Re: Time-out modal with alertdialog
← Previous message | Next message →

One additional thought.
Do you hide content from all screen readers when the timeout modal
dialog pops up (assuming that it is modal)?
For maximum usability a timeout dialog should be modal and rest of
content hiddn from assistive technology/screen readers.

Set aria-hidden="true" on container containing page content when
dialog content becomes visible (this is easiest to do when dialog
modal content is appended at the end of the dom).




On 7/6/15, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
> That's true, one thing to note though, if the browser is firing a system
> alert and the AT is processing that properly, then it should be interrupting
> speech regardless.
>
> If they change the attributes with role=alert on the container and add the
> dialog container element to that, I'm curious to know what the outcome is
> for them in Firefox for example where this is working correctly.
>
>
>

From: Maraikayar Prem Nawaz
Date: Mon, Jul 06 2015 10:27PM
Subject: Re: Time-out modal with alertdialog
← Previous message | Next message →

Hope you also plan to provide an option to increase the session timeout
limit(Level A)
http://www.w3.org/TR/2008/REC-WCAG20-20081211/#time-limits-required-behaviors
<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#time-limits-required-behaviors>;

On Tue, Jul 7, 2015 at 3:40 AM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> One additional thought.
> Do you hide content from all screen readers when the timeout modal
> dialog pops up (assuming that it is modal)?
> For maximum usability a timeout dialog should be modal and rest of
> content hiddn from assistive technology/screen readers.
>
> Set aria-hidden="true" on container containing page content when
> dialog content becomes visible (this is easiest to do when dialog
> modal content is appended at the end of the dom).
>
>
>
>
> On 7/6/15, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
> > That's true, one thing to note though, if the browser is firing a system
> > alert and the AT is processing that properly, then it should be
> interrupting
> > speech regardless.
> >
> > If they change the attributes with role=alert on the container and add
> the
> > dialog container element to that, I'm curious to know what the outcome is
> > for them in Firefox for example where this is working correctly.
> >
> >
> >

From: Sean Keegan
Date: Mon, Jul 06 2015 11:41PM
Subject: Re: Time-out modal with alertdialog
← Previous message | No next message

Hi Mike,

Yes, I agree that it is unlikely that the screen-reader user would be
working in the say-all mode for a web application. It's possible that the
individual could be rechecking the entire page via say-all, but I agree
with you that it would not be a common situation (it took me two days to
figure out how to replicate the situation). Unfortunately, this was
identified as an issue in an external review and is on a "must be
addressed" list.

I am going to try Bryan's suggestions to see if there is any effect on the
delay between when the event is triggered and when it is reported by the
screen-reader. Even though NVDA does report the time out event, there is
still a 40 second delay and I do think it may be something to keep in mind
when setting the time period by which a user can provide a response.

Take care,
Sean



> From: "Moore,Michael (HHSC)" < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc:
> Date: Mon, 6 Jul 2015 13:33:45 +0000
> Subject: Re: [WebAIM] Time-out modal with alertdialog
> This is very likely because both screen readers are reading from a virtual
> buffer when in say all mode. The screen reader is going to read to the end
> of the buffer before adding any more content. The good news is that I have
> not observed any actual screen reader users working with a web application
> in say-all mode.
>
> Mike Moore
> Accessibility Coordinator
> Texas Health and Human Services Commission
> Civil Rights Office
> (512) 438-3431 (Office)
> (512) 574-0091 (Cell)
>