I am attempting to make my ember.js app more accessible and am doing my testing via Apple's built-in VoiceOver utility. I'm adding ariaRoles as necessary to my views and tacking on aria-label attributes where the purpose of navigation is unclear. I'm having issues getting the focus on modal alerts, as the reader's focus stays on the page items behind the modal. Does anyone have experience handling focus on modal alerts for screen readers? I'm under the impression that declaring "ariaRole:'alertDialog'" in my view sets the appropriate role for such a dialog, and it is possible that the focus behavior for this role differs between screen readers. Thanks!!!
I don't have first hand experience with modal stuff. Essentially your issue is you are throwing on an ARIA role, and kind of expect it to work. You need to do more than that. You need to keep the following in mind:
Once the link/button is pressed, move focus to the modal window/dialog/popup. Most modal elements are simply a <div>. You can give the<div> an attribute of tabindex="-1".
Trap focus inside the modal window.
Allow the user to press escape to close
When closed, move focus back to link/button
Resources
keyboard accessibility with lightboxes
Similar question at UX StackExchange
Demo modal dialog - I think this is still under dev (I haven't heard from the author for a while).
jQuery Google Group thread
(Hans is the top guy or one of, for this stuff)
Related
I have a <dialog> element which, when opened, requests some content from the server using AJAX. When the content returns (which of course can be any length of time depending on connection speed and amount of content) the new content is then dynamically appended to the dialog.
How can I make screen reader users aware that this content now exists and that they can move to it?
Should focus be moved to the content once it is inserted?
I'm using the a11y-dialog library to open the dialog.
I have the container for the dialog set up with aria-live="polite" and add aria-busy="true" once I start the AJAX request.
aria-busy is then set to false once the AJAX request returns and the content is added to the container.
This works to announce the content as soon as it arrives, however, it reads all text entered, which in some cases can be several paragraphs. My experience with the screen reader controls is limited, so I'm unsure if there is a way to interrupt this automatic reading process.
This is the HTML code for the dialog. The AJAX container has the id #dialog-ajax-wrapper.
<div class="dialog js-dialog" id="dialog" hidden>
<div class="dialog__overlay" tabindex="-1" data-a11y-dialog-hide></div>
<dialog class="dialog__native" aria-labelledby="dialog-title">
<div class="dialog__inner">
<button class="dialog__close" type="button" data-a11y-dialog-hide aria-label="Close dialog window">
X
</button>
<div class="dialog__ajax" id="dialog-ajax-wrapper" aria-live="polite"></div>
<div class="dialog__loader" aria-hidden="true"><div class="loader"></div></div>
</div> <!-- /.dialog__inner -->
</dialog>
</div>
I would expect the fact that content is loading to be announced in someway, which it currently isn't. Then once the content is inserted, it is announced but not read in its entirety.
This is further compounded because focus is transferred to the close button. Since there are no other focusable elements until the content is loaded, tabbing or trying to navigate produces no result which could lead the user to think nothing is available and leave the page.
Is this the right method or is there a better way?
How can I make screen reader users aware that this content now exists and that they can move to it? Should focus be moved to the content once it is inserted?
It's a bad idea to focus static text or to make it focusable.
The user may think that he can interact with the text, what isn't the case. The basic reaction would be "it doesn't work".
Generally, the rules for placing focus in a dialog is as follows:
When the dialog requests information from the user (entering text, answering questions, etc.), the focus should be placed on the first interactive control or on the most probable answer.
It shouldn't be placed on a button unless htere's no other kind of control. Especially not on the close button.
If no interaction is needed, the correct place for the focus is to be on the button the user is the most likely to click on.
Usually OK or Yes, except for uncancellable actions such as delete where it is better to focus No or Cancel by default.
So in your case you are correct, the focus must stay to the OK or close button, and shouldn't be moved away.
This works to announce the content as soon as it arrives, however, it reads all text entered, which in some cases can be several paragraphs. My experience with the screen reader controls is limited, so I'm unsure if there is a way to interrupt this automatic reading process.
Don't worry with the text length. Of course there are ways to stop reading before the end, repeating, reading one paragraph, one sentance or one word at a time.
Jaws or NVDA under windows:
Arrows keys to read
Ctrl to shut up
Under iOS with VoiceOver
Sweep left/right and the rotor to read
Two fingers tap to shut up
etc.
I encourage you to read documentation or follow toturials about several screen readers. The most popular are Jaws and NVDA under windows, VoiceOver under Mac and iOS, Talkback under Android...
I would expect the fact that content is loading to be announced in someway, which it currently isn't.
If loading is fast enough, there's no reason that the loading be announced at all. I hope that it's your case.
Foundamentally once a dialog box appears, I wouldn't like to wait a long time for the content.
If it takes a while to load, It would probably be better if the dialog appears only when everything is loaded.
This would remove your fear about what could happen and what the user may think while the dialog content is loading.
You may show a separate load indicator instead of the empty dialog. IF you do so, don't forget to use aria-live so that loading is announced.
Then once the content is inserted, it is announced but not read in its entirety.
When the content become too long, the normal screen reader user will anyway start using navigation shortcuts such as arrow keys or left/right sweeps, rather then waiting that everything is read in a single pass.
So don't worry, it's enough if your text stays accessible with this kind of navigation.
Modals are always difficult for accessibility and they will be until the element is complete adopted.
I would insert the dynamic content after the call to action item so the user will be aware of the content he needs to fill.
I have a website and while testing I noticed that if I use tab navigation selection goes throughout my inputs and elements and after the last one focus goes to browser address bar and in some cases (browsers) other browser related elements.
Is there a way to avoid focusing browser elements?
I suppose there should be a way to do this, because I am using Visual Studio Team Services and in case of open popup tab navigation, the navigation doesn't go outside the popup.
I also noticed that if I open a popup dialog in my website even the elements outside the popup (the page from which the popup is called and is staying behind) are being focused.
I hope someone could help deal with this
I'm having an issue with a our main application's window activating itself when the mouse is hovered over it.
I'm opening the new window in a javascript function using the line below:
window.open(URL, 'Requests', 'location=no,toolbar=no,status=yes,scrollbars=yes,resizable=yes');
I have noticed that if I open a new IE window through Explorer, hovering over our main application's window does not reactivate itself. Even in this case though, the main window does make itself be "on top" of the pop-up window created by the window.open command above.
The question is this: Is there any way, when opening a "child" window in javascript, to detach the child window from the parent?
Further info: I am using an Infragistics WebDataMenu with ActivateOnHover set to true so users don't need to click on main menu items to see sub-menu choices. Unfortunately, that setting sensitizes the whole menu bar so that sliding the mouse through it activates the menu (and sadly the window when a popup is active). This is the root behavior I'm trying to fix.
The window.open(); method will create a popup window that really only shares a relationship through JavaScript via the return value of the call, and the window.opener property on the popup window.
What you want is the behavior of a modal window that locks out interaction from the 'parent' page while you work on the 'child' popup.
You can try to fight with JavaScript (and your users) by forcing a focus on the popup and blocking any blurring but this will drive users nuts when they want to go read their email etc. (eg not recommended)
You can also use the not so standard showModalDialog(); method but support is far from fully cross browser and there are a whole bunch of new problems if you try to use this (no right click in IE, zoom issues in IE, and no grandchildren popups to name a few) (again not recommended)
What you can do is make an "overlay" popup similar to many online photo viewers where you first overlay a mask (typically semi transparent) that blocks mouse/focus on the entire page content below and then overlay that with your "popup content". Just be sure that you provide a close option that removes the mask when the overlay is closed/done.
Note if you need to support IE6 you'll also need an iframe shim (Google if needed)
Many UI frameworks will provide a "dialog" just like this for you. (Eg jQueryUI)
Ultimately, I gave up on making this work. I found that what I had to do was turn off ActivateOnHover from the WebDataMenu, which didn't answer this question and requires users to click on the menu to make it drop down, but it became a work-around.
I have a document that can not be quit without saving changes. I use onbeforeunload to ask user if he really wants to quit. It works fine if the "quitting" scenario is clicking on a link and reloading page. but i have also JS menu that moves user from document editor to settings and it's done without website redirect but is handled wholly by JS by replacing "document view" and showing "edit settings view". But moving to edit settings view makes the changes in document unsaved like a normal reload does. So how to invoke browser to ask if user really wants to move to edit settings view like it does when page reload occurs in this scenario?
You can't, without navigating away from the page. But you can ask them with a much nicer, more friendly modal dialog of your own (an absolutely positioned div with a zIndex greater than any other, possibly with an iframe shim under it to eat all clicks, etc.). You can roll your own, but there are lots of modal dialog libraries out there which would save you time.
Or if you like, you can use confirm, which doesn't have a very good user experience (but then, neither does onbeforeunload) but is dead easy to code and entirely cross-browser compatible (despite the link being to a Mozilla page).
Is there anyway to create an alert box, but with a more modern style? When an alert box is issued, the user can not use the browser until it is acknowledged (enter key or click OK). I would like to lock the browser in the same fashion, however use a custom made, better looking alert box. Is this possible with javascript?
Thanks
Edit: To clarify, by lock the browser I mean unable to change url, open new tab etc. The user needs to confirm before they can switch to another page
Yes. The kind of dialog you're referring to is a modal dialog. The basic principle of implementation is to simply cover the rest of the elements on the page with another element to render them unclickable.
Simply googling "javascript modal dialog" reveals a wealth of information; I could not hope to provide a comprehensive explanation in this small space.
[edited -Nickolay] Such dialog won't block further JavaScript execution as alert() does though, and it won't prevent the user from accessing the rest of the browser (other tabs and the Location bar). It's a good thing the user can continue to use the browser and it's one of the reasons such page-modal dialogs were created.
Yes, they are called "modal dialogs". JQuery has an excellent dialog widget that can be made modal as part of its JQueryUI library that can host just about any type of content, including forms.
See this one
Dialog
using jQuery
or
jQuery Alert Dialogs (Alert, Confirm, & Prompt Replacements)
Edit
To your edit: I don't think by using javascript you can prevent the user from typing it to the url bar or opening a new tab. And do avoid doing these sort of things that make a user hinder his normal action.
No, I don't think modal dialogs solves his question.(Not that I have a solution for this, but just to express my opinion). When you use modal dialogs, the only controls you can't access are those inside the web page but the controls of the browser can very well be accessed (ie. Menus, address bar);
This is not possible in javascript. You may use facebox-like containers, that simulates modal behavior, but there are not native modal, i.e. javascript code will not stop execution, when "modal window" is appear.