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.
Related
I have a requirement to make a button that has a tooltip which provides some simple statistical information to a user. (a student's grades for example: "Homework: 100%, Exams: 85%") When the user clicks that same button it should bring up a modal with more detailed information. (Like each assignment's grade for example). I need this to be accessible for screen readers. I am using Bootstrap 5 as a framework. I've seen suggestions that are not ADA compliant for accomplishing this task. What is the best way to do this and have it be accessible?
If the tooltip is only available to mouse users, then that would be an accessibility issue. A keyboard user should be able to tab to the button and see the tooltip.
Say what you will about IE but it had a nice built in feature that tooltips (title= attribute) were displayed by the browser when the user navigated to the element with the keyboard. Fortunately, Edge also does this. Chrome and Firefox do not so you'd have to code this yourself.
Secondly, the tooltip text needs to be programmatically associated with your button so that screen readers can announce the tooltip text. You should get this behavior for "free" because of the "Accessible Name and Description Computation".
The "accessible name" of the button should come from the button text (step F in the previous link, "name from content"). Eg <button tooltip="grades">open dialog</button> will have an accessible name of "open dialog".
The "accessible description" of the button should come from the tooltip (step I ["eye"] in the previous link) if the description can't be found in other attributes (such as aria-describedby). Eg <button tooltip="grades">open dialog</button> will have an accessible description of "grades".
When a screen reader user navigates to the button, they will typically hear the accessible name followed by the accessible description (among other info such as the type/role of the element and possibly the state [such as aria-pressed]). So you shouldn't have to do anything to get the tooltip read but you'll want to test it in several browsers (Chrome, Firefox, Safari) with various screen readers (JAWS, NVDA, Voiceover).
Note that the screen reader user can turn off descriptions so that they'd only hear the accessible name and not hear the tooltip, but that's totally up to the user. As long as you coded it correctly, you don't have to worry about that scenario.
There's no real way to make a tooltip on a button that's accessible, since touchscreen users have no way to trigger it without triggering the button. Tooltips are also confusing, since even mouse users who can trigger a tooltip may not realize there is anything there to trigger.
The best approach in your case is likely to include the information from the tooltip in the modal itself as plain text. (You can keep the tooltip or remove it.)
This will improve the experience for other users too. This "simple statistical information" seems like it would be handy, and having it as part of the modal allows it to be copied (for example), unlike a traditional tooltip.
For constructing the modal itself, I would follow Bootstrap's example code.
I know that the good scenario is, when I click on number 3 on my keyboard I'm supposed to jump between my h3 headers.
For some reason this thing didn't happen in my case and my screen reader (NVDA) didn't show me any indication of it.
It's some list of results and on each result the title is h3.
Here is one example for one result:
http://codepen.io/anon/pen/PGkjdQ
According to the following page : Keyboard Shortcuts for NVDA
Numpad 3 and 3 keys have different use.
Numpad 3 : "Say Next Character"
1-6: "Headings level 1-6"
So you must not use the numpad when you want to navigate through the headings.
Questions that would be helpful in debugging this:
Are you in browse mode or focus mode?
Are you pressing the 3 on the keyboard or the number pad?
Are you at the end of the page?
Does NVDA speak to you ("No next heading 3") or make any noise when you press the 3 key?
Do you have an example that shows the HTML output, not your uncompiled Angular?
If in browse mode (source):
While in browse mode, For quicker navigation, NVDA also provides single character keys to jump to certain fields in the document. Note that not all of these commands are supported in every type of document.
The following keys by themselves jump to the next available element, while adding the shift key causes them to jump to the previous element:
h: heading
[…]
1 to 6: headings at levels 1 to 6 respectively
If you are not sure which mode you are in, you can toggle between them by pressing the NVDA key + Space (source).
The NVDA key changes based on whether you are using a laptop or desktop computer, and you can also override it. If on a desktop computer, then it is typically the Insert key on the number pad. If on a laptop then it is typically the Caps Lock key. (source)
Both NVDA and JAWS show the h3 in the headings dialog. I'm able to navigate to it using the 3 key along the top row of number keys (not number pad).
NVDA screenshot:
JAWS screenshot:
I have an HTML file:
<html>
<body>
<div> my name is <span class="hightlight">jon</span> lbrson</div>
<body>
</html>
In IOS with voice over enabled, when I touch sentence the voice over does not read all of the sentence. The voice over reads each section of the sentence (between the div/spans) separately like so:
my name is
jon
lbrson
I tried aria-hidden.
How can I change the voice over to read the whole sentence without removing the span?
That's how VoiceOver on iOS works. If you try VoiceOver on a Mac, it will read the entire sentence, as does JAWS on a PC. So VO on iOS has chosen to navigate by individual elements. However, the VO user has several options:
They can change their navigation via the rotor. If you set your rotor to "lines", then you can swipe up/down and VO will read the entire sentence.
You can "read all" on the page by doing a two finger swipe up.
You can "read all" from your current position by doing a two finger swipe down.
VO users on iOS devices are used to this. It can sometimes be handy to have VO stop at embedded spans, though. If the span is being used to format a piece of text differently, the VO user is given an indication that the text is split up for some reason.
Your second question in the comments, regarding CSS "content", should be asked as a separate question so that you'll get a wider audience to responde.
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)
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.