For accessibility purposes I need to make 'errors' that are displayed be read immediately after the page refreshes.
Currently I have role="alert" and tabindex="-1' on the div that contains the error. This works fine in Google Chrome, but it appears neither IE or Firefox support what I've done.
In Chrome the user is presented with a login page with both a username/password field. The user 'Submits' the form without filling out any information. The page refreshes with the error below and NVDA immediately reads the error. (I understand real time validation would be good, but that will be done at a later time)
<div id="notification_block">
<div class="alert alert-danger" role="alert" aria-labelledby="alertHeading" tabindex="-1">
<h2 id="alertHeading">Error: Login Failed</h2>
<div>Invalid username/password combination. Please verify that your information is correct.</div>
</div>
</div>
Any ideas how I can get this to work in IE and Firefox?
Instead of using role="alert", I would just set the focus to the div on page load. This will cause it to reliably be the first thing that will be read out and it's a pretty common solution to this.
Add the aria attribute aria-live="assertive" to the error throwing div. This way all screen readers will be able to read all dynamically appearing contents.
The only way you can get this to work is to essentially delay the insertion of the content into the alert role until all the announcements for the page have been completed. There is no way to determine programmatically when this happens, so you should:
wait for page load,
set a timeout (say 500 ms)
when timeout fires, insert the content into the alert
This will increase the likelihood that the content is announced
Related
Will content with role="alert" be announced by screen readers on page load?
I have seen contradicting advise from MDN on this.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Alert_Role states:
[T]he alert role is that it is for dynamic content ... if a page loads with multiple visible alerts scattered throughout, none would be read because they are not dynamically triggered.
While another page states it can be used with static content:
Example 1: Adding the role in the HTML code
The snippet below shows how the alert role is added directly into the html source code. The moment the element finishes loading the screen reader should be notified of the alert. If the element was already in the original source code when the page loaded, the screen reader will announce the error immediately after announcing the page title.
Can/should the alert role be used on static content or only for live regions?
I've found that it isn't reliably read out. Some screenreaders do read out the alert, but others don't. We've partially got round this issue by also moving focus to the element with role="alert" on, as that's also often a trigger for reading an element out. It also makes sense that if a page reloads and a message is read out, the user will expect their focus to be on that message.
This codepen is quite useful in showing the impact of using role=alert in different ways: codepen.io/vloux/full/JOwxmO
There is a discussion in the aria Github repo about adding a new property that reads on page load. Whether or not this is done (there is some disagreement), there is definitely a gap on what the behaviour should be and this needs to be defined.
I'm adding a blocking modal (ie one that covers the screen and prevents interaction while an API call is processing) to my company's design library.
As part of that, I modified our modal so that clicking on the grey backdrop will NOT hide the blocking modal, but I want to make sure that doesn't violate accessibility guidelines. I haven't been able to find anything online about this. Does anyone know if this this violates accessibility requirements?
Short Answer
The answer is 'it depends'. Basically if the modal is not dismissable in any way it becomes a 'keyboard trap' and so would violate WCAG.
However if you structure it correctly a modal that blocks the page while an API loads is perfectly valid (and can't be dismissed while the page is loading), but there are a few things you need to do to make sure this is accessible.
1. Make sure that when this modal loads, nothing else on the page is focusable.
The biggest issue I see on most modals is that they allow focus outside of them.
You can't just stop users using the tab key as that is not how most screen reader users navigate the page (they use shortcuts for headings (h1-h6), hyperlinks etc.).
For this reason make sure your modal sits outside of your <main> and the hide your <main> and other major landmarks that contain information with aria-hidden="true" and by adding tabindex="-1" to them so nothing is focusable.
Obviously this depends on your document structure so you would need to test it, but a properly structured HTML document will work with the above method.
2. Make sure that a screen reader user knows that the page is busy and something is loading.
There are a couple of ways to do this. The best is to use an aria-live region
Adding aria-live="polite" and aria-busy="true" to the section you are updating is one way (if you are updating one part of the page).
However in your circumstances I would make a section within the modal aria-live="assertive" and not use the aria-busy (as you will be hiding all the content in step 1 so aria-busy would not be applicable).
I would then update the message every second or two for long loads (i.e. 'loading', 'still loading', 'nearly loaded' etc. Or better yet a loading percentage if your script allows.)
Once the page content has loaded, you do not need to say 'loaded' instead make sure you have a heading for the section or page that has a tabindex="-1" added on it that accurately describes the content that has just been loaded in.
Once the load completes, programatically focus this heading and the user will know that the load is complete.
3. Make sure that if the API call fails you feed something meaningful back to screen readers
When your API call fails (notice I said when, not if!) make sure your JavaScript can handle this in a graceful way.
Provide a meaningful message within your modal aria-live region that explains the problem. Try to avoid stating error codes (or keep them short, nothing worse than hearing a 16 digit string on a screen reader for an error code), but instead keep it simple such as 'resource busy, try again later' or 'no data received, please try again' etc.
Within that region I would also add one or two buttons that allow to retry / go back / navigate to a new page depending on what is appropriate for your needs.
4. For long load times, let the user know what is happening.
I covered this in point 2 but just to emphasise it, make sure you feedback to users that things are still loading if there is a long load time by updating your aria-live region.
Nothing worse that wondering if the page has loaded and the developers forgot to tell you.
5. Give the option to cancel an API call so it doesn't become a keyboard trap.
Obviously the big problem with a whole page modal is it is a 'keyboard trap'.
To ensure this isn't an issue make sure you provide a cancel button.
Make sure it is clear that this will cancel the loading of the page, but don't rely on JavaScript alone.
Instead make this a <a> styled like a button that either points to the current page or the previous page (yet again depending on your needs) and add role="button".
Then intercept this click with JavaScript so that it can function like a button.
The reason for this is that when your JavaScript fails (yet again - when, not if) the user still has a way to get to a meaningful page, thus avoiding a keyboard trap.
This is one of the few times you should use an anchor as a button, as a fallback!
By doing this you ensure that the user always has a way to escape the modal.
You may also consider allowing a user to use the Esc key to close / cancel but that is yet again down to you and your circumstances.
NOT a duplicate of HTML Form Button value is not posted in Safari and Chrome
I have a button that is used to submit a form when it is clicked.
<form method="post" action="<URL>" class="login_form" name="login_form" id"login_form">
... various inputs here ...
<button type="submit" name="signIn" class="cta">
<span class="arrow">Enter</span>
</button>
</form>
The button name is used server-side to determine what action is to be taken (value is not provided because it is not used by the server).
The problem is that sometimes the name is not posted to the server, while sometimes it is. The ratio is about 1miss/6hits.
Many other forms on my website have the same structure, but I found this behaviour only for this one.
It seems to happen only with Chrome.
I tried clicking the button right after the page is loaded and after having waited quite some time after the page is fully loaded. so it seems not to be tied to the rest of the page.
Is this a known bug or could this be caused by something else?
I encountered a similar issue and in my case it was due to a JavaScript that on Form-Submit disabled the Submit-Button (the intention of that is to prevent duplicate POSTs when users double-click).
Disabled form elements are not included in the formdata.
A better way to "disable" it for the intent of preventing double-clicks thus may be setting pointer-events: none or preventing the surplus submits in JS (preventDefault).
It may also explain that it worked "sometimes", as I imagine there is room for a race between gathering the formdata and the button becoming disabled.
In my experience, this kind of error occurs when there is a problem with the coding of the form itself, or some related javascript error. The fact that you have tracked this to a 1 per 6 chance of happening supports this reasoning. What I would suggest is to view your console output, turn on persistent logging, then submit your forms and test. If this is indeed the problem, there will be some sort of error message printed on the console, and you will be able to solve the problem from there.
I'm curious what's the proper way to push the screen read to read <span>read me on load</span> first (it's in the middle of the html page) when the page is loaded?
Even
role="rude"
doesn't help for some reason.
Thank you.
What you are using is not part of ARIA live regions. You want either role=alert or aria-live=assertive (though in an early draft "assertive" was originally "rude").
Now, that being said, live regions are intended for use on an already-loaded page. If you are making a dialog, then your HTML might look like this:
<div role="alert" aria-live="assertive">
Anything in here will be announced as soon as it changes.
</div>
If you want the dialog to be announced at page load, then consider hiding its contents and then using script to display its contents once the page has finished loading.
If you need to make it announce as soon as the page loads and it is not a dialog, consider moving focus to the element at page load using script. By placing focus, the browser will announce whatever it is.
For this to work, however, you cannot just place focus on a <span> as it is not interactive content. You can make it interactive by adding a tabindex attribute. If you do that, then you will need to add a role describing what the element does (you can use role=region if you are stuck) so that the screen reader can announce what it is instead making the user think she has landed on a control or otherwise expect to be able to take an action.
If you are moving focus to the element for users without screen readers, or if the very first thing the page displays at page load is an alert of some sort, then this should be fine.
However, since you have provided no context and no examples, and given all the ways this can be done that are far worse than doing nothing, please ask yourself this:
Is the thing you want to announce…
…an alert or dialog?
…a control that already can receive keyboard focus?
…going to be given focus for all users, not just those with screen readers?
If you end up saying no twice then you should not do this.
If you can provide an example URL that shows what you want to do, then I am happy to help you get it working. Otherwise I fear you may be coding something that ends up creating a trap or barrier for screen reader users.
this is insanely annoying problem:
AS3 full screen application based on ADOBE FLEX 4, text field. User types something in text field, and then starts clicking backspace many many times to remove what he just wrote, and for some reason, instead of removing characters from text field it tells browser to GO BACK and user navigates away. Why?! Please, please help, this is so terrible. My users are losing important unsaved this is data while using my application!
i am using safari browser
PLEASE HELP.
Wow, this is terrible, I am so irritated, it happens every single time
It is possible that the focus is lost from your text field when hitting the backspace multiple times (check if you are firing some events on the text field that may cause this), which causes the main window to take focus and trigger 'Back' on the browser.
The root of the problem is that the browser carries out keyboard shortcuts REGARDLESS of the flash app having the focus or not. From what I heard this problem does not exist on Safari's for Mac, only Safari for Windows.
I would check to see what browser you are in and then create a popup saying you this app does NOT work on Safari browser ON windows.
Scratching head*
Well maybe if HAD to solve this, I would use the ExternalInterface to interact with Safari or javascript to PREVENT the history back button from getting applied. So it won't go back to an old page. That is what I would look into.