E-mail List Archives

Search E-mail List Archives for

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

From: adam solomon
Date: Tue, Feb 08 2011 1:03AM
Subject: changing focus location for screen readers
No previous message | Next message →

Related somewhat to a mail I sent regarding updatepanels the other day (no
responses yet), though, more general, I would really like to hear your
thoughts on the following question:

A link with the text "search this site" is provided. The link, when pressed,
opens via JS the search form, which is located on the same page. I am
assuming that in order to meet accessibility needs, page focus would have to
be sent to that search form in some way. First off, please advise which
section of WCAG would be violated if focus were not sent there, rather the
user remained where he was, uninformed of the location of the search form
(the link text would indicate the purpose and theoretically he could find
it).
Now, to the nitty gritty. I have tested this with ie8 and jaws 9 and here
are the results:

1. When setting the search form to display: none at the page load. Then,
when pressing on the link, the click event (or href with JS, doesn't matter)
of the link sets the search form to display: block, and also sends the focus
via JS to the <h2> (or even text input) of the search form (in the case of
the <h2> we added tabindex="0" per aria standard which is fully supported in
ie8). The result was that focus was sent to the <h2> of the search form, but
the jaws cursor remained where it had been - namely on the link. Conclusion,
no good.

2. Same as above, except that instead of the search form being display: none
at the page load, it is visible (we set width:0,height:0 in css to hide it).
The result was that it worked - focus was sent to the header and the jaws
cursor was at the focused header. Conclusion: works.

3. Search form set to display: none at page load. click event of link opens
search form by setting display:block. href of link sends user to id of <h2>.
This seems to work, as jaws announces a quasi-postback announcement (page
has x number of links, etc.) and then jaws reads the <h2> and continues from
there. Conclusion, works.

The problem with the first solution (second list item) is that it is more
accepted to use display:none rather than width:0, height:0. The problem with
the second solution (third list item) is that using href with same page link
(hash symbol and id) makes the page jump to that location. The project
managers all refuse to work with it.

Please advise on your experiences with focus, what works, what doesn't, and
what is required from us to support accessibility.
Thanks in advance.

--
adam solomon
linkedin <http://il.linkedin.com/pub/adam-solomon/24/449/a4>;
blogix <http://adam.blogix.co.il/>;

From: steven
Date: Tue, Feb 08 2011 2:06AM
Subject: Re: changing focus location for screen readers
← Previous message | Next message →

Hi Adam,

I'm intrigued by your comment that "The problem with the second solution .
is that using href with same page link . makes the page jump to that
location. The project managers all refuse to work with it."

Being that the anchor jump is one of the few browser consistencies that
still remains today, is this really a problem that people refuse to work
with!? Has anybody got a resource that actually backs this up? I ask,
because I had toyed with animating page anchoring, but I personally found it
to be unexpected for users (though visually more interesting) and slower to
get to content than the standard jump (in this day and age I am in both
minds, as on the one hand people want things faster, but people also love
slower GUI effects such as evident in Apple products).

Regards,

Steven

From: adam solomon
Date: Tue, Feb 08 2011 2:33AM
Subject: Re: changing focus location for screen readers
← Previous message | Next message →

I stressed the fact that project managers are the problem (mainly because it
is always easier to blame someone else). I personally don't see the big
deal. But, it is not up to me. Keep in mind, as well, that the standard same
page link jumps are quite intuitive and necessary. For instance, in the w3c
documents, long as they are, you can navigate to different parts of the page
with the menu at the top of the page. However, what I am talking about is a
popup div which is usually positioned close to where the user already is,
and the jump therefore comes off as superfluous and somewhat bothersome to
the user.

On Tue, Feb 8, 2011 at 11:04 AM, steven < = EMAIL ADDRESS REMOVED = >wrote:

> Hi Adam,
>
> I'm intrigued by your comment that "The problem with the second solution .
> is that using href with same page link . makes the page jump to that
> location. The project managers all refuse to work with it."
>
> Being that the anchor jump is one of the few browser consistencies that
> still remains today, is this really a problem that people refuse to work
> with!? Has anybody got a resource that actually backs this up? I ask,
> because I had toyed with animating page anchoring, but I personally found
> it
> to be unexpected for users (though visually more interesting) and slower to
> get to content than the standard jump (in this day and age I am in both
> minds, as on the one hand people want things faster, but people also love
> slower GUI effects such as evident in Apple products).
>
> Regards,
>
> Steven
>
>
>
>
>
>

From: Jason Kiss
Date: Tue, Feb 08 2011 2:57AM
Subject: Re: changing focus location for screen readers
← Previous message | Next message →

On 08/02/11 20:53, adam solomon wrote:
> 1. When setting the search form to display: none at the page load. Then,
> when pressing on the link, the click event (or href with JS, doesn't matter)
> of the link sets the search form to display: block, and also sends the focus
> via JS to the<h2> (or even text input) of the search form (in the case of
> the<h2> we added tabindex="0" per aria standard which is fully supported in
> ie8). The result was that focus was sent to the<h2> of the search form, but
> the jaws cursor remained where it had been - namely on the link. Conclusion,
> no good.

Not sure if this will help, but a similar problem raised its head with
Ginader's Accessible Tabs plugin (see comments starting at
http://blog.ginader.de/archives/2009/02/07/jQuery-Accessible-Tabs-How-to-make-tabs-REALLY-accessible.php#serendipity_comment_580).
It turns out that programmatically setting focus to an element set to
display:block after previously having been hidden using display:none
didn't actually fully move the JAWS cursor to the intended focus
position. Some of this I've documented at
http://www.accessibleculture.org/research/accessible-tabs/. In brief, it
appears that focus was getting set before JAWS had updated its virtual
buffer, so while browser focus moved as expected, JAWS wasn't able to
fully move focus to the intended target.

With Ginader's Accessible Tabs plugin, this was solved by postponing the
point at which focus was programmatically set, based on the types of
events that trigger a virtual buffer update (see
https://reference.ssbbartgroup.com/index.php/Client_Side_Content_Changes_in_JAWS#When_Client-Side_Content_Changes)
such that the JAWS virtual buffer was already updated with the newly
visible element. This may or may not work for you.

I've also found in playing around that adding a short delay using
setTimeout(), e.g., on the order of 200ms, before setting focus can
sometimes work to allow the JAWS virtual buffer enough time to update. I
don't particularly like this approach, but it has worked for me in the
past, and being a very short timeout, is mostly imperceptible to the
user. I'm not quite sure what is going on, but wonder if it has to do
with the increased efficiency of JavaScript engines in newer browsers
somehow working too fast for JAWS and its virtual buffer. But I'd love
to be educated if anyone has some insight.

Anyway, just a couple of ideas.

Cheers,

Jason

--
Jason Kiss
Web: www.accessibleculture.org
Mobile: 021 929 238
Email: = EMAIL ADDRESS REMOVED =
Twitter: @jkiss

From: Jared Smith
Date: Tue, Feb 08 2011 8:57AM
Subject: Re: changing focus location for screen readers
← Previous message | Next message →

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

From: adam solomon
Date: Tue, Feb 08 2011 9:09AM
Subject: Re: changing focus location for screen readers
← Previous message | Next message →

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 ADDRESS 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
>

From: Jason Kiss
Date: Tue, Feb 08 2011 1:03PM
Subject: Re: changing focus location for screen readers
← Previous message | Next message →

On 09/02/11 05:06, adam solomon wrote:
> 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).

Using width and height of 0 might also negatively affect those screen
reader users who are not blind, for example those who use a screen
reader to help with a reading or learning difficulty. If the search form
is not hidden from a screen reader, the screen reader will announce the
search form's <h2>, label and inputs, but the user won't be able to see
them, which could be confusing.

And it might be confusing or frustrating to sighted keyboard users who
will have extra presses of the TAB key required (one for the <h2> with
tabindex=0, one for the text input, and one for the submit input)
whenever they TAB past the search form, all the while not seeing what
these presses of the TAB key are setting focus to. This could be solved
by setting tabindex=-1 on each of the elements to take them out of the
TAB order while the search form is not visible, and then setting
tabindex back to 0 when visible again.

Still, I think that if one is hiding interactive content like a search
form from sighted users, it should be hidden from all users, and that
finding a way to make display:none work is the best bet.


Jason Kiss
Web: www.accessibleculture.org
Mobile: 021 929 238
Email: = EMAIL ADDRESS REMOVED =
Twitter: @jkiss

From: adam solomon
Date: Wed, Feb 09 2011 4:48AM
Subject: Re: changing focus location for screen readers
← Previous message | No next message

I tried utilizing the info from Jason's links (great stuff). I did the
following:
tabindex on header in hidden div (display:none).
added dummy span element on page with classname.
href on link is a js function which first opens the hidden div (display:
block), then changes the classname of the dummy span element, then does a
settimeout of 200 milliseconds which then changes the focus to the header.
Seems to work like a charm.

Thanks for all the feedback. It always helps.

*WebAIM Discussion List RULES!! *

On Tue, Feb 8, 2011 at 10:03 PM, Jason Kiss < = EMAIL ADDRESS REMOVED = >wrote:

> On 09/02/11 05:06, adam solomon wrote:
> > 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).
>
> Using width and height of 0 might also negatively affect those screen
> reader users who are not blind, for example those who use a screen
> reader to help with a reading or learning difficulty. If the search form
> is not hidden from a screen reader, the screen reader will announce the
> search form's <h2>, label and inputs, but the user won't be able to see
> them, which could be confusing.
>
> And it might be confusing or frustrating to sighted keyboard users who
> will have extra presses of the TAB key required (one for the <h2> with
> tabindex=0, one for the text input, and one for the submit input)
> whenever they TAB past the search form, all the while not seeing what
> these presses of the TAB key are setting focus to. This could be solved
> by setting tabindex=-1 on each of the elements to take them out of the
> TAB order while the search form is not visible, and then setting
> tabindex back to 0 when visible again.
>
> Still, I think that if one is hiding interactive content like a search
> form from sighted users, it should be hidden from all users, and that
> finding a way to make display:none work is the best bet.
>
>
> Jason Kiss
> Web: www.accessibleculture.org
> Mobile: 021 929 238
> Email: = EMAIL ADDRESS REMOVED =
> Twitter: @jkiss
>