RE: Using tab stop on important text

If I could perhaps re-state the original problem to make sure I understand
it correctly...
 
I think the requirement is to provide a mechanism for users of screen
readers in particular, to ensure they hear a chunk of explanatory text which
is associated to a number of related fields. 
 
>From the original post...
 
While I appreciate that putting any important information prior to the start
of the form on the page is best for accessibility this is not always
possible.

 

Firstly, I would challenge this belief as there are many ways of placing
text at any point in a document which would only be read by screen readers -
positioning a zero height div containing the text offscreen for one.  This
could provide the most effective solution in this situation. Obviously if
the text is repeated for other users at some other point there will be
repeatition but at least the information has been conveyed at a sensible
point in the page flow, which it sounds like it may not be otherwise.
Indeed, it would be interesting to know where this text would be placed in
any case. 

 

Secondly, again from the original email:

 

Also while I would like to be implementing fieldsets and the function of the
legend to highlight these initial instructions I'm conscious that:

1. In some screenreader browser combinations the legend isn't read at all.

2. Some of these instructions are quite long and perhaps unsuitable for use
in a legend, especially where the legend may be read out before each label.

 

I'm not sure which browser / screen reader combination doesn't read legends
but accepting that this is true, I don't believe that just because Legends
may not be read at all in certain combinations of browser / screen reader is
a reason not to do this. Yes we need to take these type of problems into
consideration when looking at how best to address a particular problem, but
this sounds more like a bug than an accessibility issue to me.

 

The same comment applies to the legend being read aloud before each label
within the fieldset. I'm not as familiar with the UAAG and ATAG as I'm sure
others on the list will be, but this doesn't sound right to me. Maybe
somebody could clarify what the correct behaviour should be regarding
legends.

 

I'm also not sure that using ARIA describedby would actually help here
because you'd need to associate the chunk of text with every field which
would be read out when the user tabbed to each field by a screen reader
(when supported).

 

In short, I think before we try and invent some new technique to address
this problem we should establish first that the existing guidelines and
techniques are not sufficient. In this situation though, I don't think this
is the case and the current guidelines and techniques do provide a perfectly
good solution. At least based on my understanding of the purpose of legend
and fieldsets and how they should be implemented anyway. 

 

Cheers

Ian

 

 

 


  _____  

From: Michael Gower [mailto:michael.gower@ca.ibm.com] 
Sent: 29 November 2011 20:36
To: w3c-wai-ig@w3.org
Subject: Re: Using tab stop on important text



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