WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: changing focus location for screen readers

for

From: adam solomon
Date: Feb 8, 2011 9:09AM

In the case of the search form I assumed that with width and height 0 the
screen reader would have it in the buffer, thus solving the focus problem.
The fact a screen reader user could always get to it shouldn't bother
anyone. Of course with dialog messages that wouldn't work (since the message
should only be readable when they are relevant).

On Tue, Feb 8, 2011 at 5:54 PM, Jared Smith < <EMAIL REMOVED> > wrote:

> These findings mirror my own. Simply setting focus() with JavaScript
> (even with tabindex values of 0 or -1) is not sufficient for JAWS in
> many cases. Setting a delay often works, but not universally (for
> example, a delay of even a full second will occasionally fail). One
> solution that seems to work is setting focus to a form control within
> the element. Because the original question referred to a search
> dialog, this might work well - and may facilitate non-screen reader
> usability as well. I can't remember for sure, but I think setting
> focus to a link (perhaps the dialog's "close" link?) worked more
> often, but not all the time. But these certainly are not viable
> options all the time.
>
> I generally recommend placing the markup for the dialog immediately
> after the control that opens it. This way the user is more likely to
> stumble upon it if/when JAWS fails to set focus.
>
> Do note that content with height and width of 0 is not universally
> hidden in all screen readers. I do not see this as a viable option.
> CSS display:none should be used to truly hide content.
>
> This is a problem I run into on nearly every site we evaluate. These
> types of dialog boxes are becoming pervasive and with JAWS seemingly
> unable to understand a basic focus() function, I think the best option
> is for us to simply code it with the standard focus() and petition
> Freedom Scientific to fix this bug.
>
> Another issue that often arises with such dialog boxes is the user
> tabbing back to the underlying content while the dialog remains open
> in the foreground. Steve Faulkner has proposed a "modal" attribute to
> HTML5 that would perfectly address all of these issues -
>
> http://lists.w3.org/Archives/Public/public-html-wg-issue-tracking/2011Jan/0013.html
>
> Jared Smith
> WebAIM.org
>