Re: Using tab stop on important text

>>Mike wrote: In example, think of a properly coded page using aria-describedby to associate the explanatory text with an input field by ID. Would it be possible to have an extension that set a tabstop for any aria-describedby information? If the user had the ability to put any such text in a consistent tabindex location (either before or after the field with the related ID), that could serve the purpose.

There are two interdependent parts – 1) Add-On and 2) Presence of
aria-describedby. Add-ons in certain situations may not work—they
cannot be downloaded in secure environments, and some users may not
want to customize their browsers beyond a certain point.
Extending your thought, could browsers implement:
1. A shortcut key that applies tabindex attributes (zero) on important
text. This uses the underlying html markup and not aria-describedby.
Basically, the browser adds a tabindex attribute of zero to html
headers, making them keyboard focusable. Text in red (like ‘Note,’
‘Warning,’ 'Error Messages,' etc.), within <em> and <strong>, etc.,
can similarly be indexed and made keyboard focusable.
2. A shortcut key that applies tabindex attributes on instructional
text. This text can be programmatically associated with a form field
using aria-describedby, a point made in your post. This can be further
extended to text adjacent to form fields, text describing an active
image, etc.
In 1 and 2, users can either opt in or out.
Thanks for the input.

Phil wrote:
>>Interesting, do you have any studies or data that support your claim? What IF is doesn't accommodate more users?

The claims are based on feedback from internal applications that use
this technique. When real users want a tab stop on header text, would
anyone refer to data? Your points could be valid, and even if we
statistically prove ‘that tab stops on headers encumbers users,’ it
will not make a difference to those who already use it.

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

I disagree. A keyboard only user with learning disability will have
other reasons first, assuming we consider tab stops on headers as an
issue. Not making the skip link visible, wacked out tab order, missing
focus indicators, blatant discrimination by exposing title attributes
to mouse and screen reader users only, etc. That is being
unproductive.

Thanks,
Devarshi

On 11/29/11, Michael Gower <michael.gower@ca.ibm.com> wrote:
> Phill said: "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?"
>
> In my experience, in situations where headings are set as tab stops, the
> focus rectangle automatically occurs around them, which provides
> sufficient orientation for a user.
> If the only added tab stops were headings, I don't think there would be an
> onerous amount of effort forced on any any user; headings don't occur
> frequently enough. But as soon as you have chunks of instructional text
> with tab stops, you rapidly impede normal keyboard operation. I'm not
> advocating for tab stop for headings; just noting that such a specific
> implementation should not pose undue time on task.
>
> I wonder if part of what Devarshi is seeking could be accomplished by an
> add-on a browser that added in items to the tab index based on browser
> settings. In example, think of a properly coded page using
> aria-describedby to associate the explanatory text with an input field by
> ID. Would it be possible to have an extension that set a tabstop for any
> aria-describedby information? If the user had the ability to put any such
> text in a consistent tabindex location (either before or after the field
> with the related ID), that could serve the purpose.
>
> As ARIA adoption progresses, I'm anticipating many such keyboard
> enhancements through plug-ins, such as those that already exist in the
> Firefox Accessibility Extensions.
>
> Regards,
> Mike Gower
>
>
>
>
>
> From:   Phill Jenkins <pjenkins@us.ibm.com>
> To:     Devarshi Pant <devarshipant@gmail.com>
> Cc:     w3c-wai-ig@w3.org
> Date:   11/29/2011 12:20 PM
> Subject:        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

Received on Wednesday, 30 November 2011 17:15:20 UTC