E-mail List Archives
Re: changing focus location for screen readers
From: adam solomon
Date: Feb 9, 2011 4:48AM
- Next message: Keith (mteye): "Re: does datepicker have to be accessible"
- Previous message: Andrew Kirkpatrick: "Re: PDF Conversion tools"
- Next message in Thread: None
- Previous message in Thread: Jason Kiss: "Re: changing focus location for screen readers"
- View all messages in this Thread
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 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 REMOVED>
> Twitter: @jkiss
>
- Next message: Keith (mteye): "Re: does datepicker have to be accessible"
- Previous message: Andrew Kirkpatrick: "Re: PDF Conversion tools"
- Next message in Thread: None
- Previous message in Thread: Jason Kiss: "Re: changing focus location for screen readers"
- View all messages in this Thread