WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: ARIA tabs interaction

for

From: _mallory
Date: May 2, 2016 3:18AM

On Fri, Apr 29, 2016 at 11:01:23PM +0000, Bryan Garaventa wrote:
> I get the frustration, yet a lot of what is experienced from the points you mention have to do with non-intuitive design and unreliable scripting.
>
> For example: The use of ARIA Tab attributes simply effects the mapping in the accessibility tree, it has no effect on the scripting or visual layout of the page.

At work we currently have a product used by many where someone did
indeed take a tabby-panel type thing, added a bunch of ARIA roles,
but then did not also add in all the keyboarding as per the ARIA
authoring practices spec-- the worst of both worlds, and I've
seen a lot of that around too.

Right now I'm debating whether I will make them keep the current
working and remove the roles (there are only three tabs so it's
not the keyboarding nightmare some aria-less tab panels can be),
or keep the roles, add in the appropriate keyboarding, and then
try to let all the users know why their tabs broke. Even screen
reader using users won't initially know how to use them without
some instruction, since now JAWS is all confused when it sees
the roles and tries to tell people to "hit space to select"
or whatever.
>
> For sighted keyboard only users, a designer can add a simple CSS class like the following to visually display arrows to indicate that the arrow keys should be pressed when interacting with a particular group of elements.
>
> *[role="tab"]:focus:after {
> /* style using content to display arrows here when focused */
> }

That's an idea.
>
> Typically this isn't needed if groups are visually conveyed intuitively, but this is an option that developers have at their disposal.
>
> I agree that icons without textual equivalents is a problem, and the same technique can be used to do the same thing actually, to accompany attributes such as aria-label that are not rendered visually.
>
> E.G
>
> <span aria-label="Add Favorite" class="addIcon" role="button" tabindex="0"></span>
>
> The following CSS will then display the above aria-label text for both sighted mouse and keyboard only users.
>
> span.addIcon:focus:after, span.addIcon:hover:after {
> /* Rules to position pseudo element. */
> content: attr(aria-label);
> }

I've done similar with the title attributes added to (actual) buttons
on the Discourse software in my browser's user CSS. If sites used
something consistently like titel or aria-label, I could even go from
site to site and know what all those silly buttons do!
>
> Nothing is ever perfect, but we all have to move forward, and saying that it's impossible for people to learn, will never help this happen.

It's not that people can't learn, it's more that it seems several
don't seem to realise that, unlike some of the truly newer things
showing up on web sites (sliders that actually work with keyboard
at all for example, or autocomplete), people have been trained on tab
panels already-- so in this case it's not just people learning a new
thing, but they also need to unlearn an old thing.

And I still want text above every one that's different, partially
also because the older sites out there who were built back when
the CSS "Sliding Doors" technique was the main way people styled
links to look like paper folder tabs are not being updated (it will
take a lot of time for them to get replaced. I expect replacement
is more likely than code updates, since these old pages definitely
breathe "old" and people like replacing everything with, I dunno,
Bootstrap). Meaning, the old way will coexist for quite a while with
the new way. This makes "teaching" people even harder.

_mallory