I know DIVs and P elements are not inherently focusable and can be made to be one by adding tabindex attribute. I am trying to make a Screen Reader friendly website and was wondering if it is necessary to have tabindex on each and every DIVs and P on my site so that the screen reading software like JAWS, NVDA and Chrome Vox can read its content.
Right now using Chrome Vox, it does not read a Paragraph content unless I have a "tabindex = 0" as an attribute. Am I testing it incorrectly? Do people who use screen reading software use some other way to read the page content then hitting tab to shift focus from element to element?
Only controls you want people to interact with (e.g. click or type into) should be focusable.
You should not need to make them focusable just to allow them to be read (and no screen reader I've ever tested (which doesn't include Vox) has required it).
Making them focusable would make it harder for people to use the site since they would have to tab through more elements to get the ones they want to interact with.
From the Chrome Vox documentation:
To navigate through the text on a screen, you can use the ChromeVox modifier keys. On a ChromeBook, the ChromeVox keys are Shift and Search, on Mac OS X the ChromeVox keys are Control and Command and on other platforms, such as Windows, the ChromeVox keys are Control and Alt. To move through a page, press the ChromeVox keys alongside the Up and Down arrow keys to navigate through the page.
you only have to put a tabindex="-1" on div tags which are the target of an anchor link
Go to anchor
[...]
<div id="targetanchor" tabindex="-1">
Using Chromevox, you have a list a shortcut to navigate through the page that you should be aware of, see here: http://www.chromevox.com/en/keyboard_shortcuts.html (ChromeVox + Down to navigate backward for instance)
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 some text that displays if there is an error
<div>Error message</div>
When the error div is displayed I want the user to be able to tab with their keyboard over this so it can be read by a screen reader so it is accessible for everybody.
While there is a simple way to accomplish this, it is not how screen reader users would expect an error message to be used: Expectation is to have the error when focussing the input element itself.
Screen reader support is not rendering content accessible to everybody. There are plenty different kinds of disabilities, and only some users benefit from screen readers. For others, other techniques are necessary.
For example, colour contrasts and a layout that does not break when font size is increased helps users with visual impairments, and keyboard focus needs to be visible for those who can see but navigate by means of keyboard.
As a start, I recommend the W3C’s Stories of Web Users in How People with Disabilities Use the Web to get an idea. The other articles and videos on that site are very well done, as well.
The foundation for any accessibility technique is to properly structure HTML, use headlines and landmarks for orientation, and use semantic tags instead of generic <div>.
How screen reader users navigate
There are several ways to navigate a document/a page with a screen reader, depending on current use case:
Simply read all elements on the page (including text)
Read the next/previous block of content
Navigate to a heading via a list of headings
Navigate to a landmark/form from a list of landmarks
Navigate to a link via a list of links
Navigate to the next/previous interactive element by means of tab
Aspects to render an error message helpful to screen readers
It should never be necessary for a (screen reader) user navigate/explore the site to see whether there was an error. The error should be announced immediately after the intended interaction.
How to achieve this, depends on how you are running form validation. Inline, server- or client side. Web AIM have a great article on Usable and Accessible Form Validation and Error Recovery.
For example, if your error message is related to an input field, and you have client-side validation, it is very important to establish the relationship between them, which is often achieved by means of aria-describedby.
<label>Name
<input type="text" name="name" autocomplete="name" aria-invalid="true" aria-describedby="name-err">
</label>
<div id="name-err">Please provide a name</div>
If validation is run on Submit, a best practice is to set focus to the first input in error via JavaScript .focus().
How to make any element tab-able
The tabindex attribute will render any element reachable by means of tab. You should not set it to a positive value.
<div tabindex="0">Error message</div>
If you want an element to receive focus only programmatically by means of JavaScript (on submit, for example), but not by means of tab, you can use tabindex="-1".
I'm doing accessibility work and testing tab focus.
Is there an easy way skip focus to a specific element on chrome or any other browser? For example, there is a button in the middle of the page. How can I quickly focus that element without tabbing through everything before it first?
Just use the focus method in JavaScript:
document.getElementById('myButton') .focus();
The focus method exists on all elements that are naturally focusable (like buttons, links, form elements), or that have been made focusable with the tabindex attribute.
For input elements, you can also use the autofocus attribute to tell the browser to focus it as soon as the page is loaded.
Many websites use "skip links" for the ability to bypass lengthy navigation menus and quickly access the certain areas of the page. This is useful for end-users as well as developers who are testing webpages.
The basic principle is that you'll have invisible links at the very beginning of the page that use anchor elements and IDs (just like any in-page link).
For example:
<body>
Skip to main content
...
<main id="maincontent">
<h1>Heading</h1>
<p>This is the first paragraph</p>
WebAIM has a very good tutorial on this.
http://webaim.org/techniques/skipnav/
When you visit their site, press the TAB key before doing anything else, and you'll see an example of how this works.
I would consider this method to be more reliable than using JavaScript, as HTML is more widely supported.
Open chrome developper tools
Inside the console, you can focus any element using the following:
document.querySelector(selector).focus();
The selector can be obtained right clicking the element inside the code of the developer tools and selecting copy / copy selector
This does not required the element to have an id attribute, but you still can use it.
Conflicts between JAWS table navigation short keys and custom implemented navigation keys(i.e. arrow keys)
I am trying to make an HTML table accessible using keyboard as well as readable using JAWS Screen reader.
To make it keyboard accessible i am doing following things:
- Added keypress events on table cells for arrow keys (left, right, top, bottom)
To make it JAWS readable i am doing following things:
- Added caption,summary to table
- Added scope=col to table headers
- Added ARIA roles like Application, row, grid, gridcell
Keyboard navigation is working fine when the page is run without using JAWS.
JAWS also read the table fine provided JAWS shortcuts are used.
When it is run with JAWS custom implemented keyboard navigation does not work properly.
To move focus to different cell using custom implemented keyboard navigation (i.e. arrow keys), i have use INSERT + 3 key followed by an arrow key.
This will move focus to different cell but it will not change JAWS current cell focus. So when JAWS read, it will read the cell other than the actual focused cell.
Example page URL : http://test.cita.illinois.edu/aria/grid/grid1.php
The above page supports custom keyboard navigation(i.e. arrow keys). Try to read above page using JAWS.
Please help to make it keyboard accessible at the same time readable by JAWS.
Appreciate your help!
Thanks a lot for your quick reply! That was very good information you provided.
However I have few more queries regarding this. It would be great if you could help.
JAWS provides support for various cursors like Virtual PC Cursor, PC Cursor, JAWS Cursor.
As per my knowledge when we specify role="application", JAWS runs on PC Cursor and whatever functionality provided in website are usable using the provided keystrokes.
The functionality i want to achieve especially with HTML Table is, user should be able to navigate using arrow keys as well as JAWS should read the currently focused content.
So the doubt here is why JAWS does not readout currently focused content in in PC Cursor.(in html table it can be currently focused cell).
It would be helpful if you could explain, how the JAWS user ideally uses web sites using JAWS (specifically with information rendered in HTML Table).
I have a complex table having following features and would like it to be accessible by keyboard and readable by JAWS:
Table with expand/collapse icon. Clicking on Expand/Collapse icon or pressing +/- from keyboard the nested table should be visible to user.
Each row of table is having some action items and pressing a key or clicking on it should perform an action. (like each row shows unique product information and user can buy(action item) by pressing some key or clicking on a button. )
I tried using dojo grid and it provides to navigate using keyboard arrow keys and there is a JAWS shortcut to readout the currently focused cell i.e INSERT + UP Arrow.
Try adding role="application" to the table or a surrounding element.
There is no way I know of to do what you want. I'm a Jaws user and the table is fine as is. I would not use your site if your custom navigation keys overrode Jaws defaults. The issue with overriding the defaults is it eliminates the ability to review character by character. If I wanted to check the spelling of a word in the table cell I could read letter by letter with the arrow keys. Disabling this ability of jaws is unacceptable. The reason I do not believe it is possible to do what you want is because Jaws uses a virtual buffer with information obtained from the internet browser to format the page in a way easier to read with a screen reader. In my experience it's murky where the boundary between the browser and Jaws is. This means that you probably cannot capture jaws specific keystrokes before Jaws does. Using the insert+3 key followed by an arrow key will not work with jaws because the key is being passed to the browser. This means the table focus is changing in the browser but there is no way to force that change in the model of the page Jaws uses.
Is there any way in HTML to tell the browser not to allow tab indexing on particular elements?
On my page though there is a sideshow which is rendered with jQuery, when you tab through that, you get a lot of tab presses before the tab control moves to the next visible link on the page as all the things being tabbed through are hidden to the user visually.
You can use tabindex="-1".
Only do this if you are certain it does not remove functionality for keyboard users.
The W3C HTML5 specification supports negative tabindex values:
If the value is a negative integer
The user agent must set the element's tabindex focus flag, but should not allow the element to be reached using sequential focus navigation.
Watch out though that this is a HTML5 feature and might not work with old browsers.
To be W3C HTML 4.01 standard (from 1999) compliant, tabindex would need to be positive.
Sample usage below in pure HTML.
Focusable
<a tabindex="-1" href="#" onclick="return false">Not focusable</a>
Focusable
Don't forget that, even though tabindex is all lowercase in the specs and in the HTML, in Javascript/the DOM that property is called tabIndex.
Don't lose your mind trying to figure out why your programmatically altered tab indices calling element.tabindex = -1 isn't working. Use element.tabIndex = -1.
If these are elements naturally in the tab order like buttons and anchors, removing them from the tab order with tabindex="-1" is kind of an accessibility smell. If they're providing duplicate functionality removing them from the tab order is ok, and consider adding aria-hidden="true" to these elements so assistive technologies will ignore them.
If you are working in a browser that doesn't support tabindex="-1", you may be able to get away with just giving the things that need to be skipped a really high tab index. For example tabindex="500" basically moves the object's tab order to the end of the page.
I did this for a long data entry form with a button thrown in the middle of it. It's not a button people click very often so I didn't want them to accidentally tab to it and press enter. disabled wouldn't work because it's a button.
The way to do this is by adding tabindex="-1". By adding this to a specific element, it becomes unreachable by the keyboard navigation. There is a great article here that will help you further understand tabindex.
Just add the attribute disabled to the element (or use jQuery to do it for you). Disabled prevents the input from being focused or selected at all.