E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 3 (In chronological order)

From: Bryan Garaventa
Date: Wed, Nov 14 2012 6:59PM
Subject: Accessible tab generation using HTML5 and content preloading
No previous message | Next message →

In case it's of interest.

The ARIA Tab generator now supports semantic configuration via HTML5, optional ARIA and non-ARIA implementations, optional preloading of external tab panels and images, and property overrides.

This is a significant update to the Tab Generator, which uses HTML5 attributes within the tab elements, so that external resource paths can be specified, or internal DOM nodes used as tab panels instead. Hidden text roles can also be controlled in this manner to provide accessible names for tab panel sections for screen reader users, the insertion point can be specified, and a default tab panel can be set to open automatically, all using HTML5 within the tab element markup.

You can see this in action at
http://whatsock.com/modules/aria_tabs_menu_modules/demo.htm
Where two flavors of tab generation are demonstrated, ARIA and Non-ARIA. This is controlled by setting the Boolean parameter for useARIA to true in the invocation statement at
http://whatsock.com/modules/aria_tabs_menu_modules/js/aria_tabs_module.js
which can be seen as applied for the demo page at
http://whatsock.com/modules/aria_tabs_menu_modules/js/setup.js
where 'preload' and 'preloadImages' are passed as configuration properties. This is the same preload functionality that was recently added to the Modal, Popup, and Tooltip modules.

The ARIA implementation pulls content from an external file, and preloads both HTML markup and images in advance to prevent any rendering delays when switching between tabs. All of the resource paths, tab panel hidden text role names, default panel opening, and insertion point settings are included within the HTML markup for each tab via the HTML5 'data-' attribute.

The same is true for the Non-ARIA implementation, except that the IDs for specific DOM nodes contained within the same page are set as tab panel contents instead.

In this case, high quality images were used to test the preloading feature, ranging between 200kb and 400kb in size per image, which isn't likely for standard tab panels. This makes a good test case however, to ensure proper functionality.

The reason there are two implementation types, is in case of a need to ensure IE6 compatibility, which can be achieved using the Non-ARIA method. The ARIA implementation has a nicer feel to it though, and was tested successfully using:
* JAWS 11 through 14 using IE 8 and 9 and Firefox.
* NVDA using IE 8 and 9 and Firefox.
* Voiceover using Mac and iOS Safari.

So here are the rules:

* Elements that are using the ARIA Tab implementation must include role=tab on the tab element, and role=tablist on the surrounding container tag.

* Any element that is a tab element should not include any other active elements (A or Button tags, etc.)

I know this last seems weird, but I've recently seen the following used: <div role=tab tabindex=0> <h3> <a href=#> Tab Name </a> </h3> </div>

To ensure accessibility, the only active element for a tab control should be the DOM node of that tab, and nothing else.

This is true as a general rule as well. Active elements should never contain other active elements that perform different actions, since these will not work reliably for keyboard and screen reader users.

The following HTML5 attributes are supported on each tab element:

data-role : (Optional) Specifies a custom name for the tab content panel, such as "Business Tab", which will be announced to screen reader users as "Business Tab Start" and "Business Tab End". The text for Start and End can be changed too by passing custom accStart and accEnd property values through the invocation statement as overrides. The role defaults to "Tab" if not assigned.

data-src : Specifies an external resource path where tab panel content can be loaded or preloaded from. Syntax: "path/file.html#containerId"

data-internal : Specifies the ID attribute value of a DOM node in the same page to use as tab panel content. This takes precedence over data-src if assigned.

data-insert : Specifies the ID attribute value of a container element where tab panels will be inserted.

data-defaultopen : Specifies whether a specific tab should open automatically.

Lastly, the new source code has been added to the AccDC API download at WhatSock.com, which includes the Modified BSD License for business integration.

From: Scott González
Date: Thu, Nov 15 2012 6:07AM
Subject: Re: Accessible tab generation using HTML5 and content preloading
← Previous message | Next message →

On Wed, Nov 14, 2012 at 8:59 PM, Bryan Garaventa <
= EMAIL ADDRESS 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

From: Bryan Garaventa
Date: Thu, Nov 15 2012 11:13AM
Subject: Re: Accessible tab generation using HTML5 and contentpreloading
← Previous message | No next message

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 ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS 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 ADDRESS 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
> > >