WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: _mallory
Date: Aug 6, 2015 12:54PM

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
> > > >
> > > >
> > > >