E-mail List Archives

Re: Are these accessible tabs?


From: Jason Kiss
Date: Feb 28, 2011 5:33PM


In terms of the tabbed interface at uxmovement.com, some things I notice
are the following:

1. As a sighted user, I find it difficult to quickly, upon glancing at
it, determine the boundaries of the tabbed interface, that is, what
content is part of the associated tab's panel, and what is not. Perhaps
something like a simple border around the tab links and tab panel
content to visually contain them would help.

2. A screen reader will announce the tab links as same-page anchors. The
default behaviour expected for these is that clicking one of them will
move focus to the associated content on the page, but this doesn't
happen here. Instead, focus remains on the tab link that was selected.
This is a common issue with many tabbed interfaces. Since the tab links
simply show and hide content, it will not be clear to a screen reader
user that the content has changed; and because focus remains on the tab
link, the screen reader user will have to navigate down the page,
possibly through other tab links, to get to the newly visible content.
There is also no non-visual indication of which tab link is currently
selected, so it will not be immediately clear to a screen reader user
what tab link the current tab panel content relates to.

Dirk Ginader has a post describing some of these issues:

He also provides a good jQuery-based plugin for accessible tabs that you
may want to look at (https://github.com/ginader/Accessible-Tabs). Using
it would require some minor changes to the structure of your tabbed
interface content, but they would go a long way to making it accessible.
Notably, you would need to provide some heading text for each of the tab
panels, but this heading is positioned offscreen so that it need not
interfere with the presentation to sighted users, though it will still
be available to assistive technologies. The heading is important as
focus is programmatically moved to it when a tab link is clicked, thus
allowing screen reader users to start reading the content that they
think they just moved to by activating the tab link.

Ginader's plugin also allows you to add hidden text, e.g., "Current
Tab:", to the selected tab link so that screen reader users can readily
figure out which tab is currently selected.

Implementing WAI-ARIA is also another option, but support for it is
still fairly limited among many assistive technology and browser
combinations currently in use. So if you are looking to maximise the
tabs' accessibility to the most users, I suggest that something like
Ginader's plugin is your best bet.

Regarding the use of display:none, it is quite appropriate in this case
since the unselected tab panels are not supposed to be available at all.
If, for example, they were simply positioned offscreen, and they
contained focusable links, then a sighted keyboard user could easily get
confused since pressing the TAB key would set focus to those links, but
they would not be visible on the page. Similarly, a sighted screen
reader user might wonder where all the content of these hidden tab
panels is when it is being read by the screen reader. There's a related
article on this at

Hope this helps.


Jason Kiss
Web: www.accessibleculture.org
Twitter: @jkiss

On 01/03/11 11:52, Celeste Mackintosh wrote:
> Hi everyone,
> Can anyone help with a test or advice? They're here:
> http://uxmovement.com/
> (On the right hand side of the page)
> I think I'm quite confused about when display:none is an issue for
> screenreaders - these are focusable links, so would this be okay?
> (Newbie alert! :))
> Many thanks,
> Celeste