WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible tab generation using HTML5 and contentpreloading

for

From: Bryan Garaventa
Date: Nov 15, 2012 11:13AM

Hi,
I'm not sure what you mean about 'What about close buttons?'

Are you referring to the element with role=tab, such as:

<div role='tab' tabindex='0'> Tab Name </div>

If you added a Close button to this, it would look something like the
following:

<div role='tab' tabindex='0'> Tab Name
<button> Close </button>
</div>

Which wouldn't work properly from the keyboard for both screen reader and
keyboard only users. This is what I was referring to earlier about not
nesting active elements. The tab panel though, can contain any number of
active elements.

The best place to put a Close icon is in the tab panel content, which is
very easy to do.

For example, if using the $A.setTabs method, simply pass the following
properties through as overrides:

closeClassName: 'whatever',
showHiddenClose: true

Then, wherever there is an active element with the className in your tab
panel content that matches 'whatever', this will automatically be configured
to close the tab panel.

E.G

<a class="closeIcon whatever" href="#"> Close </a>

The property 'showHiddenClose' also adds a hidden Close link at the end of
the tab panel content that performs the same action, which dynamically
appears onFocus to ensure 508 compliance.

All of these properties are documented on the Core API tab at WhatSock.com
as part of AccDC, under the CSS and Accessibility headings, where many other
possible overrides are available as well.

About my reasoning for activating tabs automatically, giving time for screen
reader users to hear the available tabs before activation is part of it.

The other part though, has to do with the complexity of possible tab panels.

For instance, I designed the Tab Module to be fully scalable as a
multipurpose component, so there is no way for me to predict what type of
content will be loaded into it at any given time. Also, the preload
functionality is optional, and may not be desirable in all cases, such as
when pulling content from a server script that is time sensitive or requires
user authentication; resulting in server response delays. Plus the content
itself may have large amounts of dynamic content requiring the running of
supporting scripts via the 'callback' parameter after a tab panel is
rendered, such as to program additional tab panels, interactive forms, and
any number of other complex control types and widgets that may be built into
the tab panel content.

So if these tab panels are rendered automatically when arrowing, the screen
reader is likely to freeze up during these instances as all of these things
happen at the same time. This is why it's important to provide a mechanism
for navigation that doesn't automatically activate such content prematurely.
This also prevents extra server interaction that may not be necessary or
even desired.

All of the ARIA attributes are programmed according to the ARIA spec
however, so this functionality has no negative impact on accessibility.

----- Original Message -----
From: "Scott González" < <EMAIL REMOVED> >
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Sent: Thursday, November 15, 2012 5:07 AM
Subject: Re: [WebAIM] Accessible tab generation using HTML5 and
contentpreloading


> On Wed, Nov 14, 2012 at 8:59 PM, Bryan Garaventa <
> <EMAIL REMOVED> > wrote:
>
>> * Any element that is a tab element should not include any other active
>> elements (A or Button tags, etc.)
>>
>
> What about close buttons?
>
> Also, I'd like to know why you chose not to activate tabs immediately upon
> navigation as the ARIA authoring practices suggest. I assume this is to
> give screen reader users time to hear which tab they're on before
> activating. I did a lot of investigation into how tabs are activated and
> have details listed here:
> https://github.com/jquery/jquery-ui/pull/666#issuecomment-6192174
> > >