Tabs (tabpanel, tab, tablist)
David Bolter
have each tab in the tab order, and not to auto-select the
corresponding panel unless the enter key is pressed. I can see why
this method might be nice, especially if the contents of the panel are
loaded on demand (e.g. via xhttp request). The trouble is it doesn't
follow the ARIA best practices (http://www.w3.org/WAI/PF/aria-
practices/#TabPanel) or the DHTML Styleguide (http://dev.aol.com/
dhtml_style_guide#tabpanel).
What do people think? Should we treat this as a jquery ui bug, or a
BPG/style_guide bug?
[see jquery-ui ticket: http://ui.jquery.com/bugs/ticket/3483]
Michelle D'Souza
navigation: http://build.fluidproject.org/fluid/sample-code/keyboard-a11y/jquery-ui-tabs/jquery-ui-accessible-tabs.html
It does seem nice to be able to arrow through tabs and have the
content change automatically but I wonder about pages with a lot of
content and several tabs.
Colin Clark
So the demo you're referring to is this one, right?
http://ui.jquery.com/repository/latest/demos/functional/#ui.tabs
At the moment, Tabs sort of works with the keyboard, due in large part
to the fact that each tab is rendered with a plain old link
underneath. It could be improved with a few tweaks:
1. Switching to the arrow key style interaction. This involves making
the tab container focusable with the "tab" key, and controlling the
selection of each individual tab with the left/right arrow keys.
2. Providing an easy-to-recognize indicator that a particular tab has
keyboard focus.
3. Adding ARIA to it.
I've illustrated how this could be accomplished in the example
Michelle D'Souza pointed out earlier in the thread.
As for your question about the style guide, that's a big one, which
opens an interesting can of worms. I'll see if I can summarize the two
potential options:
1. As per the style guide, a tab should be selected immediately upon
being focused with the arrow key.
2. Tabs should not be automatically selected when they get focus. The
user should be able to explore the list of tabs with the arrow keys,
and then press Enter or Space to select their desired tab.
There are a few factors to consider when choosing one or the other. If
you check out tabs on your desktop OS, you'll find that they behave
differently between the Mac and Windows. Windows uses style #1, while
the Mac more or less uses style #2.
The other issue that you mention is AJAX. If the contents of a tab are
loaded dynamically upon selection, it could be quite tedious for the
user if they have to wait for each tab to load as they cycle through
the list.
Yahoo has written an interesting article about how they implemented
their Tabs widget, and it includes some discussion about these issues:
http://yuiblog.com/blog/2008/07/30/tabview-aria/
They chose to use style #2. I think that they probably made a good
choice, but I can see both sides of the argument. Alternatively, we
could choose to allow the implementor to configure the style they
prefer, or perhaps switch the behaviour based on detecting what
operating system we're running on.
Thoughts?
Colin
---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org
David Bolter
Yep, that was the demo I was referring to.
Clown and I were discussing the whole normalized web2.0 interaction vs
platform friendly web2.0 interaction topic yesterday. I think more
voices for the latter should send comments to wai-xtech, you can
subscribe by emailing the PFWG Chair:
http://www.w3.org/WAI/PF/participation.html#Subscribin
(We're pushing for them to automate subscription... but no success
yet)
It is sometimes hard to get DHTML authors to even remember to add
keyboard interaction, let alone asking them to customize for each OS.
That said, I think we should strive for the best user experience,
whatever it may be.
cheers,
David
David Bolter
ui somehow... Colin's last email.
Scott González
I'm not sure if hover/click can or should be directly correlated to focus/keypress, but it seems like a good initial comparison. Does this break down somewhere?
I think David is correct that we should support both implementations and my current feeling is that #2 should be the default.
Colin Clark
On 21-Oct-08, at 12:19 PM, Scott González wrote:
> My first thought is that #2 is better as I can easily relate focus
> and selection as two very separate operations, just like focusing
> and selecting a standard link. However, when comparing tabs to
> accordions, it gets trickier. Many people consider selecting an
> accordion panel by hovering, not clicking, to be an ideal
> implementation.
>
> I'm not sure if hover/click can or should be directly correlated to
> focus/keypress, but it seems like a good initial comparison. Does
> this break down somewhere?
Yep, I think you're exactly right here. I guess the analogy might
start to break down when you consider that focus is often used to
"discover" the available options in the user interface. So for
example, someone using a screen reader will use keyboard focus to
determine what is available to them ahead of time. Whereas mouse hover
tends to be a reinforcement of something the user is already aware of.
Nonetheless, it's still a useful analogy.
> I think David is correct that we should support both implementations
> and my current feeling is that #2 should be the default.
I think that makes sense. I've updated my accessible UI Tabs demo to
show both interactions, allowing you to switch between them and see
the difference. Hopefully this will be helpful:
Unfortunately our daily build server appears to be down at the moment,
so if this link doesn't work for you, check back soon. In the
meantime, here's a link to the source code:
Colin
---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org
Rich Caloggero
have the tab panels update themselves. This is generally how desktop GUI
keyboard navigation works (well, at least on windows which is still what
most screen reader users are familiar with).
What would be nice is to be able to move focus to the tablist via one
keystroke, and/or to be able to cycle through tabs without having to first
find the tablist itself. THe advantage to focusing the tablist via
keystroke is that only one key is needed. However, it then takes two logical
steps to move to the next tab: focus the tablist, then move forward or
backward (and possibly press enter).
The advantage of having a next/previous tab key is that you can move to the
next/previous tab in one logical operation. If this method is chosen, the
focus should move to the first item in the newly opened tab panel. . The
nice thing here is that it may be clearer to the screen reader user when a
new tab has actually loaded since focus moves and something is read. If you
simply arrow through the tablist, there might be a delay between when the
item is selected/activated and when the panel actually loads/displays, which
might be confusing.
I can imagine situations where moving through the tabs via next/previous
keys is more functional, and situations where moving through the tablist
itself is better. I'd use the former when I know the app well and just need
to get something done quickly; the latter when I want to explore the
interface.
Hope this makes sense.
-- Rich