E-mail List Archives

Search E-mail List Archives for

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

From: Jennifer Sutton
Date: Fri, May 22 2015 6:49PM
Subject: selecting ARIA Tabs and Windows screen readers
No previous message | Next message →

Greetings, WebAIM:

I'm testing some ARIA tabs, and I am getting different behavior when
using JFW 15 and IE 11 and JFW 15 and FF 36.

I've seen so many different implementations of ARIA tabs that I need
to confirm my expectations.


Before everyone says: "just use NVDA," I'm about to test that, too,
but end-users are likely to be using JFW, so I need to test with that.

I'm getting different results with these combinations, and I'm not
sure whether it's the code or the AT. So . . .

Does anyone have a sample of ARIA Tabs that they feel is implemented
correctly, so I can compare that with my test case?

I'm imagining VO for the Mac would function similarly; I'm only
concerned about the desktop experience.

This is a very simple set of two ARIA tabs only. I don't want lists
or headings involved, if possible.


I can hear that a tab is initially selected by default (and
identified as such), and when I hit enter on the second one, I go
into forms mode. And while I can then use up and down arros to move
between the two, when I use escape to exit forms mode (when on the
tab I want to choose), sometimes it shows as selected, and sometimes
it doesn't. And I don't get selection feedback when in forms mode
and moving between the two tabs. I'd think JFW should be able to
report that, but perhaps I'm incorrect.

I believe these are vertical tabs, so using up and down arrow (rather
than right and left for horizontal ones) does seem correct in this case.

I've got plenty of examples of code; it's confirmation of screen
reader user expectations I need. And maybe there are browser issues I
need to watch out for, but ARIA tabs have been around for a long
time, so I'm hoping not.

When these two tabs are tested with keyboard-only (no screen reader),
they do operate correctly.

Thanks, and happy long weekend to all in the U.S.

Best,
Jennifer

From: Birkir R. Gunnarsson
Date: Sat, May 23 2015 3:20PM
Subject: Re: selecting ARIA Tabs and Windows screen readers
← Previous message | Next message →

Jennifer
I think the differences might be based on whether the tab gets
selected and its associated content loaded into the tabpanel when you
select it with the arrow key, vs. only performing that action when
user has focus on that tab and presses enter.
The ARIA Authoring Practices recommends the former, and Jaws appears
to expect the same, based on the fact that the Jaws shortcut key for
tabs is the same as for comboboxes (well, dropdowns) i.e. pressing "c"
gets you to the next select or tab on a webpage.
This is also the approach we followed when we implemented example tabs
for Deque University:
https://dequeuniversity.com/library/aria/tabpanels-accordions/sf-responsive-tabs-to-accordion#
I am not necessarily sure this is the one and only correct way to
implement tabs. E.g. if each tab panel contains a lot of content it
might slow the browsing experience down a lot when the content for
every tab when keyboard only user is moving the focus to it. If there
are 4 tabs between the currently selected one and the tab the user
wants, the page will refresh 5 times before he gets to it vs. if user
needs to explicitly activate the tab with the keyboard he can naviate
to the desired tab without affecting the page content and only load
the content he is interested in. However, I believe there is no one
right way to do this and it is up to the website. I think eiher
behavior is acceptable.
I have also let tabs go that are not ntested in a tablist and wehre
all the tabs are in focus order. I think this is acceptable if we have
ooonly 2 or 3 tabs on the page. The extra work of implementing arrow
key navigation within a set of 2 or 3 tabs to me just does not seem to
necessarily bring that great benefit to the user. wCAG does not
absolutely dictate how to operate controls with the keyboard, though
the Authoring Practices makes good recommendations.
Cheers
-Birkir



On 5/22/15, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
> Greetings, WebAIM:
>
> I'm testing some ARIA tabs, and I am getting different behavior when
> using JFW 15 and IE 11 and JFW 15 and FF 36.
>
> I've seen so many different implementations of ARIA tabs that I need
> to confirm my expectations.
>
>
> Before everyone says: "just use NVDA," I'm about to test that, too,
> but end-users are likely to be using JFW, so I need to test with that.
>
> I'm getting different results with these combinations, and I'm not
> sure whether it's the code or the AT. So . . .
>
> Does anyone have a sample of ARIA Tabs that they feel is implemented
> correctly, so I can compare that with my test case?
>
> I'm imagining VO for the Mac would function similarly; I'm only
> concerned about the desktop experience.
>
> This is a very simple set of two ARIA tabs only. I don't want lists
> or headings involved, if possible.
>
>
> I can hear that a tab is initially selected by default (and
> identified as such), and when I hit enter on the second one, I go
> into forms mode. And while I can then use up and down arros to move
> between the two, when I use escape to exit forms mode (when on the
> tab I want to choose), sometimes it shows as selected, and sometimes
> it doesn't. And I don't get selection feedback when in forms mode
> and moving between the two tabs. I'd think JFW should be able to
> report that, but perhaps I'm incorrect.
>
> I believe these are vertical tabs, so using up and down arrow (rather
> than right and left for horizontal ones) does seem correct in this case.
>
> I've got plenty of examples of code; it's confirmation of screen
> reader user expectations I need. And maybe there are browser issues I
> need to watch out for, but ARIA tabs have been around for a long
> time, so I'm hoping not.
>
> When these two tabs are tested with keyboard-only (no screen reader),
> they do operate correctly.
>
> Thanks, and happy long weekend to all in the U.S.
>
> Best,
> Jennifer
>
> > > > >


--
Work hard. Have fun. Make history.

From: Birkir R. Gunnarsson
Date: Sat, May 23 2015 3:25PM
Subject: Re: selecting ARIA Tabs and Windows screen readers
← Previous message | Next message →

Oh, to correct .. I do call it a WCAG violation if tabs are not
contained in a tablist, that is a violation of SC 4.1.2, my comment
had more to do with the tab vs. arrow key behavior.

On 5/23/15, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
> Jennifer
> I think the differences might be based on whether the tab gets
> selected and its associated content loaded into the tabpanel when you
> select it with the arrow key, vs. only performing that action when
> user has focus on that tab and presses enter.
> The ARIA Authoring Practices recommends the former, and Jaws appears
> to expect the same, based on the fact that the Jaws shortcut key for
> tabs is the same as for comboboxes (well, dropdowns) i.e. pressing "c"
> gets you to the next select or tab on a webpage.
> This is also the approach we followed when we implemented example tabs
> for Deque University:
> https://dequeuniversity.com/library/aria/tabpanels-accordions/sf-responsive-tabs-to-accordion#
> I am not necessarily sure this is the one and only correct way to
> implement tabs. E.g. if each tab panel contains a lot of content it
> might slow the browsing experience down a lot when the content for
> every tab when keyboard only user is moving the focus to it. If there
> are 4 tabs between the currently selected one and the tab the user
> wants, the page will refresh 5 times before he gets to it vs. if user
> needs to explicitly activate the tab with the keyboard he can naviate
> to the desired tab without affecting the page content and only load
> the content he is interested in. However, I believe there is no one
> right way to do this and it is up to the website. I think eiher
> behavior is acceptable.
> I have also let tabs go that are not ntested in a tablist and wehre
> all the tabs are in focus order. I think this is acceptable if we have
> ooonly 2 or 3 tabs on the page. The extra work of implementing arrow
> key navigation within a set of 2 or 3 tabs to me just does not seem to
> necessarily bring that great benefit to the user. wCAG does not
> absolutely dictate how to operate controls with the keyboard, though
> the Authoring Practices makes good recommendations.
> Cheers
> -Birkir
>
>
>
> On 5/22/15, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
>> Greetings, WebAIM:
>>
>> I'm testing some ARIA tabs, and I am getting different behavior when
>> using JFW 15 and IE 11 and JFW 15 and FF 36.
>>
>> I've seen so many different implementations of ARIA tabs that I need
>> to confirm my expectations.
>>
>>
>> Before everyone says: "just use NVDA," I'm about to test that, too,
>> but end-users are likely to be using JFW, so I need to test with that.
>>
>> I'm getting different results with these combinations, and I'm not
>> sure whether it's the code or the AT. So . . .
>>
>> Does anyone have a sample of ARIA Tabs that they feel is implemented
>> correctly, so I can compare that with my test case?
>>
>> I'm imagining VO for the Mac would function similarly; I'm only
>> concerned about the desktop experience.
>>
>> This is a very simple set of two ARIA tabs only. I don't want lists
>> or headings involved, if possible.
>>
>>
>> I can hear that a tab is initially selected by default (and
>> identified as such), and when I hit enter on the second one, I go
>> into forms mode. And while I can then use up and down arros to move
>> between the two, when I use escape to exit forms mode (when on the
>> tab I want to choose), sometimes it shows as selected, and sometimes
>> it doesn't. And I don't get selection feedback when in forms mode
>> and moving between the two tabs. I'd think JFW should be able to
>> report that, but perhaps I'm incorrect.
>>
>> I believe these are vertical tabs, so using up and down arrow (rather
>> than right and left for horizontal ones) does seem correct in this case.
>>
>> I've got plenty of examples of code; it's confirmation of screen
>> reader user expectations I need. And maybe there are browser issues I
>> need to watch out for, but ARIA tabs have been around for a long
>> time, so I'm hoping not.
>>
>> When these two tabs are tested with keyboard-only (no screen reader),
>> they do operate correctly.
>>
>> Thanks, and happy long weekend to all in the U.S.
>>
>> Best,
>> Jennifer
>>
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
>


--
Work hard. Have fun. Make history.

From: Jennifer Sutton
Date: Mon, May 25 2015 1:44PM
Subject: Re: selecting ARIA Tabs and Windows screen readers
← Previous message | Next message →

Birkir:

Thanks for your onlist response, and thanks to others who responded offlist.

In the end, NVDA and JFW handled this two-tabbed (very simple ARIA
implementation) differently.
NVDA handled it as I would have expected i.e. hit enter on the tab,
NVDA reports it as selected, and arrowing up and down (or left and
right -- depending on how the tabs are positioned) changes the
selection. That's with FF 36 and NVDA 2015-1.

I don't know whether there's a real bug in JFW, but since I'm using
15, at the moment, and 16 is released, I'm going to have to call this
"done" on my end.

I wasn't at liberty to post a test page here.

Best,
Jennifer

From: Birkir R. Gunnarsson
Date: Mon, May 25 2015 4:07PM
Subject: Re: selecting ARIA Tabs and Windows screen readers
← Previous message | Next message →

Jennifer.
I am curious.
Can you get a visual keyboard only check on what happens when the
keyboard only user (with no assistive technology) presses the arrow
keys with focus on a tab?
Does the tab content for the new tab load as soon as the arrow key is
pressed, or does the user have to actually press enter to load the new
content.
Knowing this helps tounderstand the different implementation of Jaws and NVDA.
Cheers


On 5/25/15, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
> Birkir:
>
> Thanks for your onlist response, and thanks to others who responded offlist.
>
> In the end, NVDA and JFW handled this two-tabbed (very simple ARIA
> implementation) differently.
> NVDA handled it as I would have expected i.e. hit enter on the tab,
> NVDA reports it as selected, and arrowing up and down (or left and
> right -- depending on how the tabs are positioned) changes the
> selection. That's with FF 36 and NVDA 2015-1.
>
> I don't know whether there's a real bug in JFW, but since I'm using
> 15, at the moment, and 16 is released, I'm going to have to call this
> "done" on my end.
>
> I wasn't at liberty to post a test page here.
>
> Best,
> Jennifer
>
> > > > >


--
Work hard. Have fun. Make history.

From: Jennifer Sutton
Date: Mon, May 25 2015 4:40PM
Subject: Re: selecting ARIA Tabs and Windows screen readers
← Previous message | Next message →

All:

When I said I was "done," I really meant it. So, I'm afraid I can't
do anything more on this.

This was a very quick test for someone else -- sighted help no longer
available as the person's on the road for the next ten days. and by
the time the road trip's over, the UI may have changed.


This isn't my project, and it's not public.

Thanks for the quick help, though.

Jennifer

At 03:07 PM 5/25/2015, you wrote:
>Jennifer. I am curious. Can you get a visual keyboard only check on
>what happens when the keyboard only user (with no assistive
>technology) presses the arrow keys with focus on a tab? Does the tab
>content for the new tab load as soon as the arrow key is pressed, or
>does the user have to actually press enter to load the new content.
>Knowing this helps tounderstand the different implementation of Jaws
>and NVDA. Cheers

>On 5/25/15, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote: >
>Birkir: > > Thanks for your onlist response, and thanks to others
>who responded offlist. > > In the end, NVDA and JFW handled this
>two-tabbed (very simple ARIA > implementation) differently. > NVDA
>handled it as I would have expected i.e. hit enter on the tab, >
>NVDA reports it as selected, and arrowing up and down (or left
>and > right -- depending on how the tabs are positioned) changes
>the > selection. That's with FF 36 and NVDA 2015-1. > > I don't know
>whether there's a real bug in JFW, but since I'm using > 15, at the
>moment, and 16 is released, I'm going to have to call this > "done"
>on my end. > > I wasn't at liberty to post a test page here. > >
>Best, > Jennifer >

From: Birkir R. Gunnarsson
Date: Mon, May 25 2015 5:09PM
Subject: Re: selecting ARIA Tabs and Windows screen readers
← Previous message | Next message →

NP Jennifer.
I will sit down with our own example, modify and explore.
If messing with it reveals more about different interpretations of
screen readers I will post back to a new thread on this list.
Cheers


On 5/25/15, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
> All:
>
> When I said I was "done," I really meant it. So, I'm afraid I can't
> do anything more on this.
>
> This was a very quick test for someone else -- sighted help no longer
> available as the person's on the road for the next ten days. and by
> the time the road trip's over, the UI may have changed.
>
>
> This isn't my project, and it's not public.
>
> Thanks for the quick help, though.
>
> Jennifer
>
> At 03:07 PM 5/25/2015, you wrote:
>>Jennifer. I am curious. Can you get a visual keyboard only check on
>>what happens when the keyboard only user (with no assistive
>>technology) presses the arrow keys with focus on a tab? Does the tab
>>content for the new tab load as soon as the arrow key is pressed, or
>>does the user have to actually press enter to load the new content.
>>Knowing this helps tounderstand the different implementation of Jaws
>>and NVDA. Cheers
>
>>On 5/25/15, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote: >
>>Birkir: > > Thanks for your onlist response, and thanks to others
>>who responded offlist. > > In the end, NVDA and JFW handled this
>>two-tabbed (very simple ARIA > implementation) differently. > NVDA
>>handled it as I would have expected i.e. hit enter on the tab, >
>>NVDA reports it as selected, and arrowing up and down (or left
>>and > right -- depending on how the tabs are positioned) changes
>>the > selection. That's with FF 36 and NVDA 2015-1. > > I don't know
>>whether there's a real bug in JFW, but since I'm using > 15, at the
>>moment, and 16 is released, I'm going to have to call this > "done"
>>on my end. > > I wasn't at liberty to post a test page here. > >
>>Best, > Jennifer >
>
> > > > >


--
Work hard. Have fun. Make history.

From: _mallory
Date: Thu, May 28 2015 2:24AM
Subject: Re: selecting ARIA Tabs and Windows screen readers
← Previous message | No next message

I was recently on a Dutch page that changed tabs when the arrow
was hit. This sucked much horribly, as it meant the long tab content
could not be read because my down arrow was highjacked from scrolling
the page to selecting another tab. I ended up not reading further.

I can give a URL if someone wants to see it. It appears they used
something from jQuery UI.

_mallory

On Mon, May 25, 2015 at 07:09:23PM -0400, Birkir R. Gunnarsson wrote:
> NP Jennifer.
> I will sit down with our own example, modify and explore.
> If messing with it reveals more about different interpretations of
> screen readers I will post back to a new thread on this list.
> Cheers
>
>
> On 5/25/15, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
> > All:
> >
> > When I said I was "done," I really meant it. So, I'm afraid I can't
> > do anything more on this.
> >
> > This was a very quick test for someone else -- sighted help no longer
> > available as the person's on the road for the next ten days. and by
> > the time the road trip's over, the UI may have changed.
> >
> >
> > This isn't my project, and it's not public.
> >
> > Thanks for the quick help, though.
> >
> > Jennifer
> >
> > At 03:07 PM 5/25/2015, you wrote:
> >>Jennifer. I am curious. Can you get a visual keyboard only check on
> >>what happens when the keyboard only user (with no assistive
> >>technology) presses the arrow keys with focus on a tab? Does the tab
> >>content for the new tab load as soon as the arrow key is pressed, or
> >>does the user have to actually press enter to load the new content.
> >>Knowing this helps tounderstand the different implementation of Jaws
> >>and NVDA. Cheers
> >
> >>On 5/25/15, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote: >
> >>Birkir: > > Thanks for your onlist response, and thanks to others
> >>who responded offlist. > > In the end, NVDA and JFW handled this
> >>two-tabbed (very simple ARIA > implementation) differently. > NVDA
> >>handled it as I would have expected i.e. hit enter on the tab, >
> >>NVDA reports it as selected, and arrowing up and down (or left
> >>and > right -- depending on how the tabs are positioned) changes
> >>the > selection. That's with FF 36 and NVDA 2015-1. > > I don't know
> >>whether there's a real bug in JFW, but since I'm using > 15, at the
> >>moment, and 16 is released, I'm going to have to call this > "done"
> >>on my end. > > I wasn't at liberty to post a test page here. > >
> >>Best, > Jennifer >
> >
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > >