russmaxdesign / web-usability-resources

4 stars 0 forks source link

Tabs and screenreaders #12

Closed dominikwilkowski closed 7 years ago

dominikwilkowski commented 7 years ago

Rogers comments below:

With just the keyboard (Firefox, chrome, and I.E.) you can only move from one in-page tab to another with the left/right arrow keys. And when focus goes to the tab the section opens automatically. When tabbing down or up the page focus goes to first (or last) in-page tab and then you have to use the arrow keys, as the next tab action takes you to the next focusable item. In short, this appears to be how we are expecting it to behave with the keyboard and since there is a message for the sighted keyboard user they will be able to see what to do.

With the screen readers however, the performance of the in-page tab is not consistent. Some results with NVDA 2016 and JAWS 15 using different browsers below:

1. With NVDA 2016 and Firefox: You basically use the up/down arrow key to move between the in-page tab. When focus goes to a tab it doesn’t automatically open. Rather, the tab is identified with the label and tab state (e.g “expanded distribution” or “collapsed habitat”) . The next keyboard down arrow takes you to the message which indicates state and then reports the message – e.g. “collapse (or expanded) link use the arrow keys to select a tab”. And, the next arrow takes you to the next inpage tab. This basic pattern is followed even when you expand a tab by pressing the enter key. This means that if you select the second tab, for example, you still have to arrow past the third tab in order to get to the content. (NB: You can move from one tab to the next with the left/right arrow key the first time – but after that the left/right keys just read out the letters, as normally happens with most screen readers when using the left/right arrows).

2. NVDA and Chrome: Pretty much the same as for Firefox. But when you press the arrow key after the message is read out and move to the next tab, the screen reader includes the previous tab label in the reporting. E.g. when you go from Distribution to Habitat is says “clickable link habitat distribution.” Not sure why this is happening but if it only happens with this browser I wouldn’t worry about it.

3. With NVDA and I.E. 9: You can tab or arrow between the various tabs, but the message about using the arrow key is not always readout. When you expand a section it is difficult (or impossible) to get to the content of that section with the arrow keys – it kept jumping down to the activities part of the page.

4. NVDA and I.E. 11: Can move between in-page tab items with the tab key or arrows. The message about using the arrow key and the state is reported. Many times when you expand a section, the screen reader starts reading some of the content from the activities section.

5. JAWS 15 and I.E. 11: You can tab or arrow to the in-page tabs. The state (expanded or collapsed) is reported, when you change state by pressing enter this is also reported. When moving to a tab, most of the time (but not always) the message about using arrow keys is read out. When an in-page tab is expanded it is necessary to go through the remaining tabs with the arrow keys before getting to the content. That is, focus doesn’t go to the top of the opened tab.

6. JAWS and Firefox: You can tab or arrow from tab to tab. The message is read out and when expanded this is reported. However, not able to move directly from label to content with either the tab or arrow key. Need to go through the remain in-page tab items first.

All up, there appears to be some browser compatibility issues which could be potentially confusing for some screen reader users.

Suggestions, if possible: Can the in-page tabs be made so that they only operate with the arrow key? And, when a new tab is opened focus goes to that content container. If this is the case, we could change the help message to some think like: “Arrow to change tab. Enter to open tab.” Hopefully this would make sense to keyboard users who both use or don’t use a screen reader. To help with the testing could you put a link (that doesn’t go anywhere – e.g. Link not active) at the end of both the Distribution and Habitat content.

I checked out a few examples of in-page tab and found these which are reasonably keyboard accessible with and without NVDA screen reader. However, they all appear to have at least some problems.

Top crafted beers: http://codepen.io/jeffsmith/full/mPByya/ Without NVDA works fine tabbing, only partially works when trying to arrow between the tab items. With NVDA can tab or arrow to the tab items, open item with enter and then go directly to the content.

Accessible tab navigation V5: https://websemantics.uk/articles/accessible-tab-navigation/ Without NVDA, you tab to the first item (or another item if already opened) and then move between the in-page tab items with the left/right arrow keys. With NVDA when arrowing down the page the tabs are identified and one that is open is described as selected. It then seems to be a little different inconsistent depending on how you enter the in-page tab menu. Sometimes, if you arrow down into it, you move to other tabs with the left/right arrow key and open the tab with enter, and focus goes directly to the heading at the top of the content. However, at other times if you tab or arrow to the tab menu item you need to use the up/down key to move between the in-page tab options. When tabbing down the page, you move to the first tab item (or another tab if it is already open) with the keyboard tab key and the screen reader automatically switches to forms mode. You then use the left/right arrow keys (not tab) to move between the tab options and the open tab is identified as selected. You select a tab with the enter key which then moves focus directly to the heading at the top of the opened panel. If a tab is already opened when you move to it, you get to the content by pressing the enter key which causes focus to go to the heading. (Slight problem, when you move away from the in-page tab menu, the screen read switches out of forms mode and if you then arrow back to the tab menu you now have to use the up/down keys to move between items.)

Simple Aria-tab interface: http://heydonworks.com/practical_aria_examples/#tab-interface Without NVDA, you tab to either the first in-page tab item, or the tab for an item that is already opened. Then use the left/right arrow keys to move between the items. With NVDA: When arrowing down page it is a little confusing. Unable to arrow to the individual tab items – rather they all get readout together. However when tabbing it works well, move between items with left/right arrow keys and the selected item is identified as selected. You press tab to enter the content of the selected item.

dominikwilkowski commented 7 years ago
  • The tabs, oh the tabs :) I am detecting now when we use tabs vs arrow keys and modify the behaviour accordingly.
  • NVDA with Firefox: When you arrow into the tabs, you can arrow along the different tabs with the up/down arrow.
  • NVDA with Firefox: When you tab into the first tab, the screen reader identifies the tab label (distribution)and then says "use the arrow key to select a tab. Link". When you press the arrow key, you get this same message. But, when you press it again you move to the next tab and the content for that tab is displayed. If I now press the enter key the screen reader says "out of list" and then starts reading the content of the section. You move between the tabs with the up/down arrows. **\ NVDA with IE: When you arrow to the first tab item it is identified and if it is collapsed or expanded. The next arrow press takes you to the message about using the arrow key and the next arrow press takes you to the next tab and its content is displayed. When you press the enter key the screen reader reports "out of list" and starts reading the content. NB: It seems to work in exactly the same way if you just use the tab key instead of the arrow key.

So when you use the tabs and hit enter the focus is moved automatically to the newly opened tab which has a aria-label attribute with the words �Open tabular content�. Not sure if this is read out though so please check for me.

  • NVDA with Firefox: The aria-label is not read out. Rather when you press enter to open/select a tab the screen reader starts reading the content of the opened tab.
  • NB: If I manually switch to forms mode before tabbing to the first item (or after I am on the first item) I can use the left/right arrow keys to move between the tabs and the content of each tab is displayed when it gets focus. If I now press enter, the screen reader says "open tabular content section", but I can't move into the content with the down arrow key (I can tab to the focusable item in the content). But, I can't see any reason why someone would manually switch to forms mode so this is not really relevant.
  • NVDA with IE: The aria-label is not read out at all, even if I manually switch modes.
  • JAWS with IE: Can arrow between the tab items with up/down arrows and when focus goes to a new tab it is described as collapsed (or expanded). If you then press enter the content is presented and the screen reader starts reading it. You can arrow through the content of the expanded tab or go back up to the tab menu and move to another (collapsed) tab which can then be selected by pressing enter. The message about using the arrow keys is not read out. NB: when you use the tab key rather than the arrow keys to move between tab items it behaves in the same way.
  • JAWS with Firefox: When arrowing JAWS behaves in basically the same was as it does with Firefox. However, when tabbing the message about using the arrow key is readout, but you can't move to another tab with the arrow keys. When you select a tab with the enter key the content of the tab is then readout.
dominikwilkowski commented 7 years ago

We made the help bubble aria=hidden and now it all seems pretty straight forward. Closing this issue now.