Re: Using tab stop on important text

Devarshi,
when you say: "A keyboard only user, without an AT, would be benefitted. 
Users with learning disabilities may learn better. If
it accommodates more users, it should be encouraged."

Interesting, do you have any studies or data that support your claim? What 
IF is doesn't accommodate more users?  I'm trying to envision how a 
sighted user (non magnifier, non screen reader, non-AT user) would benefit 
from tab stops on elements that do not require interaction, like headings 
and explanatory text in forms?  Seems to me they would NOT use the 
keyboard to direct their eyes to what to read, and would probably be even 
more confused when the cursor did stop on headings and text when their 
eyes would already be reading ahead (or behind).  I wouldn't think that 
the blinking cursor is that effective alone in getting their attention 
without any additional AT doing some voice or highlighting.  So, what 
benefit is there for the keyboard (non-AT users) to stop on headings that 
are already bold and possible colored/styled differently than the rest of 
the text?

And what about the keyboard user without a learning disability that is 
trying to be more productive that now has to tab a bunch more times to get 
to the interactive elements? He or she will hate that web application for 
doing that to them.

Regards,
Phill Jenkins, 




From:   Devarshi Pant <devarshipant@gmail.com>
To:     Jonathan Avila <jon.avila@ssbbartgroup.com>
Cc:     w3c-wai-ig@w3.org
Date:   11/29/2011 11:30 AM
Subject:        Re: Using tab stop on important text



*Jonathan wrote: Adding additional tab stops to headings would only
add to the number of times to the user must tab. Providing other ways
for keyboard users to
navigate other than tab would be preferential. *

Yes, putting a tab stop would add to the number of stops, but do we
know for sure that keyboard only users are inconvenienced with added
tab stops? You are correct, there should be other ways—I hope browser
vendors could provide a solution.

Leon—I agree with you. I have often seen instructional text placed
between form fields, which is often difficult to get to, especially
when you don’t know where to arrow down from when running a screen
reader. Users generally tab when filling out forms, and a tab index of
zero, when applied judiciously, does accommodate user groups. I was
hoping we can get some direction on a WCAG technique (the intent of
this post) that can set the parameters (when, where, how, etc.) for
those who are interested.

*Phil wrote: Sounds to me like you're trying to play the role of
assistive technology
when you BOTH make it a heading AND add a tabindex.  Requiring the author
/ developer to add even more mark-up in addition to the heading tag is not
the best approach in my opinion.  Shouldn't AT developers take on any
additional responsibility for the behavior you are suggesting if not
already provided? *

AT vendors already expose html headings, so I am not sure how they may
help in this regard, considering we put a tab index attribute. Yes,
project teams / developers should ideally be doing this, and here is
why: Adding a tab index attribute (of just *zero*) in certain designs
could help users who tab. A keyboard only user, without an AT, would
be benefitted. Users with learning disabilities may learn better. If
it accommodates more users, it should be encouraged.

Thanks,
Devarshi

On 11/28/11, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote:
> [Devarshi wrote] 1. Page headers could have a tabindex attribute of zero
> (sequential focus navigation) allowing keyboard only users to access
> important sections in the page, without having to tab extensively.
>
> Adding additional tab stops to headings would only add to the number of
> times to the user must tab.  Providing other ways for keyboard users to
> navigate other than tab would be preferential.
>
> I do believe it is helpful to place error messages as tab stops.  Other
> scrolling areas such as license text would also need to be tab stops in
> order for users of speech recognition to be able to scroll them with 
voice
> commands.  Read only fields that are enabled should also be keyboard
> accessible.
>
> Jonathan