WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: changing focus location for screen readers

for

From: adam solomon
Date: Feb 8, 2011 2:33AM

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