WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: tabpanel mark-up, possible effect of role=presentation

for

From: Birkir R. Gunnarsson
Date: Aug 6, 2015 2:18PM

Leonie
I was referring to a situation where aria-hidden="false" is used on
visble tabpanel (and that makes sense), but the tabpanel itself
contains content that is hidden, either because it is infor for
developers, or because the tabpanel contains expandable sections or
error messages.
I saw this in two different scenarios:
1. Developers used hidden inputs to store system data
<input type="hidden" value="some value">
They were reported by Voiceover on iOS as form fields with no label.
The other situation was tabpanel containing a form, the error messages
were present but hidden with display: none.
Voiceover on iOS would read these error messages as you swipe through
the tabpanel.
The minute I removed aria-hidden="false" everything worked as expected.
As for keyboard operations.
Yes, consistent implementations should be used wherever possible.
I see cases for tabkey being allowed alongside or even instead of
arrow keys for tab navigation, especially when you only have 2 tabs.
But without consistency we cannot teach users to work with our
widgets, so that is why I always refer people first to the ARIA APG
recommendations for the pattern and tell them that , while APG is not
normative, they should take note of the proposed keyboard
functionality for the widget and implement it unless they have
specific reasons not to.



On 8/6/15, Bryan Garaventa < <EMAIL REMOVED> > wrote:
> It depends on the paradigm and the UI obviously, menu buttons already
> typically have downward pointing arrows to indicate this functionality for
> example.
>
> The point is, as long as ARIA widgets are not programmed consistently, they
> will never be understood properly.
>
>