WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Bryan Garaventa
Date: Aug 6, 2015 2:07PM


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.

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Jonathan Avila
Sent: Thursday, August 06, 2015 12:24 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] tabpanel mark-up, possible effect of role=presentation

> Little pictures of arrows do not change the years of training by every website that you tab from focusable to focusable.

I agree and I think arrows would be confusing and would clutter the control.

Jonathan

--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
<EMAIL REMOVED>
Phone 703.637.8957
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter


-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of _mallory
Sent: Thursday, August 06, 2015 2:55 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] tabpanel mark-up, possible effect of role=presentation

Little pictures of arrows do not change the years of training by every website that you tab from focusable to focusable.

Users discover arrows by tabbing and shift-tabbing around several times before then giving Plan B (the arrows) a try. This may or may not be after trying various combinations of ctrl, alt, and shift.

This will hopefully go away as more sites start using arrows for tabs.

_mallory

On Thu, Aug 06, 2015 at 11:21:16AM -0700, Bryan Garaventa wrote:
> > Also for keyboard-only users without AT wouldn't it be hard to know when to use arrow navigation in tabs?
>
> Not if the widget is programmed intuitively.
>
> E.G If the tabs flow from left to right in a single row, it would be a simple matter to use a CSS pseudo element such as :after to append left/right pointing arrows to clue the sighted keyboard user into this functionality.
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Joseph Sherman
> Sent: Thursday, August 06, 2015 10:19 AM
> To: 'WebAIM Discussion List' < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] tabpanel mark-up, possible effect of
> role=presentation
>
> Also for keyboard-only users without AT wouldn't it be hard to know when to use arrow navigation in tabs?
>
>
> Joseph
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Graham Armfield
> Sent: Thursday, August 06, 2015 12:56 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] tabpanel mark-up, possible effect of
> role=presentation
>
> Having all the tab headers as links surely helps users of Dragon NaturallySpeaking to select required tab more easily - without having to rely on mouse grid or full mouse move interaction. Also, aren't many switch setups geared up for easier access to tab and enter - rather than left/right arrow keys?
>
> Regards
> ​Graham Armfield​
>
>
>
> On Thu, Aug 6, 2015 at 5:25 PM, Birkir R. Gunnarsson < <EMAIL REMOVED> > wrote:
>
> > Be mindful of using aria-hidden="false" as it may override things
> > inside the tabpanel that are supposed to be hidden.
> > <div role="tabpanel" aria-hidden="false"> <div id="userOpinionSecret"
> > style="display: none">WE know this user, he is not popular</div>
> > </div> Users, at least of some screen readers, will see tthis text,
> > because aria-hidden="false" overrides display: none; If you are
> > using
> > display: none type class to hide inactive tabpanels you do not need
> > to add aria-hidden to that.
> > I have passed tabbed interfaces where all tabs are in focus order,
> > though I have recommended full implementation as strong best practice.
> > Jaws treats tabs as comboboxes (you can get to them using keyboard
> > shortcut "c") and it makes sense in a way, but only if arrow key
> > navigation is enabled.
> > I would be surprised if adding aria-controls solves the issue,
> > though I hope it does.
> >
> >
> >
> > On 8/6/15, Detlev Fischer < <EMAIL REMOVED> > wrote:
> > > Hi,
> > > thanks to Jon and Leonie and Birkir for your quick and helpful
> > suggestions!
> > >
> > > The main deviation from the recommended pattern is that on
> > > reaching the tablist, arrow navigation is not used to navigate
> > > between tabs - tabs are indeed reached by tabbing to them, and
> > > enter on the focused tab updates
> > the
> > > tabpanel content. (We actually have at times recommended that
> > > behaviour
> > to
> > > avoid a situation where users not familiar with the tab pattern
> > > and switching to arrowing may miss content inside not active
> > > tabpanels.)
> > >
> > > Jon: the tabs themselves do not have aria-hidden on them, and they
> > > are
> > the
> > > ones that are not read by the screenreader when arrowing through
> > content...
> > >
> > > What is missing in the current mark-up of tabs is actually the
> > > "aria-controls" attribute referencing the respective tabpanels. So
> > > adding that might make a difference.
> > >
> > > Birkir: the ol holding the li elements witn role=presentation
> > > indeed
> > carries
> > > role=tablist.
> > >
> > > --
> > > Detlev Fischer
> > > testkreis c/o feld.wald.wiese
> > > Thedestr. 2, 22767 Hamburg
> > >
> > > Mobil +49 (0)1577 170 73 84
> > > Tel +49 (0)40 439 10 68-3
> > > Fax +49 (0)40 439 10 68-5
> > >
> > > http://www.testkreis.de
> > > Beratung, Tests und Schulungen für barrierefreie Websites
> > >
> > > Jonathan Avila schrieb am 06.08.2015 16:30:
> > >
> > >> Detlev, perhaps aria-hidden is not being updated in time for the
> > >> screen reader to see the updated content.
> > >>
> > >> Jonathan
> > >>
> > >> --
> > >> Jonathan Avila
> > >> Chief Accessibility Officer
> > >> SSB BART Group
> > >> <EMAIL REMOVED>
> > >> Phone 703.637.8957
> > >> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ]
> > >> On
> > Behalf
> > >> Of
> > >> Detlev Fischer
> > >> Sent: Thursday, August 06, 2015 8:55 AM
> > >> To: <EMAIL REMOVED>
> > >> Subject: [WebAIM] tabpanel mark-up, possible effect of
> > >> role=presentation
> > >>
> > >> Hi,
> > >>
> > >> I have a question for screen reader users. Curently I am testing
> > >> a site that uses what appears to be a properly marked-up tabpanel:
> > >> two tabs with
> > role
> > >> tab,
> > >> content in two divs with role tabpanel. The tabs are technically
> > >> skip links to the associated tabpanel divs. These two tab links
> > >> sit inside li elements with role=presentation. The site also use
> > >> aria-selected on the tabs and aria-hidden=true and display=none
> > >> on the hidden tabpanel.
> > >>
> > >> Now my question: when navigating with arrow keys in NVDA and JAWS
> > >> (Firefox), both screen readers do not read the tabs - they skip
> > >> straight to the tabpanel content below. I fist though this might
> > >> be due to role=presentatino on
> > the
> > >> li
> > >> elements, but this role should not apply to the a elements inside
> > >> the li elements, if I correctly understand the ARIA semantics.
> > >>
> > >> Tabbing through content will focus and rtead the tabs, but fail
> > >> to read the tabpanel content when arrowing doen after activation
> > >> (just a visible scroll effect).
> > >> Could well be that I am not using the screen readers correctly.
> > >> Or is
> > this
> > >> due
> > >> to known screen reader bugs?
> > >> Unfortunately I cannot point you to the site (behind a login).
> > >>
> > >> Any ideas?
> > >>
> > >> --
> > >> Detlev Fischer
> > >> testkreis c/o feld.wald.wiese
> > >> Thedestr. 2, 22767 Hamburg
> > >>
> > >> Mobil +49 (0)1577 170 73 84
> > >> Tel +49 (0)40 439 10 68-3
> > >> Fax +49 (0)40 439 10 68-5
> > >>
> > >> http://www.testkreis.de
> > >> Beratung, Tests und Schulungen für barrierefreie Websites
> > >>
> > >> > > >> > > archives
> > >> at
> > >> http://webaim.org/discussion/archives
> > >> > > >> > > >> > > >> archives at http://webaim.org/discussion/archives
> > >> > > >>
> > >
> > > > > > > > > archives at http://webaim.org/discussion/archives
> > > > > >
> >
> >
> > --
> > Work hard. Have fun. Make history.
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >
> > > archives at http://webaim.org/discussion/archives
>