WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: changing focus location for screen readers

for

From: steven
Date: Feb 8, 2011 2:06AM

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





-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of adam solomon
Sent: 08 February 2011 07:54
To: WebAIM Discussion List
Subject: [WebAIM] changing focus location for screen readers

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/>;