E-mail List Archives

Search E-mail List Archives for

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

From: Robert Fentress
Date: Tue, Feb 14 2017 7:03AM
Subject: Tooltip displaying keyboard interaction model for ARIA tabs
No previous message | Next message →

I'm wondering what folks think of the idea of displaying tooltips when
focus is set to a tab in an ARIA tab control widget
<https://www.w3.org/TR/wai-aria-practices-1.1/#tabpanel>, that informs the
user to use arrow keys to move between tabs. I think there are good
reasons for using the ARIA tab control pattern and hewing to its keyboard
interaction model, but web users (particularly keyboarders) expect each tab
to be a tab stop and will likely be confused if pressing the Tab key takes
them to the next focusable element within the tab panel, rather than the
next tab in the tablist. Is this a reasonable compromise or hand-holding
that is too verbose?

If you eschew the ARIA pattern altogether, what do you think is the best
strategy for informing screen reader users that these things are tabs and
that clicking on them causes a change in view?

Thanks.

-Rob

From: Birkir R. Gunnarsson
Date: Tue, Feb 14 2017 7:36AM
Subject: Re: Tooltip displaying keyboard interaction model for ARIA tabs
← Previous message | No next message

This is not a bad idea.
I would display the tooltip only the first time a tab receives focus
after a pageload. That should help the users without patronizing them.
It does take a little JavaScript mucking about, but I think it is a good idea.
Also a website that uses complex widgets should have an accessibility
FAQ section that lists things such as the keyboard operation of these
widgets.



On 2/14/17, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
> I'm wondering what folks think of the idea of displaying tooltips when
> focus is set to a tab in an ARIA tab control widget
> <https://www.w3.org/TR/wai-aria-practices-1.1/#tabpanel>, that informs the
> user to use arrow keys to move between tabs. I think there are good
> reasons for using the ARIA tab control pattern and hewing to its keyboard
> interaction model, but web users (particularly keyboarders) expect each tab
> to be a tab stop and will likely be confused if pressing the Tab key takes
> them to the next focusable element within the tab panel, rather than the
> next tab in the tablist. Is this a reasonable compromise or hand-holding
> that is too verbose?
>
> If you eschew the ARIA pattern altogether, what do you think is the best
> strategy for informing screen reader users that these things are tabs and
> that clicking on them causes a change in view?
>
> Thanks.
>
> -Rob
> > > > >


--
Work hard. Have fun. Make history.