Any idea why NVDA reads clickable word when tabbing through text in html example:
<h1 tabindex="1"> testing </h1>
NVDA will read clickable testing
In first place remember that tabindex are not a good practice in a11y, and also headers don't need a tabindex NVDA provides a header navigation with the H key. About the clickable I can say from my experience is a known issue for NVDA, if you check that in other SR (Voice over or Chromebox) should be read properly
Short answer:
the tabindex attribute implies functionality to some screenreaders.
Long answer:
Two primary ways that a screen reader user will navigate your webpage are by skipping through interactive elements or by headings. Interactive elements are things like links, buttons, form fields and any other piece of functionality that the user will initiate on your page. These are navigated by using the 'tab' key.
The other primary way they will navigate your page is by headings. In fact, a survey from webaim lists headings overwhelmingly as the primary method of navigating a page to find information (source). In your example, you have given the heading a tabindex which will give the impression that it has some functionality or interactivity to it. To my understanding, both JAWS and NVDA will read out 'clickable' on elements that have a tabindex, as they could easily (and typically would) have some javascript click handlers that are not evident from the screenreader.
Answer:
It's because of attribute tabindex which makes this element keyboard focusable. One can focus it by pressing TAB key on a keyboard.
Hint #1: Attribute tabindex with value above 0 should be generally avoided!
Don't use tabindex="1", tabindex="2" and so on. Only tabindex="0" or tabindex="-1" can be useful in some cases. Otherwise you can create a complete mess for a user experience.
Read more:
Google: Using a tabindex greater than 0 is considered an anti-pattern.
WebAIM (accessibility): This is almost always a bad idea.
MDN: Avoid using tabindex values greater than 0.
Hint #2: Generally no need to make focusable elements that a user cannot interact with.
As in specific case no sense to make a heading element keyboard focusable if a user cannot interact with it.
If you are concerned about screen reader users have no worries as they read non focusable content just fine. A quote from Accessibility Developer Guide: As opposed to keyboard only users, screen reader users usually do not use the Tab key to read a page! Read the "Screen readers browse and focus modes" to know the difference between navigation using Arrow keys and Tab key.
But... Exception to the rule exists
Exception to the rule exists and it's probably a good idea in cases where developers set tabindex="-1" to headings which they want the focus to be moved programmatically for the purpose of accessibility. Such cases are for example fresh content update with AJAX in single page applications. The focus would be moved to a heading for a user to get aware of the content update and to be able to start from there. Also it can be useful when currently focused content is about to get removed from the DOM (a.g. deleting currently focused table entry) or moving a focus to an error summary heading after a form submit trial etc.
In my case (VoiceOver on MacOS), it seems that H1 is announced as clickable only on Firefox. On Chrome, it's announced correctly.
This leads me to believe it's a Firefox bug.
Related
Is there a way to write semantic HTML for checkboxes where it won't read it as "unlabeled, check box"?
The following html results in "unlabeled, check box, not checked, Yes" to be read by the screen reader.
<p>Is this checkbox selected?</p>
<input type="checkbox">
<label>Yes</label>
Opening NVDA's Elements List on Interactive Accessibility: Training 3.2 which claims this is the accessible example also results in "unlabeled, check box" treeview entries to be generated.
Is there a way to write checkboxes to ensure they aren't marked as "unlabeled"? Or is this a quirk of NVDA itself?
This is actually a Chrome browser defect. I'm not aware of a workaround, but one would not be recommended, as it could alter correct behavior in other browsers and screen readers.
For more information check the NVDA issues list on GitHub:
Unlabeled is prepended before labelled radio elements while in elements list
I see your example is incomplete with IDs, but I understand what issues you are talking about. It will happen no matter how good is the markup with native or ARIA checkbox controls.
Add some id in your label and add aria-labelledby in the input. The value of aria-labelledby should be the id of the lebel. Hence your code block should be something like this:
<p>Is this checkbox selected?</p>
<input type="checkbox" aria-labelledby="someId">
<label id="someId">Yes</label>
How can I prevent the showing of the Next or Done buttons of the Android VKB in a Codename One app?
Currently, for my app, they are a mess: the next button of the VKB doesn't focus the next field, but the previous. After tons of trials, I didn't find a way to make them working correctly (but there are fine on iOS and on the Simulator). I also tried to override the Layout.overridesTabIndices(com.codename1.ui.Container) and Layout.getChildrenInTraversalOrder(com.codename1.ui.Container) methods in the Form, but nothing changed on Android.
I supposed two possible causes: the use of a Form inside a Form or, more probably, the fact that I replace all the TextFields and Pickers in the same Form (and other components). Maybe the fact that the inner Form is deeply changed results in a confusion for the Android mapping of the "next" button.
That's why my request: because I didn't find a way to make the "next" button useful, I'm asking how I can avoid that it's been shown.
Thank you
Nesting forms would probably mess with the focus traversal/tab order.
Normally you should be able to override public TabIterator getTabIterator(Component start) to return a blank iterator. I'd suggest doing the same for both the parent and child form to disable the "next" feature.
I'm making an accessible web application. One of the feature is a button that allows users to scroll to a certain section of the page. I'm using window.scrollTo(x,y) for this functionality.
Now testing my application using the built-in Mac VoicerOver, I found that although I can click on the button and scroll with no problem, after scrolling, VoiceOver doesn't read anything. Instead I have to click on the mouse one, or use the keyboard equivalents to make it read the content that's on the screen after scrolling.
I'm afraid that some users may not realize that they need another click after clicking on the button. I have two possible solutions:
When the screen reader read the button, it also tells the user that if they want to go to the livechat, they need to click again after clicking on the button. I know how to implement this one, but it looks verbose and dumb.
Change my code so that VoiceOver will read the content after scrolling. I don't know how to implement this one.
The content I would like the screen reader to read is wrapped in a tag.
If you are only scrolling the page, then most screen reader users will not care that you scrolled. With limited or no vision, whether the screen scrolls or not does not matter because the screen cannot be seen.
However, if you are scrolling the page in order to put a certain element into view, then that would benefit screen reader users too.
It sounds like you're trying to do the latter:
allow users to scroll to a certain section of the page
In that case, you also need to put the keyboard focus on that element via the focus() javascript call. Moving the focus will cause VoiceOver to read that content. But to move the focus to a natively non-focusable element (such as an <h2> or a <section> or <p>), the receiving element will need tabindex="-1".
<h2 tabindex="-1" id="myh2">some heading</h2>
and then somewhere you'd have this javascript:
var element = document.getElementById("myh2");
element.focus();
Issue: I have an accessibility issue that I am struggling with. I have an angular web application. A page loading spinner/indicator is shown when content is loading. And when the page content has loaded the spinner is hidden. This "div" is never removed from DOM.
Content of the loading div are not read (by NVDAor jaws) when the loading div is shown.
<div class='loading' aria-live='polite' aria-label='Do not refresh the page' tabindex="-1">Do not refresh the page</div>
I wouldn't like to change the structure of the application but work around using 'aria tags' to resolve this, just wondering if I will have to do anything more to make aria-live work?
Updated (27/July/2016)
Further clarification: I am not removing the content from DOM but using css to show/hide content (display: none to display: block and vice versa)
aria-live triggers screen readers when an element with aria-live (or text within an element with aria-live) is added or removed from the DOM. In contrast, when you unhide a hidden element, neither elements nor text are added or removed from the DOM, so the element's aria-live property doesn’t come into play.
To get screen readers to announce “Do not refresh the page”, either of these options should do the trick:
You can create the <div class='loading' aria-live='polite'> element and its text content from scratch and then add that element to the DOM.
Or you can start with an empty <div class='loading' aria-live='polite'> element and then populate its text content.
A few other tidbits:
As long as the text inside the element is what you want to be read aloud, you can omit the element’s aria-label='Do not refresh the page' attribute.
For icing on the cake, it can’t hurt to include a role attribute on the div that has aria-live. If you’re not sure which role to use, go with role="status"—that’s a pretty safe bet.
When or if the page is at a state where you no longer need to display "Do not refresh the page”, be sure to reverse the steps above. (That is, if you went with the first option and you added the whole element to the DOM, remove that entire element from the DOM. Or if you went with the second option and you populated the element’s text content, clear out the element’s text content.)
There are several issues with dynamically added or shown/hidden live-region.
Firstly a quote from MDN - ARIA live regions:
Simply including an aria-live attribute or a specialized live region role (such as role="alert") in the initial markup as it's loaded will have no effect.
Dynamically adding an element with an aria-live attribute or specialized role to the document also won't result in any announcement by assistive technologies (as, at that point, the browser/assistive technologies are not aware of the live region yet, so cannot monitor it for changes).
Always make sure that the live region is present in the document first, and only then dynamically add/change any content.
From my personal experience, even if a live regoin exists in the DOM on page load if you use show/hide then NVDA also has a bug which requires a small delay before a text update in a live region after it was shown initially. Apparently because the region didn't exist when the first text was added, so this isn't an "update". Regarding the timeout, you'd need to set it to something greater than the browser's refresh tick. I use 100ms. Disclaimer: I am strongly against such workarounds to make up for the issues with screen readers or browsers but it might be useful for someone in some cases.
I am trying to build an app using Extjs 4.1. In general: it is a viewport with a tree panel on the west and a center panel that it is actually a tab-holder panel. When a user clicks on a tree node a tab is populating the center view. I had set an attribute in the tree panel that after selecting a node it gets deselected (deselectAll). The reason for this is that the user can open many tabs from different places (e.g. within each tab). But, when I set the above attribute it is producing an error (the “data” is undefined). The data that is undefined is the data related to the tree node. So, the question concerning selection model:
How can I address this problem (a solution may be to select the fist node, but I don’t want it)?
As for the history utility, I need to implement browser back button. Especially I want to disable browser’s refresh button. If user opens let’s say 15 tabs and accidentally click on browser refresh or “F5” he/she will lose everything. I had tried many things but with no luck. I am unable to understand “Ext history util”. So,
Is there any good example out there?
Could anybody guide me on how to do it?
Notice that the application is built respecting the new “MVC” architecture.
Stopping the refresh event is pretty easy - providing that your page has the focus. E.g.:
Ext.getDoc().on('keypress', function(event) {
if (event.getCharCode() == event.F5) {
event.stopEvent();
console.log('you stopped the refresh event');
}
});
If your page doesn't have the focus then there is nothing that can be done -- but most of the time your page loses the focus when a different browser tab is opened so F5 would be refreshing that one instead anyway.
I'm still trying to wrap my wits around the first part of your question, but I thought I would share that.
EDIT
Instead of trying to stop the default browser behavior (something which you can only do on a very limited basis), you should look into state management. ExtJS supports it on many components. Here is the ExtJS example.
Also here is the example of controlling browser history.