What keystrokes should one use to navigate tabs on a web page using JAWS Screen Reader? I'm talking about tabs within a web page, not separate web pages opened in different tabs. Such tabs usually appear in the middle of web pages.
What I want to know is how to navigate from one tab to its associated content area. Also, once I'm done reading the tab's content, I want to go back to tab titles, switch to another tab, and then read that second tab content.
I help to build websites that are accessible to screen reader users. An answer to this question would allow us to test what we develop.
Within tabs user will expect to use left/right arrow to navigate between tabs.
1. User press tab key to focus to the tab strip; the first tab item gets focus.
2. Then will use left/right arrow to jump between tabs.
3. Pressing tab key again, will move the focus out of the tab strip to the next focusable element.
Complete aria guidelines for tabpanel is here: https://www.w3.org/TR/wai-aria-practices-1.1/#tabpanel
Once a tab control has focus, use the apostrophe key to navigate through tabs.
Related
When a user clicks tab on my page, it travels to all the links and buttons. Simply anything that is interactive. This works fine.
But how will a person that has accessibility limitations know there is a text on the page and to get it read out or to tab to it.
What's the norm here. Cause I tried the same on well known sites like stackoverflow and bbc.co.uk. They are doing the same where tabbing only works on links and buttons. It ignores text.
What about text. I tried using arrow keys which does nothing. If I press down it scrolls the page.
I get that the person could highlight the text and then get it read out to them with a screen reader. But that is assuming they are able to highlight in the first place.
What's the expected behaviour. How do we deal with text to get read out.
Imagine a page in following format. At present tab skips all text and only highlights the links and buttons. How do we handle text for accessibility. How do we set it up for keyboard access or have I pictured this wrong and text should indeed be ignored.
<!DOCTYPE html>
<html>
<body>
<h1>Heading 1</h1>
<p>This is some sample text.</p>
<h2>Heading 2</h2>
<p>This is some more sample text.</p>
<h3>Heading 3</h3>
<p>Here's even more sample text.</p>
<!-- All the above ignored by screen reader unless you highlight with a mouse, arrow key does nothing even on sites like bbc.co.uk -->
<button>Button 1</button>
Link 1
<button>Button 2</button>
Link 2
</body>
</html>
P.S: If it matters, using mac with built in screen reader. Also tried on Windows with NVDA, same outcome.
You don’t need to do anything additional to allow for reading your website (except for providing a proper semantic structure of your document, which you did).
Desktop screen readers distinguish between reading and interaction. The latter is done via the Tab keys.
As you mentioned, arrow keys are usually used for reading, but only together with a modifier key.
According to WebAIM’s guide on Using VoiceOver to Evaluate Web Accessibility, you can use
VO+a to start reading
VO + → to read next item
The modifier key for VoiceOver, here referred to as VO can be customised. By default, it’s Control + Option. So you’d press Control + Option + a to start reading.
You are essentially asking how to use a screen reader. #andy already spoke about VoiceOver so I'll comment on NVDA since you said "Also tried on Windows with NVDA, same outcome."
Using the tab key is just one way to navigate a webpage. Anyone can use tab regardless of whether a screen reader is running or not.
But with a screen reader such as NVDA (or JAWS) on a PC, you have a ton of shortcut keys for navigating. When NVDA is running, the down arrow will navigate to the next DOM elements (*) so you can access all the text on the page.
(*) It's not really the next DOM element but the next element in the accessibility tree, which is like a subset of the DOM. From the "Accessible Name and Description Computation 1.1" document, the "Introduction" section says:
User agents acquire information from the DOM and create a parallel structure called the accessibility tree, made up of accessible objects. An accessible object provides information about its role, states, and properties.
And the "accessibility tree" is defined as:
Tree of accessible objects that represents the structure of the user interface (UI). Each node in the accessibility tree represents an element in the UI as exposed through the accessibility API; for example, a push button, a check box, or container.
Also, the down arrow might not navigate to the next DOM element if you are in "forms mode". You have two modes you can run a screen reader in: "Forms mode" and "Browse mode". (The actual term for the mode might be different for different screen readers but conceptually they're "forms" and "browse"). The two modes automatically switch between the two by default (unless you change your screen reader settings).
In "browse mode", the down arrow key moves to the next DOM element. Browse mode also allows lots of other keyboard shortcuts such as the H key to navigate to the next heading (<h1>, <h2>, etc), the T key to navigate to the next table (<table>), the L key to navigate to the next list (<ul>, <ol>, <dl>), etc. NVDA and JAWS have similar keyboard shortcuts but occasionally the shortcut letter might be different.
If you tab to a form element such as an <input>, NVDA and JAWS will automatically switch from "browse mode" to "forms mode". In browse mode, all keyboard events are interpreted by the screen reader first but in forms mode, the keyboard events are sent to the browser. This lets you type the letter "H" or "T" or "L" into the <input> without the screen reader trying to navigate to the next heading, table, or list (respectively). So when you're in "forms mode", the down arrow will not move to the next DOM element.
That might be what you were experiencing when you said the down arrow key was not working with NVDA.
I have a modal that consists of tab layout to enter some form data. The form is a list of radiogroups that can be quite long.
For a user to get back to the tab, currently they have to shift+tab all the way back through the radio buttons to get back to the tab.
I know escape should close the modal. What is the expected keyboard navigation to return to a tab from a tab panel, so the user doesn’t have to shift tab through all of the radio buttons?
There is no predefined standard keyboard shortcut to go back to a tab control from inside its content.
IN a native app, you can go to next/previous tab with Ctrl+Tab/Ctrl+Shift+Tab or Ctrl+PageDown/Up, or sometimes Ctrl+number.
However, on the web, these shortcuts are of course already taken to control the tabs of the browser itself. You won't be able to intercept them for your own use, and even if you could, it would be a terribly bad idea because you would prevent the user from changing browser tab.
If your modal dialog is so big and so long, maybe you can think about modifying the behavior of the escape key.
On first press, you go back on the tab control, and if you area already on the tab control then it closes the dialog.
The user whould have then to press escape twice to close the dialog completely. This is a change from standard escape behavior, but it's maybe more acceptable than defining a completely new keyboard shortcut that no one will use because it's unknown or they didn't get the information at proper moment or didn't remember about it.
More generally, it's maybe the sign that your UI design is too complicated and that you should simplify it or organize it differently.
What about splitting into different dialogs (e.g. one per tab) ? Making groups that you can expand/collapse ? etc.
A big part of accessibility is also about making things simple. If it's too complicated to do it accessibly, maybe you should simplify.
There is no such keyboard shortcut defined for this action in web applications. If you take a look at the "keyboard interaction" section of the W3's Authoring Practices document on "Tabs":
For the tab list:
Tab:
When focus moves into the tab list, places focus on the active tab element.
When the tab list contains the focus, moves focus to the next element in the page tab sequence outside the tablist, which is the tabpanel unless the first element containing meaningful content inside the tabpanel is focusable.
When focus is on a tab element in a horizontal tab list:
Left Arrow: moves focus to the previous tab. If focus is on the first tab, moves focus to the last tab. Optionally, activates the newly focused tab (See note below).
Right Arrow: Moves focus to the next tab. If focus is on the last tab element, moves focus to the first tab. Optionally, activates the newly focused tab (See note below).
When focus is on a tab in a tablist with either horizontal or vertical orientation:
Space or Enter: Activates the tab if it was not activated automatically on focus.
Home (Optional): Moves focus to the first tab. Optionally, activates the newly focused tab (See note below).
End (Optional): Moves focus to the last tab. Optionally, activates the newly focused tab (See note below).
Shift + F10: If the tab has an associated popup menu, opens the menu.
Delete (Optional): If deletion is allowed, deletes (closes) the current tab element and its associated tab panel, sets focus on the tab following the tab that was closed, and optionally activates the newly focused tab. If there is not a tab that followed the tab that was deleted, e.g., the deleted tab was the right-most tab in a left-to-right horizontal tab list, sets focus on and optionally activates the tab that preceded the deleted tab. If the application allows all tabs to be deleted, and the user deletes the last remaining tab in the tab list, the application moves focus to another element that provides a logical work flow. As an alternative to Delete, or in addition to supporting Delete, the delete function is available in a context menu.
Notably absent is any shortcut for the operation you are envisioning. You may look to QuentinC's answer for some alternative solutions from more of a UX perspective.
I am improving the accessibility of a website to make sure users can easily navigate using the keyboard only. There is a button that generates a file, but after clicking on the button, the generic browser download dialog appears at the bottom of the page, and the focus still stays on the button. Users with a screen reader are not notified about the dialog.
There is a way to focus on the dialog when it appears?
I am able to focus on elements of the page, but since the dialog is a browser feature, I have no idea how to do it!?
I will appreciate any guidance what can you give me. Thank you!
You do not have control to do this, plus this is expected behaviour and there is nothing you need to do.
Screen reader users will go out of the active screen using shortcut keys if they wish to access the file.
Other considerations as you said "button" in your question
You should not use a <button> element to generate a file. File downloads should always be a hyperlink (<a>).
If the document requires variables to be passed and you are able to pass them via a GET request then the hyperlink href should be the URL + GET parameters.
The advantage of this for everyone is that they can middle click to open the document in a new window (or right click and choose "open in new window" etc.), plus it works without JavaScript and is easily indexed by Search Engines.
Also adding the download attribute to a hyperlink has some advantages, especially as in some screen readers it gets signalled to users that this link will download a document.
When creating a download link you should state the document type (pdf, word etc.) and document size for accessibility. You can do this with visually hidden text if your design does not allow for it.
I have written a reasonably in-depth answer on how to add the file size and file type info for screen readers here. About 70% of it is relevant to you.
I want to create a popup next to some data that contains a few input fields. Let's pretend that the we have the following document structure
<input name="before-the-data" type="text />
<div id="the-data"><!-- presents some data --></div>
<input name="after-the-data" type="text />
When you tab forward from before-the-data the popover should open and focus should go to the first input in this popover. This popover is appended to the body kinda of like Modal from material-ui so that it lies above the rest of the content. Similarly the popover should open when you tab backwards from after-the-data.
The popover should behave as if it were inside #the-data for navigation purposes but the actual position would be at the end of <body> for presentation purposes.
To achieve this effect, I set tabindex="0" on #the-data and trigger opening the modal and shift focus into it. This works fine so far.
Now for the question: How do I best create the following effect?
You should be able to navigate back out of the modal. My idea was this: When focus shifts from it or the user clicks outside the modal, we close it and restore focus to the element that had focus before it opened up. This can be done with a simple onblur handler and a onclick on a backplane. To support tabbing, the resulting modal looks like this:
<div id="backplane" onclick="closeAndRestoreFocus()"
onfocusout="checkCloseAndRestoreFocus()">
<div id="beforecanary" onfocus="shiftFocusBefore()" tabindex="0"/>
<!-- popover content -->
<div id="aftercanary" onfocus="shiftFocusAfter()" tabindex="0"/>
</div>
You can see that I added two divs that you can tab to beforecanary and aftercanary. When they get focused they shift focus to before-the-data and after-the-data respectively, to simulate as if the popover was actually inside #the-data.
At this point, you hopefully have understood what I am trying to create. Thus, the question: How good is this approach in general with respect to accessibility and how can I make sure I follow best practices of WAI-ARIA?
we close it and restore focus to the element that had focus before it opened up
That might be considered a tab trap, 2.1.2 No Keyboard Trap. Isn't the element that had focus before the popup the #the-data? So if I tab from before-the-data to #the-data, the popup will open. If I press esc to close the popup (you didn't mention that esc would close the popup but it should), the focus goes back to #the-data, which will automatically open the popup again, won't it? (Because onfocus() ran again.)
If I just tab through the entire process, I think it would work. It's just the dismissing of the popup that causes the problem. Tabbing straight through everything would move focus from before-the-data to #the-data to the elements in the popup to after-the-data then to the rest of the page, right?
When tabbing backwards, from after-the-data to #the-data, is the focus moved into the last element in the popup? Since I'm tabbing backwards, it needs to be on the last item so that I can continue tabbing backwards through the popup and then to before-the-data.
The popover should behave as if it were inside #the-data for navigation purposes but the actual position would be at the end of <body> for presentation purposes.
If the popup is in the DOM at the end, that would not allow a natural tab order. You can certainly put it there but then you have to manage the tab order. It would be much simpler if the popup was truly part of #the-data. Then the browser handles the tab order naturally.
You also have to be careful with automatically opening a popup but it might be a violation of 3.2.1 On Focus. See "Example of a Failure: A help dialog". It sort of describes what you are doing but is a little different. In the failure example, focus is moving to an input field, and the popup opens automatically and the focus moves from the input to the popup. Your case is a little different because you move the focus off the input first (or before-the-data) and then the popup displays, which would not violate 3.2.1. I just wanted to point this out in case you change your interaction model.
So in summary, your current behavior is kind of like a skip link. Skip links are often implemented as "hidden" links that only become visible when you tab to them and allow you to jump to a location on the page. The fact that they become visible upon focus is how your popup works (since it too becomes visible when it receives focus). The difference is that skip links do not dismiss if you press esc. They do dismiss if you click outside of them. I think that's the behavior you're trying to mimic. If you ignore my comment earlier that esc should dismiss your popup, then you'll be ok. I only had that comment because it sounded like your popup was like a modal dialog.
I recently noticed a very weird problem with VoiceOver's web navigation on tabs and tab panels. In particular, if the wrapper wrapping the tabs and tab panels has attribute aria-label set, then VoiceOver navigation cannot navigate to tab panel when switching tabs.
The problem may be hard to describe by words, thus I created this fiddle to demonstrate. Notice that the outside wrapper div has aria-label="Wrapper". Below are the steps to recreate the problem:
Run the jsFiddle to get the result area loaded.
Navigate to one of the tab buttons either by using mouse or keyboard navigation.
Activate VoiceOver.
Use VO + Right Arrow to try to navigate to tab panel content, this should work.
Use VO + Left Arrow to navigate back to the second tab, press VO + Space to activate the tab.
Now using VO + Right Arrow try to navigate to the new tab panel. This will fail.
After the above steps, switching between tabs doesn not fix the problem, you cannot navigate to the panel whatsoever. But if you remove the aria-label="Wrapper" from the wrapper div, everything works again.
Does anyone familiar with VoiceOver and WAI-ARIA know where the problem might be?
If the two tabs contain just the strings "Tab panel 1" and "tab panel 2", then the issue appears to be fixed. Tested with OS X 10.11.1.
Yes, I know that the question is pretty old, but I'm adding my answer for future reference, just in case! :-)