$('#firstButton').focus();
<div id="liveRegion" aria-live="assertive">
This is a very long text
</div>
<button id="firstButton">First Button</button>
I am quite a newbie in accessibility issues. I basically have a button on which I want the focus to be on page load, but I also want a text to be picked up by the screenreaders in the liveRegion.
Right now, the text will be inteerrupted at some point during page load, and focus goes to the button.
Is there a way to have the screenreader not be interrupted?
Live regions can be confusing at first. The purpose of a live region is to announce changes to the page, not to announce page load information. After your page is loaded, if something changes on the page, such as the text within an element, or a new element is added, those changes can be announced if the aria-live attribute is used.
Most pages do not announce anything as they're loaded. A screen reader user will hear that the page is loading, and when it's done (usually there's an audible clue in the screen reader to let you know if the page is still loading or if it's done), the page title is typically announced and then whatever object has initial focus is read.
If you really need something read after the page loads, then it should probably have the initial focus. But be careful because putting focus on a non-interactive element such as a paragraph (<p>) or non-semantic elment (<div>) can be confusing. If you have to resort to that, make sure that element has tabindex="-1" so that the element will not be in normal keyboard focus order.
as such, there is no way to prevent the reading of your text by the button gaining focus.
The order of priority of what to say when heavily depends on screen reader / browser / OS combination, but usually, an element taking the focus has priority against any live region, including assertive.
What you can do is making the live region assertive text appear after the focus is moved to the button.
It has greater chances to be announced without interruption then.
IN any case, a live region present at page load isn't reliably read on all platforms.
To make sure that it will be effectively spoken, make it appear in the DOM after the page has completely finished to load.
Related
I'm developing a web application that needs to be accessible via JAWS. There is a requirement which says that newly opened dialogs need to be focused on in order to be announced by JAWS. I implemented this, and it's working fine without JAWS: the dialog's first element has focus. Testing this web site with JAWS+IE shows that the element is focused, but the braille viewer shows something different (part of the page header) and that's also being read.
From my understanding, this means that the PC's cursor is correct, but the JAWS cursor is misplaced.
Is there any way to influence the JAWS cursor placement using JavaScript?
When testing with JAWS, you need to not just look at the screen but listen to what JAWS is saying. Spend time getting to know JAWS intimately if you need your testing to provide reliable results.
The best way to create an accessible dialog is to:
Ensure the dialog heading has an ID attribute.
If the dialog has a short message, make sure this also has an ID attribute.
Give the container a role of "dialog" and a tabindex of "-1".
Ensure that the container's ARIA-LABELLEDBY attribute contains the ID of the heading.
Ensure the container's ARIA-DESCRIBEDBY attribute contains the ID of the short message if there is one.
When the dialog opens, send focus to the container.
If you follow this pattern to the letter, your dialog will work beautifully with JAWS and other AT.
Simple example:
<div id="dlg_discard" tabindex="-1" role="dialog" aria-labelledby="dialog_heading" aria-describedby="dialog_message">
<h1 id="dialog_heading">Discard changes?</h1>
<p id="dialog_message">Are you sure you want to discard your changes?</p>
<button>Yes</button> <button>No</button>
</div>
... And the jQuery to make the dialog visible ...
$("#dlg_discard").show().focus();
Is there any way to influence he JAWS cursor placement (via Javascript)?
No
I have a pop-up window that I have enabled with tab stops via tabindex=0. When I interact with the page without a screen reader, I can use the tab key to move between the window and form elements that it contains.
When I use my screen reader client (Window Eyes 8.4) to view my website, I cannot consistently tab into the window.
Are there any special cases with code structure that I should be considering that would cause the window to either lose focus or prevent the screen reader from interpreting the markup of the pop-up?
For reference - I'm in a ASP .NET MVC4 web app (page is HTML/CSS/JS) that is generating the pop-up with a Kendo UI [Kendo] Window.
03/17 Update -
The pop-up is intermittently announced by the screen reader as a dialogue box but as soon as the pop-up loads, I can - occasionally - tab into the div and focus is not lost. I am not able to consistently reproduce this and only found this out after pressing the tab key rapidly after pressing the button to show the pop-up.
On the other hand (when not hitting the tab key rapidly), the focus consistently lands at the pop-up without focus outlines (screen reader announces "Foo dialogue box") but on first tab keypress, focus jumps back to the underlying page at the last actionable element before the footer. Pressing tab at this time will then move me into the footer UL element.
It is difficult to answer without a demo, but there are a couple of areas to investigate.
I did a page on the accessibility requirements for a content based pop-up, i.e. one that is not a form. That also includes code on how to manage the focus.
If the pop-up is essentially form based, you might want to try this one on dialogue boxes.
You'll see from those examples that adding tabindex to the container is only part of it, you should manage the focus as well, so that the focus is moved to the pop-up.
The sporadic nature of the issue might be because screen readers generally don't read things that are display:none, and tabbing to something that isn't there may not activate reliably.
If you can post an example I can update this answer.
I want to pop up a window.alert() if the user mouses out of an area when they haven't saved changes yet (for structural reasons, there are several forms and a common problem I've seen in other apps is making changes in multiple areas, submitting one and losing the rest) and automatically close the alert when they mouse back into the area. To do that, I need the id of the window that pops up, but I'm not sure how to get it.
The window does not have an id, and you cannot close it from Javascript. It is not a part of the DOM.
You can only open an alert() box, and then wait till the user closes it. Nothing else.
No alert() please :)
Actually an alert() will block further code execution anyway so even if you COULD close it programatically it would never actually execute that dialog-closing code.
You need something you can access through the DOM (like every other response here says).
Make your Javascript track the mouse location and upon leaving the area you overlay a dark translucent background or do a modal dialog
Techniques on creating modal dialogs
I would also advise adding a pointer-events: none; and position: fixed to the underlying content to prevent further action until the user actually goes back where they should be.
If you want real specifics on how to code this let me know. I'm hoping you'll travel down the rabbit hole and discover the wonders on your own, though. Much more satisfying.
Right Click, inspect element allows me to see corresponding html & css to screen element. Does the browser likewise, permit tracing the javascript function to corresponding clicks? Or do you manually need to trace from onclick event, so on and so forth?
If so, can one likewise, perform editing of the Javascript, in a browser to verify, what changes will it bring about? Much like, what we can do for html & css
On Google Chrome i discover, in Elements on the right side screen, one can browse to Event Listners then click event to see some Javascript. I'm still deciphering it to see if it permits simultaneous browser screen manipulation.
It doesn't seem to be working at the moment.
Suppose I have a link, which would fade out the entire page when link is clicked. The reason I fade out the page is because a next page is about to load, but it is not loaded yet. I can use pointer-events: none which will disable any mouse events until the next page is loaded.
Suppose it was done with the keyboard, I could use the following to prevent double-enter, or to cleanly disable all elements within, for example tab-enter would be disabled this way as well.
parent.onkeydown = fals
parent.onkeyup = fals
parent.onkeypress = fals
function fals() {return false}
This works well for short loads, but if it takes a long time to load, the user may notice the following difficulties.
Cannot tab away from the a tag.
Cannot use several of the keyboard shortcuts which would control the browser.
Able to tab into the disabled area from the address bar.
Is there a modern and slick way to prevent these 3 problems, other than setting an onfocus=blur for all of the child elements? I do not care about IE today.
I think the commonly accepted way of dealing with things like what you're talking about is to use Modal's, which is to say when they click that link, you pop up a box that says 'Processing' or something like that, and you create a fullscreen div with a z-index above everything else so the user can't click / interact with anything else on the screen until you're done doing whatever it is you are doing.
See http://twitter.github.com/bootstrap/javascript.html#modals for an example of what i'm talking about.