You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Andrew Robinson <an...@gmail.com> on 2008/03/18 19:18:13 UTC
[Trinidad] implementing tabIndex attributes on select components
On Tue, Mar 18, 2008 at 11:28 AM, Gabrielle Crawford
<ga...@oracle.com> wrote:
> I know this has been considered many times in the past, but not
> implemented due to complexity.
What complexity are you referring to? Could you please provide
concrete examples? Thanks.
> When you know the details of the implementation, can you start a new
> thread with [Trinidad] in the subject?
Done, but kept the reply ID intact for threaded email reading.
> How will it work with stamping,
> components with multiple tab stops, etc.
Tab indexes do not have to be unique. Browsers support this as it is a
w3c requirement.
Example:
<a href="#" tabindex="5">
<input type="checkbox" tabindex="5" />
<input type="text" tabindex="5" />
</a>
<a href="#" tabindex="7">
<input type="checkbox" tabindex="7" />
<input type="text" tabindex="7" />
</a>
<a href="#" />
The browser will tab to the first element with 5 first, then to each
element with 5 next. After all of the 5's are visited it will go to
the 7's as there are none with a tab index of 6.
The last anchor gets a default tab stop that will be focused after
every element that has an explicit tab stop has already been visited.
So stamping is not an issue if implemented correctly (all components
in a table are given the same tab index). If users want different tab
indexes per component, per row, the tabIndex supports EL, so users can
"easily" program around this problem by incrementing something like a
counter in a backing bean. Example:
<tr:commandLink tabIndex="1" />
<tr:table varStatus="_status" ...>
<tr:column>
<tr:commandLink tabIndex="#{_status.index + 2}" />
</tr:column>
<tr:column>
<tr:commandLink tabIndex="#{_status.index + 3}" />
</tr:column>
</tr:table>
or:
<tr:commandLink tabIndex="#{bean.nextTabIndex}" />
<tr:table>
<tr:column>
<tr:commandLink tabIndex="#{bean.nextTabIndex}" />
</tr:column>
<tr:column>
<tr:commandLink tabIndex="#{bean.nextTabIndex}" />
</tr:column>
</tr:table>
Please see the specification for more information on the tabIndex:
http://www.w3.org/TR/html4/interact/forms.html#adef-tabindex
Re: [Trinidad] implementing tabIndex attributes on select components
Posted by Andrew Robinson <an...@gmail.com>.
Okay, based on Gab's and Andy's input, I started a WIKI:
http://wiki.apache.org/myfaces/CustomTabOrder
It is *very* primitive at the moment, but I wanted it to spark a
discussion. If you have another concrete option, just add it to the
wiki. I guess we can discuss the options in this thread for now.
-Andrew
On Sat, Mar 22, 2008 at 9:51 AM, Andrew Robinson
<an...@gmail.com> wrote:
> Andy,
>
> I will pause development, and write up a WIKI. The big problem with tab indexes is tables or extra components that people don't want to tab to (skipping over an advertisement link for example). Tables tab left to right, sometimes people want newspaper style tabs - top to bottom then left to right.
>
> I think that perhaps we can discuss different approaches on a wiki that could make development easier than having to set a tab index on every component. I'll start one within the week that has different options, with pros and cons so that we can have a discussion.
>
> Thanks,
> Andrew
>
>
>
>
>
> On Sat, Mar 22, 2008 at 7:31 AM, Andy Schwartz <an...@gmail.com> wrote:
>
> >
> > > So if I have a log in form, the tab indexes would probably be:
> > >
> > > user name: 1
> > > password: 2
> > > submit: 3
> > >
> > > And then everything else would not have one. This way all the
> > > "template" components would be tabbed, just not first.
> >
> > In this particular use case it sounds like you actually like the
> > natural tab order of the form (user name, password, submit), but want
> > to make life easier for the end user by placing the focus in the user
> > name field when the page is loaded. I think that, rather than mucking
> > with tab indicies, a better solution to this problem would be to take
> > advantage of tr:document's initialFocusId attribute. IIRC
> > initialFocusId is not currently honored in the default accessibility
> > mode, which makes this attribute somewhat less useful, but I think we
> > should revisit this decision - ie. I think that we should start
> > honoring initialFocusId in the default accessibility mode.
> >
> > Andy
> >
>
>
Re: [Trinidad] implementing tabIndex attributes on select components
Posted by Andrew Robinson <an...@gmail.com>.
Andy,
I will pause development, and write up a WIKI. The big problem with tab
indexes is tables or extra components that people don't want to tab to
(skipping over an advertisement link for example). Tables tab left to right,
sometimes people want newspaper style tabs - top to bottom then left to
right.
I think that perhaps we can discuss different approaches on a wiki that
could make development easier than having to set a tab index on every
component. I'll start one within the week that has different options, with
pros and cons so that we can have a discussion.
Thanks,
Andrew
On Sat, Mar 22, 2008 at 7:31 AM, Andy Schwartz <an...@gmail.com>
wrote:
> > So if I have a log in form, the tab indexes would probably be:
> >
> > user name: 1
> > password: 2
> > submit: 3
> >
> > And then everything else would not have one. This way all the
> > "template" components would be tabbed, just not first.
>
> In this particular use case it sounds like you actually like the
> natural tab order of the form (user name, password, submit), but want
> to make life easier for the end user by placing the focus in the user
> name field when the page is loaded. I think that, rather than mucking
> with tab indicies, a better solution to this problem would be to take
> advantage of tr:document's initialFocusId attribute. IIRC
> initialFocusId is not currently honored in the default accessibility
> mode, which makes this attribute somewhat less useful, but I think we
> should revisit this decision - ie. I think that we should start
> honoring initialFocusId in the default accessibility mode.
>
> Andy
>
Re: [Trinidad] implementing tabIndex attributes on select components
Posted by Andy Schwartz <an...@gmail.com>.
> So if I have a log in form, the tab indexes would probably be:
>
> user name: 1
> password: 2
> submit: 3
>
> And then everything else would not have one. This way all the
> "template" components would be tabbed, just not first.
In this particular use case it sounds like you actually like the
natural tab order of the form (user name, password, submit), but want
to make life easier for the end user by placing the focus in the user
name field when the page is loaded. I think that, rather than mucking
with tab indicies, a better solution to this problem would be to take
advantage of tr:document's initialFocusId attribute. IIRC
initialFocusId is not currently honored in the default accessibility
mode, which makes this attribute somewhat less useful, but I think we
should revisit this decision - ie. I think that we should start
honoring initialFocusId in the default accessibility mode.
Andy
Re: [Trinidad] implementing tabIndex attributes on select components
Posted by Andy Schwartz <an...@gmail.com>.
Blake, Andrew -
> I preferred to wait until we had a good set
> of concrete focus management use cases.
This was my main question after reading the Andrew's wiki page - I
want to be sure to understand the use cases that we are trying to
address before moving forward with a solution. Many use cases can be
addressed by simpler solutions, eg:
- The login page initial focus case can be addressed by tr:document
initialFocusId.
- The skip advertising/chrome use case can be addressed by improved
skip link support.
- The newspaper-style column-based tab traversal can be addressed by
using multi-column panelFormLayouts, or similar dom structures.
We should at least consider whether such solutions meet our
requirements before deciding to add new functionality.
Andy
Re: [Trinidad] implementing tabIndex attributes on select components
Posted by Blake Sullivan <bl...@oracle.com>.
Further elaborating on what Andy wrote, the reason why Trinidad has
never supported tab index directly is that tab index is lame. In
addition to the reasons that Andy listed, tab index has real problems
when composing content from multiple authors (in the simplest case
jsp:include), as there is no way for the authors to collaborate on the
correct indices to use. Even specifying a tab-base on the locations
where external content is included either hacking the ResponseWriter to
modify the actual tab index written has potential problems with the
limited tabindex space (0 - 32767) unless multiple passes are used.
Even then, if the tab indices are packed too tightly together a PPR
request that adds new items to be inserted into the tab order adds
complexity, as it can require the shifting of existing indices to make
space for the new items. All of this ignores sources of raw HTML
content, such as Portlets, that a solely ResponseWriter-based system
can't deal with.
However, my biggest issue with exposing tab index on Trinidad components
is that I doubt that it is even the appropriate abstraction. I suspect
that some sort of focus manager strategy, attachable to any component
would be more appropriate. I preferred to wait until we had a good set
of concrete focus management use cases. We could then verify that a
component tree with attached focus managers handled these cases and look
at whether a small set of declarative focus managers covered these cases.
-- Blake Sullivan
Andy Schwartz said the following On 3/22/2008 5:15 AM PT:
> Hey All -
>
> The concern with exposing a public component-level tabIndex attribute
> has always been that this opens up the potential for way more problems
> than it solves. The problem with HTML tabIndex attribute is that once
> you set one positive tabIndex value, in order to ensure that the tab
> traversal order matches the natural reading order (eg. the order in
> which a screen reader traverses the content), you are required to set
> tabIndex values on every tab stop on the page. This might be possible
> on extremely simple pages, but anything beyond that becomes
> unmanageable. Since it is not obvious to most page authors that
> setting tabIndex can actually have a negative impact on the
> accessibility of their page, we have historically avoided this issue
> by not exposing access to this functionality.
>
> The solution for the colorChooser problem is to:
>
> 1. Make the first color cell a tab stop.
> 2. Make all of the other color cells focusable, but not tab stops
> (tabIndex="-1").
> 3. Implement up/down/left/right arrow key handlers which explicitly
> call element.focus() to move the focus to the appropriate color cell.
>
> I guess we could implement #1 and #2 now and leave #3 for later,
> though in the case where the chooseColor is used in an inputColor's
> popup (probably more common than the inline case), keyboard users
> would be losing some functionality - ie. they would no longer tab
> through the color cells in the popup. On non-FF browsers where the
> focus highlight is displayed, this might be considered useful, though
> clearly #3 is a much better solution.
>
> Andy
>
>
Re: [Trinidad] implementing tabIndex attributes on select components
Posted by Andy Schwartz <an...@gmail.com>.
Hey All -
The concern with exposing a public component-level tabIndex attribute
has always been that this opens up the potential for way more problems
than it solves. The problem with HTML tabIndex attribute is that once
you set one positive tabIndex value, in order to ensure that the tab
traversal order matches the natural reading order (eg. the order in
which a screen reader traverses the content), you are required to set
tabIndex values on every tab stop on the page. This might be possible
on extremely simple pages, but anything beyond that becomes
unmanageable. Since it is not obvious to most page authors that
setting tabIndex can actually have a negative impact on the
accessibility of their page, we have historically avoided this issue
by not exposing access to this functionality.
The solution for the colorChooser problem is to:
1. Make the first color cell a tab stop.
2. Make all of the other color cells focusable, but not tab stops
(tabIndex="-1").
3. Implement up/down/left/right arrow key handlers which explicitly
call element.focus() to move the focus to the appropriate color cell.
I guess we could implement #1 and #2 now and leave #3 for later,
though in the case where the chooseColor is used in an inputColor's
popup (probably more common than the inline case), keyboard users
would be losing some functionality - ie. they would no longer tab
through the color cells in the popup. On non-FF browsers where the
focus highlight is displayed, this might be considered useful, though
clearly #3 is a much better solution.
Andy
Re: [Trinidad] implementing tabIndex attributes on select components
Posted by Gabrielle Crawford <ga...@oracle.com>.
Thanks. Maybe it wasn't complexity but just that it affected a lot of
components? We'll see what they say next week....
Thanks,
Gab
Andrew Robinson wrote:
> On Tue, Mar 18, 2008 at 12:47 PM, Gabrielle Crawford
> <ga...@oracle.com> wrote:
>
>> Unfortunately I can't remember the details. Blake Sullivan and Andy
>> Schwartz aren't around this week, but they may know more.
>>
>
> Not a problem, I don't see myself getting too much done this week with
> Easter coming up.
>
>
>> What happens to components that don't have a tabindex set, meaning do
>> you have to set it on everything in the page once you set it on one thing?
>>
>
> That is the way of HTML, this isn't a Trinidad consideration, but
> something specific to writing web sites. Note that you don't have to
> set all the tab indexes, but only the ones that you want to get focus
> first (as I mentioned, elements without tab indexes are tabbed too
> after all the explicit ones).
>
> So if I have a log in form, the tab indexes would probably be:
>
> user name: 1
> password: 2
> submit: 3
>
> And then everything else would not have one. This way all the
> "template" components would be tabbed, just not first.
>
Re: [Trinidad] implementing tabIndex attributes on select components
Posted by Andrew Robinson <an...@gmail.com>.
On Tue, Mar 18, 2008 at 12:47 PM, Gabrielle Crawford
<ga...@oracle.com> wrote:
> Unfortunately I can't remember the details. Blake Sullivan and Andy
> Schwartz aren't around this week, but they may know more.
Not a problem, I don't see myself getting too much done this week with
Easter coming up.
> What happens to components that don't have a tabindex set, meaning do
> you have to set it on everything in the page once you set it on one thing?
That is the way of HTML, this isn't a Trinidad consideration, but
something specific to writing web sites. Note that you don't have to
set all the tab indexes, but only the ones that you want to get focus
first (as I mentioned, elements without tab indexes are tabbed too
after all the explicit ones).
So if I have a log in form, the tab indexes would probably be:
user name: 1
password: 2
submit: 3
And then everything else would not have one. This way all the
"template" components would be tabbed, just not first.
Re: [Trinidad] implementing tabIndex attributes on select components
Posted by Gabrielle Crawford <ga...@oracle.com>.
Unfortunately I can't remember the details. Blake Sullivan and Andy
Schwartz aren't around this week, but they may know more.
What happens to components that don't have a tabindex set, meaning do
you have to set it on everything in the page once you set it on one thing?
Thanks,
Gab
Andrew Robinson wrote:
> On Tue, Mar 18, 2008 at 11:28 AM, Gabrielle Crawford
> <ga...@oracle.com> wrote:
>
>> I know this has been considered many times in the past, but not
>> implemented due to complexity.
>>
>
> What complexity are you referring to? Could you please provide
> concrete examples? Thanks.
>
>
>> When you know the details of the implementation, can you start a new
>> thread with [Trinidad] in the subject?
>>
>
> Done, but kept the reply ID intact for threaded email reading.
>
>
>> How will it work with stamping,
>> components with multiple tab stops, etc.
>>
>
> Tab indexes do not have to be unique. Browsers support this as it is a
> w3c requirement.
> Example:
>
> <a href="#" tabindex="5">
> <input type="checkbox" tabindex="5" />
> <input type="text" tabindex="5" />
> </a>
> <a href="#" tabindex="7">
> <input type="checkbox" tabindex="7" />
> <input type="text" tabindex="7" />
> </a>
>
> <a href="#" />
>
> The browser will tab to the first element with 5 first, then to each
> element with 5 next. After all of the 5's are visited it will go to
> the 7's as there are none with a tab index of 6.
>
> The last anchor gets a default tab stop that will be focused after
> every element that has an explicit tab stop has already been visited.
>
> So stamping is not an issue if implemented correctly (all components
> in a table are given the same tab index). If users want different tab
> indexes per component, per row, the tabIndex supports EL, so users can
> "easily" program around this problem by incrementing something like a
> counter in a backing bean. Example:
> <tr:commandLink tabIndex="1" />
> <tr:table varStatus="_status" ...>
> <tr:column>
> <tr:commandLink tabIndex="#{_status.index + 2}" />
> </tr:column>
> <tr:column>
> <tr:commandLink tabIndex="#{_status.index + 3}" />
> </tr:column>
> </tr:table>
>
> or:
>
> <tr:commandLink tabIndex="#{bean.nextTabIndex}" />
> <tr:table>
> <tr:column>
> <tr:commandLink tabIndex="#{bean.nextTabIndex}" />
> </tr:column>
> <tr:column>
> <tr:commandLink tabIndex="#{bean.nextTabIndex}" />
> </tr:column>
> </tr:table>
>
> Please see the specification for more information on the tabIndex:
> http://www.w3.org/TR/html4/interact/forms.html#adef-tabindex
>