E-mail List Archives
Thread: Interaction with tab panels
Number of posts in this thread: 19 (In chronological order)
From: Vemaarapu Venkatesh
Date: Wed, Aug 03 2016 8:42AM
Subject: Interaction with tab panels
No previous message | Next message →
Hello all, Greetings
If we consider tab panel, we should use arrow keys to interact with tabs
inside the widget if I am not wrong.
https://support.skype.com/en/faq/fa109/i-ve-forgotten-my-username-or-password
When I interacted with the tab panel present in the above link, I observed
1. When all tabs are in collapsed state, I hit tab to enter into tab panel.
Then I thought that focus moves out of tab panel to "Yes" button if I hit
tab key once again. But navigation continues in tab panel i.e the other two
tab items are in tab order. This behavior is not seen when any one of tab
items is expanded.
I feel that interaction inside the tab panel should be only with arrow keys
but not with tab key anytime.
2. If I am expanding any tab item, the already selected tab item is not
getting collapsed automatically. User has to collapse and expand manually.
Whether these two behaviors are recommendable when I am interacting with
tab panel widget.
Hope you will correct me if I am going wrong with my perception.
Regards,
venkatesh
From: Joseph Sherman
Date: Wed, Aug 03 2016 8:57AM
Subject: Re: Interaction with tab panels
← Previous message | Next message →
For #1, there was a discussion a few weeks back about using the specification versus what users are currently expecting. I know when I come to a tab panel or menu panel, I try to tab to the next item and then have to go back and use the arrows if it skips.
Joseph
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Vemaarapu Venkatesh
Sent: Wednesday, August 03, 2016 10:42 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Interaction with tab panels
Hello all, Greetings
If we consider tab panel, we should use arrow keys to interact with tabs inside the widget if I am not wrong.
https://support.skype.com/en/faq/fa109/i-ve-forgotten-my-username-or-password
When I interacted with the tab panel present in the above link, I observed 1. When all tabs are in collapsed state, I hit tab to enter into tab panel.
Then I thought that focus moves out of tab panel to "Yes" button if I hit tab key once again. But navigation continues in tab panel i.e the other two tab items are in tab order. This behavior is not seen when any one of tab items is expanded.
I feel that interaction inside the tab panel should be only with arrow keys but not with tab key anytime.
2. If I am expanding any tab item, the already selected tab item is not getting collapsed automatically. User has to collapse and expand manually.
Whether these two behaviors are recommendable when I am interacting with tab panel widget.
Hope you will correct me if I am going wrong with my perception.
Regards,
venkatesh
From: Bryan Garaventa
Date: Wed, Aug 03 2016 11:18AM
Subject: Re: Interaction with tab panels
← Previous message | Next message →
Yes indeed. The following article will help with understanding the logic behind accessible ARIA Tab construction and usage.
https://hackpoets.wordpress.com/2016/05/10/from-html-to-aria-tabs-a-travelog/
All the best,
Bryan
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Vemaarapu Venkatesh
Sent: Wednesday, August 03, 2016 7:42 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Interaction with tab panels
Hello all, Greetings
If we consider tab panel, we should use arrow keys to interact with tabs inside the widget if I am not wrong.
https://support.skype.com/en/faq/fa109/i-ve-forgotten-my-username-or-password
When I interacted with the tab panel present in the above link, I observed 1. When all tabs are in collapsed state, I hit tab to enter into tab panel.
Then I thought that focus moves out of tab panel to "Yes" button if I hit tab key once again. But navigation continues in tab panel i.e the other two tab items are in tab order. This behavior is not seen when any one of tab items is expanded.
I feel that interaction inside the tab panel should be only with arrow keys but not with tab key anytime.
2. If I am expanding any tab item, the already selected tab item is not getting collapsed automatically. User has to collapse and expand manually.
Whether these two behaviors are recommendable when I am interacting with tab panel widget.
Hope you will correct me if I am going wrong with my perception.
Regards,
venkatesh
From: Vemaarapu Venkatesh
Date: Wed, Aug 03 2016 11:58AM
Subject: Re: Interaction with tab panels
← Previous message | Next message →
>When I interacted with the tab panel present in the above link, I observed
> >1. When all tabs are in collapsed state, I hit tab to enter into tab
> panel. Then I thought that >focus moves out of tab panel to "Yes" button if
> I hit tab key once again. But navigation >continues in tab panel i.e the
> other two tab items are in tab order. This behavior is not >seen when any
> one of tab items is expanded.
> >I feel that interaction inside the tab panel should be only with arrow
> keys but not with tab >key anytime.
> >2. If I am expanding any tab item, the already selected tab item is not
> getting collapsed >automatically. User has to collapse and expand manually.
>
> Can I consider above 2 points as violations as tab items are navigable
> with tab key and selected tab items are not collapsed when we expand other
> tab item.
>
> Regards,
> venkatesh
>
From: Bryan Garaventa
Date: Wed, Aug 03 2016 3:18PM
Subject: Re: Interaction with tab panels
← Previous message | Next message →
Hi,
Which screen reader and which browser are you using?
Also, are you referring to the example at
http://a11yideas.com/testcode/tabs/tabs_with_ARIA.html ?
This matches the ARIA Tab paradigm at
http://whatsock.com/bootstrap/jquery
All of the Tabs are programmed with one tab stop plus the requisit ARIA attributes to ensure proper functionality within ATs.
I'm not sure why your browser would be showing multiple tab stops.
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Vemaarapu Venkatesh
Sent: Wednesday, August 03, 2016 10:59 AM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Interaction with tab panels
>When I interacted with the tab panel present in the above link, I
>observed
> >1. When all tabs are in collapsed state, I hit tab to enter into tab
> panel. Then I thought that >focus moves out of tab panel to "Yes"
> button if I hit tab key once again. But navigation >continues in tab
> panel i.e the other two tab items are in tab order. This behavior is
> not >seen when any one of tab items is expanded.
> >I feel that interaction inside the tab panel should be only with
> >arrow
> keys but not with tab >key anytime.
> >2. If I am expanding any tab item, the already selected tab item is
> >not
> getting collapsed >automatically. User has to collapse and expand manually.
>
> Can I consider above 2 points as violations as tab items are navigable
> with tab key and selected tab items are not collapsed when we expand
> other tab item.
>
> Regards,
> venkatesh
>
From: Vemaarapu Venkatesh
Date: Wed, Aug 03 2016 9:19PM
Subject: Re: Interaction with tab panels
← Previous message | Next message →
Bryan, I found interaction is perfect with tab panel in the mentioned pages
by you. In the first page, tab items are selected with the focus and in the
second page first tab item is expanded as soon as receiving the focus. In
two pages, interaction is possible only with arrow keys inside tab panel
and tab key wont take us to next tab item.
But in my case tab items are in collapsed state even after taking the focus
to the tab panel and my main concern is "navigation is moving to other tab
items in the list when we hit tab key when all items are collapsed". Is it
fine like that.
Please refer
https://support.skype.com/en/faq/fa109/i-ve-forgotten-my-username-or-password
I am using NVDA+Firefox. Hope I am clear.
Regards,
venkatesh
On Wed, Aug 3, 2016 at 8:12 PM, Vemaarapu Venkatesh <
= EMAIL ADDRESS REMOVED = > wrote:
> Hello all, Greetings
>
> If we consider tab panel, we should use arrow keys to interact with tabs
> inside the widget if I am not wrong.
>
>
> https://support.skype.com/en/faq/fa109/i-ve-forgotten-my-username-or-password
>
> When I interacted with the tab panel present in the above link, I observed
> 1. When all tabs are in collapsed state, I hit tab to enter into tab
> panel. Then I thought that focus moves out of tab panel to "Yes" button if
> I hit tab key once again. But navigation continues in tab panel i.e the
> other two tab items are in tab order. This behavior is not seen when any
> one of tab items is expanded.
> I feel that interaction inside the tab panel should be only with arrow
> keys but not with tab key anytime.
> 2. If I am expanding any tab item, the already selected tab item is not
> getting collapsed automatically. User has to collapse and expand manually.
>
> Whether these two behaviors are recommendable when I am interacting with
> tab panel widget.
>
> Hope you will correct me if I am going wrong with my perception.
>
> Regards,
> venkatesh
>
From: Sean Murphy
Date: Thu, Aug 04 2016 4:30AM
Subject: Re: Interaction with tab panels
← Previous message | Next message →
This is a interesting discussion. I was at a A11y Web Dev meeting a few weeks which the speaker mention the different user expectation on the desktop compared to the Web Browser. On the desktop people know when to use the tab and arrow keys. In the browser, people attend to use the tab key first then the arrow keys. He went on to say that movement in the wider world of the Web is to try and merge these two type of usage as one.
Personally, I think if you are in a tab strip, menu, etc. Then you use the arrows key by default. AS this is what you do on the desktop. As well these are an single object regardless how they are built. The tab should move you to the next object (element).
Sean
> On 4 Aug 2016, at 1:19 PM, Vemaarapu Venkatesh < = EMAIL ADDRESS REMOVED = > wrote:
>
> Bryan, I found interaction is perfect with tab panel in the mentioned pages
> by you. In the first page, tab items are selected with the focus and in the
> second page first tab item is expanded as soon as receiving the focus. In
> two pages, interaction is possible only with arrow keys inside tab panel
> and tab key wont take us to next tab item.
> But in my case tab items are in collapsed state even after taking the focus
> to the tab panel and my main concern is "navigation is moving to other tab
> items in the list when we hit tab key when all items are collapsed". Is it
> fine like that.
> Please refer
> https://support.skype.com/en/faq/fa109/i-ve-forgotten-my-username-or-password
> I am using NVDA+Firefox. Hope I am clear.
> Regards,
> venkatesh
>
>
> On Wed, Aug 3, 2016 at 8:12 PM, Vemaarapu Venkatesh <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hello all, Greetings
>>
>> If we consider tab panel, we should use arrow keys to interact with tabs
>> inside the widget if I am not wrong.
>>
>>
>> https://support.skype.com/en/faq/fa109/i-ve-forgotten-my-username-or-password
>>
>> When I interacted with the tab panel present in the above link, I observed
>> 1. When all tabs are in collapsed state, I hit tab to enter into tab
>> panel. Then I thought that focus moves out of tab panel to "Yes" button if
>> I hit tab key once again. But navigation continues in tab panel i.e the
>> other two tab items are in tab order. This behavior is not seen when any
>> one of tab items is expanded.
>> I feel that interaction inside the tab panel should be only with arrow
>> keys but not with tab key anytime.
>> 2. If I am expanding any tab item, the already selected tab item is not
>> getting collapsed automatically. User has to collapse and expand manually.
>>
>> Whether these two behaviors are recommendable when I am interacting with
>> tab panel widget.
>>
>> Hope you will correct me if I am going wrong with my perception.
>>
>> Regards,
>> venkatesh
>>
> > > >
From: Jamous, JP
Date: Thu, Aug 04 2016 7:01AM
Subject: Re: Interaction with tab panels
← Previous message | Next message →
Sean,
Quite interesting as I faced it myself first-hand when I taught blind folks how to use JAWS. The average person lacks the understanding of containers and how each responds to keyboard commands. I know because I have been a programmer and a JAWS scripter too. Yet, on some dropdowns, I do wonder sometimes which will make me go through the menu items as the developer might use tab and shift + tab rather than arrow keys.
A prime example, JAWS and the worthless ribbon bar in Office. You can tab or shift + tab with it or use the arrow keys. Sometimes, you cannot use the up or down arrow keys and you have to use the left or right ones.
Please, give me my dropdown menus again. The ribbon is terrible and even sighted folks agree with me. Most of them including programmers do not like the ribbon bar.
I agree that a standard should be enforced in this regard.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean Murphy
Sent: Thursday, August 04, 2016 5:31 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Interaction with tab panels
This is a interesting discussion. I was at a A11y Web Dev meeting a few weeks which the speaker mention the different user expectation on the desktop compared to the Web Browser. On the desktop people know when to use the tab and arrow keys. In the browser, people attend to use the tab key first then the arrow keys. He went on to say that movement in the wider world of the Web is to try and merge these two type of usage as one.
Personally, I think if you are in a tab strip, menu, etc. Then you use the arrows key by default. AS this is what you do on the desktop. As well these are an single object regardless how they are built. The tab should move you to the next object (element).
Sean
> On 4 Aug 2016, at 1:19 PM, Vemaarapu Venkatesh < = EMAIL ADDRESS REMOVED = > wrote:
>
> Bryan, I found interaction is perfect with tab panel in the mentioned
> pages by you. In the first page, tab items are selected with the focus
> and in the second page first tab item is expanded as soon as receiving
> the focus. In two pages, interaction is possible only with arrow keys
> inside tab panel and tab key wont take us to next tab item.
> But in my case tab items are in collapsed state even after taking the
> focus to the tab panel and my main concern is "navigation is moving to
> other tab items in the list when we hit tab key when all items are
> collapsed". Is it fine like that.
> Please refer
> https://support.skype.com/en/faq/fa109/i-ve-forgotten-my-username-or-p
> assword I am using NVDA+Firefox. Hope I am clear.
> Regards,
> venkatesh
>
>
> On Wed, Aug 3, 2016 at 8:12 PM, Vemaarapu Venkatesh <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hello all, Greetings
>>
>> If we consider tab panel, we should use arrow keys to interact with
>> tabs inside the widget if I am not wrong.
>>
>>
>> https://support.skype.com/en/faq/fa109/i-ve-forgotten-my-username-or-
>> password
>>
>> When I interacted with the tab panel present in the above link, I
>> observed 1. When all tabs are in collapsed state, I hit tab to enter
>> into tab panel. Then I thought that focus moves out of tab panel to
>> "Yes" button if I hit tab key once again. But navigation continues in
>> tab panel i.e the other two tab items are in tab order. This behavior
>> is not seen when any one of tab items is expanded.
>> I feel that interaction inside the tab panel should be only with
>> arrow keys but not with tab key anytime.
>> 2. If I am expanding any tab item, the already selected tab item is
>> not getting collapsed automatically. User has to collapse and expand manually.
>>
>> Whether these two behaviors are recommendable when I am interacting
>> with tab panel widget.
>>
>> Hope you will correct me if I am going wrong with my perception.
>>
>> Regards,
>> venkatesh
>>
> > > archives at http://webaim.org/discussion/archives
>
From: Chagnon | PubCom
Date: Thu, Aug 04 2016 9:58AM
Subject: Re: Interaction with tab panels
← Previous message | Next message →
JP Jamous wrote:
"Please, give me my dropdown menus again. The ribbon is terrible and even sighted folks agree with me. Most of them including programmers do not like the ribbon bar."
One key fault of the ribbon bar GUI becomes very evident when viewed on a large, wide-screen monitor: there's too much distance the eye must track from the far left edge to the far right edge. This is the eye-tracking distance. Some monitor setups force the user to not just move their eyes left-to-right over this long distance, but actually turn their heads from left to right, like watching a tennis match.
It's worse for those using screen enlargers. This factor about the GUI is tiring and puts a psychological barrier in the user's mind.
On the other hand, drop-down menus don't force such an extreme eye-tracking distance on the user.
Also, when a MS ribbon bar menu is viewed on a narrower monitor (or with a lower resolution setting), the far right side of the ribbons are collapsed into unrecognizable icons or mini drop down menus. This is confusing and makes it difficult to find the utility or function you're looking for. It's especially bad for those of us who teach, moving from our personal computers to all kinds of projection systems at different resolutions. Our MS ribbon bars morph into something unrecognizable while we're presenting to several hundred people.
A similar thing happens with Adobe's top panels in InDesign, Photoshop, and Illustrator, so it's not just a Microsoft thing. It's becoming a common design theme throughout the computer interface design community.
--Bevi Chagnon
From: Jamous, JP
Date: Thu, Aug 04 2016 11:03AM
Subject: Re: Interaction with tab panels
← Previous message | Next message →
Thank you for this extra knowledge. I did not know it impacted low vision folks like that.
Well, it is a snowball effect. Microsoft patented it and declared that it is the best thing after sliced bread.
A buddy of mine that is a heavy Microsoft programmer contacted them and informed them how terrible it is for him and his customers. The answer was, "It is better for you than drop down menus. We do not create something that is not best for our customers."
Microsoft and Adobe could care less about accessibility from my experience. They only deal with accessibility to avoid legal issues. Aside from that they could care less.
Apple on the other hand, have done an amazing job with VoiceOver. I can set up any Apple device alone without sighted help. Even on the tinniest iPod, VoiceOver is available. This makes me wonder, "If they can put a screen reader on a tiny device running an ARM processor, don't you think Microsoft could do way better with Narrator?"
They are following Apple's business model now by providing Windows which runs on multiple devices. In fact, they changed the inner structure of Windows to match that of Mac. The only thing they did not touch was accessibility.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Chagnon | PubCom
Sent: Thursday, August 04, 2016 10:59 AM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Interaction with tab panels
JP Jamous wrote:
"Please, give me my dropdown menus again. The ribbon is terrible and even sighted folks agree with me. Most of them including programmers do not like the ribbon bar."
One key fault of the ribbon bar GUI becomes very evident when viewed on a large, wide-screen monitor: there's too much distance the eye must track from the far left edge to the far right edge. This is the eye-tracking distance. Some monitor setups force the user to not just move their eyes left-to-right over this long distance, but actually turn their heads from left to right, like watching a tennis match.
It's worse for those using screen enlargers. This factor about the GUI is tiring and puts a psychological barrier in the user's mind.
On the other hand, drop-down menus don't force such an extreme eye-tracking distance on the user.
Also, when a MS ribbon bar menu is viewed on a narrower monitor (or with a lower resolution setting), the far right side of the ribbons are collapsed into unrecognizable icons or mini drop down menus. This is confusing and makes it difficult to find the utility or function you're looking for. It's especially bad for those of us who teach, moving from our personal computers to all kinds of projection systems at different resolutions. Our MS ribbon bars morph into something unrecognizable while we're presenting to several hundred people.
A similar thing happens with Adobe's top panels in InDesign, Photoshop, and Illustrator, so it's not just a Microsoft thing. It's becoming a common design theme throughout the computer interface design community.
--Bevi Chagnon
From: Chagnon | PubCom
Date: Thu, Aug 04 2016 12:13PM
Subject: Re: Interaction with tab panels
← Previous message | Next message →
JP makes a point that has come up many times on this list:
Our software manufacturers aren't really giving us adequate accessibility tools, whether the tools are for accessing documents or tools for making accessible documents.
I won't single out Adobe or Microsoft because I find all of our manufacturers are dropping the ball.
So keep accessibility front and center on any user forums (manufacturer forums, not private discussion forums like WebAim).
Tell these software companies what you need their software to do.
And for those of us on this list with contacts at these companies, keep submitting your feature requests and bug fix reports for accessibility. We may be small in number, but we can still have a big voice.
I keep thinking that it's a matter of time before someone or the Department of Justice sues these companies for violations of Sec. 508. If those of us who create content don't have the tools to make our work accessible, can't the software companies be held responsible, too?
If a software program incorrectly converts a source document to PDF and mis-tags the PDF making it inaccessible, is that the fault of the person who created the content or the fault of the software company that made the conversion program?
FYI, PDF is in the public domain so many companies other than Adobe make PDF converters.
--Bevi Chagnon
-----Original Message-----
From: Jamous, JP [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, August 4, 2016 1:04 PM
To: = EMAIL ADDRESS REMOVED = ; WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: RE: [WebAIM] Interaction with tab panels
Thank you for this extra knowledge. I did not know it impacted low vision folks like that.
Well, it is a snowball effect. Microsoft patented it and declared that it is the best thing after sliced bread.
A buddy of mine that is a heavy Microsoft programmer contacted them and informed them how terrible it is for him and his customers. The answer was, "It is better for you than drop down menus. We do not create something that is not best for our customers."
Microsoft and Adobe could care less about accessibility from my experience. They only deal with accessibility to avoid legal issues. Aside from that they could care less.
Apple on the other hand, have done an amazing job with VoiceOver. I can set up any Apple device alone without sighted help. Even on the tinniest iPod, VoiceOver is available. This makes me wonder, "If they can put a screen reader on a tiny device running an ARM processor, don't you think Microsoft could do way better with Narrator?"
They are following Apple's business model now by providing Windows which runs on multiple devices. In fact, they changed the inner structure of Windows to match that of Mac. The only thing they did not touch was accessibility.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Chagnon | PubCom
Sent: Thursday, August 04, 2016 10:59 AM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Interaction with tab panels
JP Jamous wrote:
"Please, give me my dropdown menus again. The ribbon is terrible and even sighted folks agree with me. Most of them including programmers do not like the ribbon bar."
One key fault of the ribbon bar GUI becomes very evident when viewed on a large, wide-screen monitor: there's too much distance the eye must track from the far left edge to the far right edge. This is the eye-tracking distance. Some monitor setups force the user to not just move their eyes left-to-right over this long distance, but actually turn their heads from left to right, like watching a tennis match.
It's worse for those using screen enlargers. This factor about the GUI is tiring and puts a psychological barrier in the user's mind.
On the other hand, drop-down menus don't force such an extreme eye-tracking distance on the user.
Also, when a MS ribbon bar menu is viewed on a narrower monitor (or with a lower resolution setting), the far right side of the ribbons are collapsed into unrecognizable icons or mini drop down menus. This is confusing and makes it difficult to find the utility or function you're looking for. It's especially bad for those of us who teach, moving from our personal computers to all kinds of projection systems at different resolutions. Our MS ribbon bars morph into something unrecognizable while we're presenting to several hundred people.
A similar thing happens with Adobe's top panels in InDesign, Photoshop, and Illustrator, so it's not just a Microsoft thing. It's becoming a common design theme throughout the computer interface design community.
--Bevi Chagnon
From: Bryan Garaventa
Date: Thu, Aug 04 2016 1:26PM
Subject: Re: Interaction with tab panels
← Previous message | Next message →
Hi,
A quick question, is what you are building an Accordion, or a Tablist?
E.G A Tablist control includes all tabs within one parent container, and the controlled Tabpanel is outside of that container element, either positioned one on top of the other or side by side visually. Nevertheless, both containers are not nested.
An Accordion control is different however, in that the dynamically rendered content is nested within the same container element and inserted inline between the Accordion toggle elements.
Can you explain which one fits what you are doing?
The ARIA and keyboard usage paradigm will be different based on which one you are building.
Thanks,
Bryan
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Vemaarapu Venkatesh
Sent: Wednesday, August 03, 2016 8:19 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Interaction with tab panels
Bryan, I found interaction is perfect with tab panel in the mentioned pages by you. In the first page, tab items are selected with the focus and in the second page first tab item is expanded as soon as receiving the focus. In two pages, interaction is possible only with arrow keys inside tab panel and tab key wont take us to next tab item.
But in my case tab items are in collapsed state even after taking the focus to the tab panel and my main concern is "navigation is moving to other tab items in the list when we hit tab key when all items are collapsed". Is it fine like that.
Please refer
https://support.skype.com/en/faq/fa109/i-ve-forgotten-my-username-or-password
I am using NVDA+Firefox. Hope I am clear.
Regards,
venkatesh
On Wed, Aug 3, 2016 at 8:12 PM, Vemaarapu Venkatesh < = EMAIL ADDRESS REMOVED = > wrote:
> Hello all, Greetings
>
> If we consider tab panel, we should use arrow keys to interact with
> tabs inside the widget if I am not wrong.
>
>
> https://support.skype.com/en/faq/fa109/i-ve-forgotten-my-username-or-p
> assword
>
> When I interacted with the tab panel present in the above link, I
> observed 1. When all tabs are in collapsed state, I hit tab to enter
> into tab panel. Then I thought that focus moves out of tab panel to
> "Yes" button if I hit tab key once again. But navigation continues in
> tab panel i.e the other two tab items are in tab order. This behavior
> is not seen when any one of tab items is expanded.
> I feel that interaction inside the tab panel should be only with arrow
> keys but not with tab key anytime.
> 2. If I am expanding any tab item, the already selected tab item is
> not getting collapsed automatically. User has to collapse and expand manually.
>
> Whether these two behaviors are recommendable when I am interacting
> with tab panel widget.
>
> Hope you will correct me if I am going wrong with my perception.
>
> Regards,
> venkatesh
>
From: Sean Murphy
Date: Thu, Aug 04 2016 10:25PM
Subject: Re: Interaction with tab panels
← Previous message | Next message →
I completely agree, as I am a screen reader user myself. :-)
> On 4 Aug 2016, at 11:01 PM, Jamous, JP < = EMAIL ADDRESS REMOVED = > wrote:
>
> Sean,
>
> Quite interesting as I faced it myself first-hand when I taught blind folks how to use JAWS. The average person lacks the understanding of containers and how each responds to keyboard commands. I know because I have been a programmer and a JAWS scripter too. Yet, on some dropdowns, I do wonder sometimes which will make me go through the menu items as the developer might use tab and shift + tab rather than arrow keys.
>
> A prime example, JAWS and the worthless ribbon bar in Office. You can tab or shift + tab with it or use the arrow keys. Sometimes, you cannot use the up or down arrow keys and you have to use the left or right ones.
>
> Please, give me my dropdown menus again. The ribbon is terrible and even sighted folks agree with me. Most of them including programmers do not like the ribbon bar.
>
> I agree that a standard should be enforced in this regard.
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean Murphy
> Sent: Thursday, August 04, 2016 5:31 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Interaction with tab panels
>
> This is a interesting discussion. I was at a A11y Web Dev meeting a few weeks which the speaker mention the different user expectation on the desktop compared to the Web Browser. On the desktop people know when to use the tab and arrow keys. In the browser, people attend to use the tab key first then the arrow keys. He went on to say that movement in the wider world of the Web is to try and merge these two type of usage as one.
>
> Personally, I think if you are in a tab strip, menu, etc. Then you use the arrows key by default. AS this is what you do on the desktop. As well these are an single object regardless how they are built. The tab should move you to the next object (element).
>
> Sean
>> On 4 Aug 2016, at 1:19 PM, Vemaarapu Venkatesh < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> Bryan, I found interaction is perfect with tab panel in the mentioned
>> pages by you. In the first page, tab items are selected with the focus
>> and in the second page first tab item is expanded as soon as receiving
>> the focus. In two pages, interaction is possible only with arrow keys
>> inside tab panel and tab key wont take us to next tab item.
>> But in my case tab items are in collapsed state even after taking the
>> focus to the tab panel and my main concern is "navigation is moving to
>> other tab items in the list when we hit tab key when all items are
>> collapsed". Is it fine like that.
>> Please refer
>> https://support.skype.com/en/faq/fa109/i-ve-forgotten-my-username-or-p
>> assword I am using NVDA+Firefox. Hope I am clear.
>> Regards,
>> venkatesh
>>
>>
>> On Wed, Aug 3, 2016 at 8:12 PM, Vemaarapu Venkatesh <
>> = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> Hello all, Greetings
>>>
>>> If we consider tab panel, we should use arrow keys to interact with
>>> tabs inside the widget if I am not wrong.
>>>
>>>
>>> https://support.skype.com/en/faq/fa109/i-ve-forgotten-my-username-or-
>>> password
>>>
>>> When I interacted with the tab panel present in the above link, I
>>> observed 1. When all tabs are in collapsed state, I hit tab to enter
>>> into tab panel. Then I thought that focus moves out of tab panel to
>>> "Yes" button if I hit tab key once again. But navigation continues in
>>> tab panel i.e the other two tab items are in tab order. This behavior
>>> is not seen when any one of tab items is expanded.
>>> I feel that interaction inside the tab panel should be only with
>>> arrow keys but not with tab key anytime.
>>> 2. If I am expanding any tab item, the already selected tab item is
>>> not getting collapsed automatically. User has to collapse and expand manually.
>>>
>>> Whether these two behaviors are recommendable when I am interacting
>>> with tab panel widget.
>>>
>>> Hope you will correct me if I am going wrong with my perception.
>>>
>>> Regards,
>>> venkatesh
>>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >
> > > > > > >
From: Vemaarapu Venkatesh
Date: Thu, Aug 04 2016 11:21PM
Subject: Re: Interaction with tab panels
← Previous message | Next message →
Bryan,
After a bit of work around that, I seriously got the conclusion that it is
not tab panel but accordians. Here what made my life harder was aria-tab
roles are used while designing these accordians. This makes user to live in
fool's world as no differentiation is provided even though they are two
different custom widgets. I always tried to interact with the panel keeping
tablist in view but never bothered to consider that as accordians. Actually
I came across this type of scenario for the first time and really confused
with the reading order.
Thank you Bryan for your precise explanation of these widgets.
As experts discussed here, mode of interaction is differs with the same
widget in different cases provided with different apps. Really it will be
very difficult to teach someone if they arrives to us with these change of
behaviors. I think keeping different projections and resolutions in view
there should be some legal standards regarding these interaction modes like
WCAG 2.0, I mean to say there should be only one way of interaction if we
consider any component.
I don't think so WCAG 2.0 will talk about modes of interaction with the
different elements. Please let me know if any such standards exists as I am
not aware of it. Can I consider APG as such standards and can I raise any
violations pointing towards APG. Also correct me if WCAG 2.0 talks about
modes of interaction.
Regards,
venkatesh
On Thu, Aug 4, 2016 at 8:49 AM, Vemaarapu Venkatesh <
= EMAIL ADDRESS REMOVED = > wrote:
> Bryan, I found interaction is perfect with tab panel in the mentioned
> pages by you. In the first page, tab items are selected with the focus and
> in the second page first tab item is expanded as soon as receiving the
> focus. In two pages, interaction is possible only with arrow keys inside
> tab panel and tab key wont take us to next tab item.
> But in my case tab items are in collapsed state even after taking the
> focus to the tab panel and my main concern is "navigation is moving to
> other tab items in the list when we hit tab key when all items are
> collapsed". Is it fine like that.
> Please referhttps://support.skype.com/en/faq/fa109/i-ve-
> forgotten-my-username-or-password
> I am using NVDA+Firefox. Hope I am clear.
> Regards,
> venkatesh
>
>
> On Wed, Aug 3, 2016 at 8:12 PM, Vemaarapu Venkatesh <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hello all, Greetings
>>
>> If we consider tab panel, we should use arrow keys to interact with tabs
>> inside the widget if I am not wrong.
>>
>> https://support.skype.com/en/faq/fa109/i-ve-forgotten-my-
>> username-or-password
>>
>> When I interacted with the tab panel present in the above link, I observed
>> 1. When all tabs are in collapsed state, I hit tab to enter into tab
>> panel. Then I thought that focus moves out of tab panel to "Yes" button if
>> I hit tab key once again. But navigation continues in tab panel i.e the
>> other two tab items are in tab order. This behavior is not seen when any
>> one of tab items is expanded.
>> I feel that interaction inside the tab panel should be only with arrow
>> keys but not with tab key anytime.
>> 2. If I am expanding any tab item, the already selected tab item is not
>> getting collapsed automatically. User has to collapse and expand manually.
>>
>> Whether these two behaviors are recommendable when I am interacting with
>> tab panel widget.
>>
>> Hope you will correct me if I am going wrong with my perception.
>>
>> Regards,
>> venkatesh
>>
>
>
From: Bryan Garaventa
Date: Fri, Aug 05 2016 11:15AM
Subject: Re: Interaction with tab panels
← Previous message | Next message →
I'm glad that helped, we are currently discussing these differences so they can be added to the APG 1.1 document for Accordion, reference
https://lists.w3.org/Archives/Public/public-aria/2016Jul/0172.html
Going forward, the most accessible implementation recommended for a basic Accordion is the design pattern demonstrated at
http://whatsock.com/test/w3c/ARIA%20Accordions/demo.htm
Which can be easily implemented using the demo code at
http://whatsock.com/test/w3c/ARIA%20Accordions.zip
Kind regards,
Bryan
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Vemaarapu Venkatesh
Sent: Thursday, August 04, 2016 10:21 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Interaction with tab panels
Bryan,
After a bit of work around that, I seriously got the conclusion that it is not tab panel but accordians. Here what made my life harder was aria-tab roles are used while designing these accordians. This makes user to live in fool's world as no differentiation is provided even though they are two different custom widgets. I always tried to interact with the panel keeping tablist in view but never bothered to consider that as accordians. Actually I came across this type of scenario for the first time and really confused with the reading order.
Thank you Bryan for your precise explanation of these widgets.
As experts discussed here, mode of interaction is differs with the same widget in different cases provided with different apps. Really it will be very difficult to teach someone if they arrives to us with these change of behaviors. I think keeping different projections and resolutions in view there should be some legal standards regarding these interaction modes like WCAG 2.0, I mean to say there should be only one way of interaction if we consider any component.
I don't think so WCAG 2.0 will talk about modes of interaction with the different elements. Please let me know if any such standards exists as I am not aware of it. Can I consider APG as such standards and can I raise any violations pointing towards APG. Also correct me if WCAG 2.0 talks about modes of interaction.
Regards,
venkatesh
On Thu, Aug 4, 2016 at 8:49 AM, Vemaarapu Venkatesh < = EMAIL ADDRESS REMOVED = > wrote:
> Bryan, I found interaction is perfect with tab panel in the mentioned
> pages by you. In the first page, tab items are selected with the focus
> and in the second page first tab item is expanded as soon as receiving
> the focus. In two pages, interaction is possible only with arrow keys
> inside tab panel and tab key wont take us to next tab item.
> But in my case tab items are in collapsed state even after taking the
> focus to the tab panel and my main concern is "navigation is moving to
> other tab items in the list when we hit tab key when all items are
> collapsed". Is it fine like that.
> Please referhttps://support.skype.com/en/faq/fa109/i-ve-
> forgotten-my-username-or-password
> I am using NVDA+Firefox. Hope I am clear.
> Regards,
> venkatesh
>
>
> On Wed, Aug 3, 2016 at 8:12 PM, Vemaarapu Venkatesh <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hello all, Greetings
>>
>> If we consider tab panel, we should use arrow keys to interact with
>> tabs inside the widget if I am not wrong.
>>
>> https://support.skype.com/en/faq/fa109/i-ve-forgotten-my-
>> username-or-password
>>
>> When I interacted with the tab panel present in the above link, I
>> observed 1. When all tabs are in collapsed state, I hit tab to enter
>> into tab panel. Then I thought that focus moves out of tab panel to
>> "Yes" button if I hit tab key once again. But navigation continues in
>> tab panel i.e the other two tab items are in tab order. This behavior
>> is not seen when any one of tab items is expanded.
>> I feel that interaction inside the tab panel should be only with
>> arrow keys but not with tab key anytime.
>> 2. If I am expanding any tab item, the already selected tab item is
>> not getting collapsed automatically. User has to collapse and expand manually.
>>
>> Whether these two behaviors are recommendable when I am interacting
>> with tab panel widget.
>>
>> Hope you will correct me if I am going wrong with my perception.
>>
>> Regards,
>> venkatesh
>>
>
>
From: _mallory
Date: Tue, Aug 09 2016 5:28AM
Subject: Re: Interaction with tab panels
← Previous message | Next message →
I'm confused, why is an anchor with a role of "button" better than
a button? I vaguely recall something about working cross-browser...
is there a browser who won't work with real buttons?
_mallory
On Fri, Aug 05, 2016 at 05:15:13PM +0000, Bryan Garaventa wrote:
> I'm glad that helped, we are currently discussing these differences so they can be added to the APG 1.1 document for Accordion, reference
> https://lists.w3.org/Archives/Public/public-aria/2016Jul/0172.html
>
> Going forward, the most accessible implementation recommended for a basic Accordion is the design pattern demonstrated at
> http://whatsock.com/test/w3c/ARIA%20Accordions/demo.htm
>
> Which can be easily implemented using the demo code at
> http://whatsock.com/test/w3c/ARIA%20Accordions.zip
>
> Kind regards,
> Bryan
>
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> = EMAIL ADDRESS REMOVED =
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Vemaarapu Venkatesh
> Sent: Thursday, August 04, 2016 10:21 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: [WebAIM] Interaction with tab panels
>
> Bryan,
>
> After a bit of work around that, I seriously got the conclusion that it is not tab panel but accordians. Here what made my life harder was aria-tab roles are used while designing these accordians. This makes user to live in fool's world as no differentiation is provided even though they are two different custom widgets. I always tried to interact with the panel keeping tablist in view but never bothered to consider that as accordians. Actually I came across this type of scenario for the first time and really confused with the reading order.
> Thank you Bryan for your precise explanation of these widgets.
>
> As experts discussed here, mode of interaction is differs with the same widget in different cases provided with different apps. Really it will be very difficult to teach someone if they arrives to us with these change of behaviors. I think keeping different projections and resolutions in view there should be some legal standards regarding these interaction modes like WCAG 2.0, I mean to say there should be only one way of interaction if we consider any component.
> I don't think so WCAG 2.0 will talk about modes of interaction with the different elements. Please let me know if any such standards exists as I am not aware of it. Can I consider APG as such standards and can I raise any violations pointing towards APG. Also correct me if WCAG 2.0 talks about modes of interaction.
>
> Regards,
> venkatesh
>
> On Thu, Aug 4, 2016 at 8:49 AM, Vemaarapu Venkatesh < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Bryan, I found interaction is perfect with tab panel in the mentioned
> > pages by you. In the first page, tab items are selected with the focus
> > and in the second page first tab item is expanded as soon as receiving
> > the focus. In two pages, interaction is possible only with arrow keys
> > inside tab panel and tab key wont take us to next tab item.
> > But in my case tab items are in collapsed state even after taking the
> > focus to the tab panel and my main concern is "navigation is moving to
> > other tab items in the list when we hit tab key when all items are
> > collapsed". Is it fine like that.
> > Please referhttps://support.skype.com/en/faq/fa109/i-ve-
> > forgotten-my-username-or-password
> > I am using NVDA+Firefox. Hope I am clear.
> > Regards,
> > venkatesh
> >
> >
> > On Wed, Aug 3, 2016 at 8:12 PM, Vemaarapu Venkatesh <
> > = EMAIL ADDRESS REMOVED = > wrote:
> >
> >> Hello all, Greetings
> >>
> >> If we consider tab panel, we should use arrow keys to interact with
> >> tabs inside the widget if I am not wrong.
> >>
> >> https://support.skype.com/en/faq/fa109/i-ve-forgotten-my-
> >> username-or-password
> >>
> >> When I interacted with the tab panel present in the above link, I
> >> observed 1. When all tabs are in collapsed state, I hit tab to enter
> >> into tab panel. Then I thought that focus moves out of tab panel to
> >> "Yes" button if I hit tab key once again. But navigation continues in
> >> tab panel i.e the other two tab items are in tab order. This behavior
> >> is not seen when any one of tab items is expanded.
> >> I feel that interaction inside the tab panel should be only with
> >> arrow keys but not with tab key anytime.
> >> 2. If I am expanding any tab item, the already selected tab item is
> >> not getting collapsed automatically. User has to collapse and expand manually.
> >>
> >> Whether these two behaviors are recommendable when I am interacting
> >> with tab panel widget.
> >>
> >> Hope you will correct me if I am going wrong with my perception.
> >>
> >> Regards,
> >> venkatesh
> >>
> >
> >
> > > > > > >
From: Swift, Daniel P.
Date: Tue, Aug 09 2016 6:40AM
Subject: Re: [POSSIBLE SPAM] Interaction with tab panels
← Previous message | Next message →
I vaguely recall having a problem with older versions of IE and the button tag. I don't recall what the exact issue was or even if it was consistent but I do remember that in the particular situation(s) we ended up switching back to input type button.
-Dan
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of _mallory
Sent: Tuesday, August 09, 2016 7:28 AM
To: WebAIM Discussion List
Subject: [POSSIBLE SPAM] Re: [WebAIM] Interaction with tab panels
Importance: Low
I'm confused, why is an anchor with a role of "button" better than a button? I vaguely recall something about working cross-browser...
is there a browser who won't work with real buttons?
_mallory
On Fri, Aug 05, 2016 at 05:15:13PM +0000, Bryan Garaventa wrote:
> I'm glad that helped, we are currently discussing these differences so
> they can be added to the APG 1.1 document for Accordion, reference
> https://lists.w3.org/Archives/Public/public-aria/2016Jul/0172.html
>
> Going forward, the most accessible implementation recommended for a
> basic Accordion is the design pattern demonstrated at
> http://whatsock.com/test/w3c/ARIA%20Accordions/demo.htm
>
> Which can be easily implemented using the demo code at
> http://whatsock.com/test/w3c/ARIA%20Accordions.zip
>
> Kind regards,
> Bryan
>
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> = EMAIL ADDRESS REMOVED =
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Vemaarapu Venkatesh
> Sent: Thursday, August 04, 2016 10:21 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: [WebAIM] Interaction with tab panels
>
> Bryan,
>
> After a bit of work around that, I seriously got the conclusion that it is not tab panel but accordians. Here what made my life harder was aria-tab roles are used while designing these accordians. This makes user to live in fool's world as no differentiation is provided even though they are two different custom widgets. I always tried to interact with the panel keeping tablist in view but never bothered to consider that as accordians. Actually I came across this type of scenario for the first time and really confused with the reading order.
> Thank you Bryan for your precise explanation of these widgets.
>
> As experts discussed here, mode of interaction is differs with the same widget in different cases provided with different apps. Really it will be very difficult to teach someone if they arrives to us with these change of behaviors. I think keeping different projections and resolutions in view there should be some legal standards regarding these interaction modes like WCAG 2.0, I mean to say there should be only one way of interaction if we consider any component.
> I don't think so WCAG 2.0 will talk about modes of interaction with the different elements. Please let me know if any such standards exists as I am not aware of it. Can I consider APG as such standards and can I raise any violations pointing towards APG. Also correct me if WCAG 2.0 talks about modes of interaction.
>
> Regards,
> venkatesh
>
> On Thu, Aug 4, 2016 at 8:49 AM, Vemaarapu Venkatesh < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Bryan, I found interaction is perfect with tab panel in the
> > mentioned pages by you. In the first page, tab items are selected
> > with the focus and in the second page first tab item is expanded as
> > soon as receiving the focus. In two pages, interaction is possible
> > only with arrow keys inside tab panel and tab key wont take us to next tab item.
> > But in my case tab items are in collapsed state even after taking
> > the focus to the tab panel and my main concern is "navigation is
> > moving to other tab items in the list when we hit tab key when all
> > items are collapsed". Is it fine like that.
> > Please referhttps://support.skype.com/en/faq/fa109/i-ve-
> > forgotten-my-username-or-password
> > I am using NVDA+Firefox. Hope I am clear.
> > Regards,
> > venkatesh
> >
> >
> > On Wed, Aug 3, 2016 at 8:12 PM, Vemaarapu Venkatesh <
> > = EMAIL ADDRESS REMOVED = > wrote:
> >
> >> Hello all, Greetings
> >>
> >> If we consider tab panel, we should use arrow keys to interact with
> >> tabs inside the widget if I am not wrong.
> >>
> >> https://support.skype.com/en/faq/fa109/i-ve-forgotten-my-
> >> username-or-password
> >>
> >> When I interacted with the tab panel present in the above link, I
> >> observed 1. When all tabs are in collapsed state, I hit tab to
> >> enter into tab panel. Then I thought that focus moves out of tab
> >> panel to "Yes" button if I hit tab key once again. But navigation
> >> continues in tab panel i.e the other two tab items are in tab
> >> order. This behavior is not seen when any one of tab items is expanded.
> >> I feel that interaction inside the tab panel should be only with
> >> arrow keys but not with tab key anytime.
> >> 2. If I am expanding any tab item, the already selected tab item is
> >> not getting collapsed automatically. User has to collapse and expand manually.
> >>
> >> Whether these two behaviors are recommendable when I am interacting
> >> with tab panel widget.
> >>
> >> Hope you will correct me if I am going wrong with my perception.
> >>
> >> Regards,
> >> venkatesh
> >>
> >
> >
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
>
From: Jamous, JP
Date: Tue, Aug 09 2016 7:28AM
Subject: Re: Interaction with tab panels
← Previous message | Next message →
The only thing that comes to mind is styling.
I believe you are restricted to what you can do with styling as it comes to buttons. Yet with links you can make them link buttons and style them differently.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of _mallory
Sent: Tuesday, August 09, 2016 6:28 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Interaction with tab panels
I'm confused, why is an anchor with a role of "button" better than a button? I vaguely recall something about working cross-browser...
is there a browser who won't work with real buttons?
_mallory
On Fri, Aug 05, 2016 at 05:15:13PM +0000, Bryan Garaventa wrote:
> I'm glad that helped, we are currently discussing these differences so
> they can be added to the APG 1.1 document for Accordion, reference
> https://lists.w3.org/Archives/Public/public-aria/2016Jul/0172.html
>
> Going forward, the most accessible implementation recommended for a
> basic Accordion is the design pattern demonstrated at
> http://whatsock.com/test/w3c/ARIA%20Accordions/demo.htm
>
> Which can be easily implemented using the demo code at
> http://whatsock.com/test/w3c/ARIA%20Accordions.zip
>
> Kind regards,
> Bryan
>
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> = EMAIL ADDRESS REMOVED =
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Vemaarapu Venkatesh
> Sent: Thursday, August 04, 2016 10:21 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: [WebAIM] Interaction with tab panels
>
> Bryan,
>
> After a bit of work around that, I seriously got the conclusion that it is not tab panel but accordians. Here what made my life harder was aria-tab roles are used while designing these accordians. This makes user to live in fool's world as no differentiation is provided even though they are two different custom widgets. I always tried to interact with the panel keeping tablist in view but never bothered to consider that as accordians. Actually I came across this type of scenario for the first time and really confused with the reading order.
> Thank you Bryan for your precise explanation of these widgets.
>
> As experts discussed here, mode of interaction is differs with the same widget in different cases provided with different apps. Really it will be very difficult to teach someone if they arrives to us with these change of behaviors. I think keeping different projections and resolutions in view there should be some legal standards regarding these interaction modes like WCAG 2.0, I mean to say there should be only one way of interaction if we consider any component.
> I don't think so WCAG 2.0 will talk about modes of interaction with the different elements. Please let me know if any such standards exists as I am not aware of it. Can I consider APG as such standards and can I raise any violations pointing towards APG. Also correct me if WCAG 2.0 talks about modes of interaction.
>
> Regards,
> venkatesh
>
> On Thu, Aug 4, 2016 at 8:49 AM, Vemaarapu Venkatesh < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Bryan, I found interaction is perfect with tab panel in the
> > mentioned pages by you. In the first page, tab items are selected
> > with the focus and in the second page first tab item is expanded as
> > soon as receiving the focus. In two pages, interaction is possible
> > only with arrow keys inside tab panel and tab key wont take us to next tab item.
> > But in my case tab items are in collapsed state even after taking
> > the focus to the tab panel and my main concern is "navigation is
> > moving to other tab items in the list when we hit tab key when all
> > items are collapsed". Is it fine like that.
> > Please referhttps://support.skype.com/en/faq/fa109/i-ve-
> > forgotten-my-username-or-password
> > I am using NVDA+Firefox. Hope I am clear.
> > Regards,
> > venkatesh
> >
> >
> > On Wed, Aug 3, 2016 at 8:12 PM, Vemaarapu Venkatesh <
> > = EMAIL ADDRESS REMOVED = > wrote:
> >
> >> Hello all, Greetings
> >>
> >> If we consider tab panel, we should use arrow keys to interact with
> >> tabs inside the widget if I am not wrong.
> >>
> >> https://support.skype.com/en/faq/fa109/i-ve-forgotten-my-
> >> username-or-password
> >>
> >> When I interacted with the tab panel present in the above link, I
> >> observed 1. When all tabs are in collapsed state, I hit tab to
> >> enter into tab panel. Then I thought that focus moves out of tab
> >> panel to "Yes" button if I hit tab key once again. But navigation
> >> continues in tab panel i.e the other two tab items are in tab
> >> order. This behavior is not seen when any one of tab items is expanded.
> >> I feel that interaction inside the tab panel should be only with
> >> arrow keys but not with tab key anytime.
> >> 2. If I am expanding any tab item, the already selected tab item is
> >> not getting collapsed automatically. User has to collapse and expand manually.
> >>
> >> Whether these two behaviors are recommendable when I am interacting
> >> with tab panel widget.
> >>
> >> Hope you will correct me if I am going wrong with my perception.
> >>
> >> Regards,
> >> venkatesh
> >>
> >
> >
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
>
From: Jim Homme
Date: Tue, Aug 09 2016 7:41AM
Subject: Re: Interaction with tab panels
← Previous message | No next message
Hi Mary,
OK. Thanks for the answers and further instructions. I'm working through this and will have progress for you before I leave.
Jim
=========Jim Homme,
Accessibility Consultant,
Bender HighTest Accessibility Team
Bender Consulting Services, Inc.,
412-787-8567,
= EMAIL ADDRESS REMOVED =
http://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
E+R=O
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jamous, JP
Sent: Tuesday, August 09, 2016 9:28 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Interaction with tab panels
The only thing that comes to mind is styling.
I believe you are restricted to what you can do with styling as it comes to buttons. Yet with links you can make them link buttons and style them differently.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of _mallory
Sent: Tuesday, August 09, 2016 6:28 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Interaction with tab panels
I'm confused, why is an anchor with a role of "button" better than a button? I vaguely recall something about working cross-browser...
is there a browser who won't work with real buttons?
_mallory
On Fri, Aug 05, 2016 at 05:15:13PM +0000, Bryan Garaventa wrote:
> I'm glad that helped, we are currently discussing these differences so
> they can be added to the APG 1.1 document for Accordion, reference
> https://lists.w3.org/Archives/Public/public-aria/2016Jul/0172.html
>
> Going forward, the most accessible implementation recommended for a
> basic Accordion is the design pattern demonstrated at
> http://whatsock.com/test/w3c/ARIA%20Accordions/demo.htm
>
> Which can be easily implemented using the demo code at
> http://whatsock.com/test/w3c/ARIA%20Accordions.zip
>
> Kind regards,
> Bryan
>
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> = EMAIL ADDRESS REMOVED =
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Vemaarapu Venkatesh
> Sent: Thursday, August 04, 2016 10:21 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: [WebAIM] Interaction with tab panels
>
> Bryan,
>
> After a bit of work around that, I seriously got the conclusion that it is not tab panel but accordians. Here what made my life harder was aria-tab roles are used while designing these accordians. This makes user to live in fool's world as no differentiation is provided even though they are two different custom widgets. I always tried to interact with the panel keeping tablist in view but never bothered to consider that as accordians. Actually I came across this type of scenario for the first time and really confused with the reading order.
> Thank you Bryan for your precise explanation of these widgets.
>
> As experts discussed here, mode of interaction is differs with the same widget in different cases provided with different apps. Really it will be very difficult to teach someone if they arrives to us with these change of behaviors. I think keeping different projections and resolutions in view there should be some legal standards regarding these interaction modes like WCAG 2.0, I mean to say there should be only one way of interaction if we consider any component.
> I don't think so WCAG 2.0 will talk about modes of interaction with the different elements. Please let me know if any such standards exists as I am not aware of it. Can I consider APG as such standards and can I raise any violations pointing towards APG. Also correct me if WCAG 2.0 talks about modes of interaction.
>
> Regards,
> venkatesh
>
> On Thu, Aug 4, 2016 at 8:49 AM, Vemaarapu Venkatesh < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Bryan, I found interaction is perfect with tab panel in the
> > mentioned pages by you. In the first page, tab items are selected
> > with the focus and in the second page first tab item is expanded as
> > soon as receiving the focus. In two pages, interaction is possible
> > only with arrow keys inside tab panel and tab key wont take us to next tab item.
> > But in my case tab items are in collapsed state even after taking
> > the focus to the tab panel and my main concern is "navigation is
> > moving to other tab items in the list when we hit tab key when all
> > items are collapsed". Is it fine like that.
> > Please referhttps://support.skype.com/en/faq/fa109/i-ve-
> > forgotten-my-username-or-password
> > I am using NVDA+Firefox. Hope I am clear.
> > Regards,
> > venkatesh
> >
> >
> > On Wed, Aug 3, 2016 at 8:12 PM, Vemaarapu Venkatesh <
> > = EMAIL ADDRESS REMOVED = > wrote:
> >
> >> Hello all, Greetings
> >>
> >> If we consider tab panel, we should use arrow keys to interact with
> >> tabs inside the widget if I am not wrong.
> >>
> >> https://support.skype.com/en/faq/fa109/i-ve-forgotten-my-
> >> username-or-password
> >>
> >> When I interacted with the tab panel present in the above link, I
> >> observed 1. When all tabs are in collapsed state, I hit tab to
> >> enter into tab panel. Then I thought that focus moves out of tab
> >> panel to "Yes" button if I hit tab key once again. But navigation
> >> continues in tab panel i.e the other two tab items are in tab
> >> order. This behavior is not seen when any one of tab items is expanded.
> >> I feel that interaction inside the tab panel should be only with
> >> arrow keys but not with tab key anytime.
> >> 2. If I am expanding any tab item, the already selected tab item is
> >> not getting collapsed automatically. User has to collapse and expand manually.
> >>
> >> Whether these two behaviors are recommendable when I am interacting
> >> with tab panel widget.
> >>
> >> Hope you will correct me if I am going wrong with my perception.
> >>
> >> Regards,
> >> venkatesh
> >>
> >
> >
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
>