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.
Related
I have an HTML page that has a lot of content. When I open it with a screen reader (specifically, JAWS) without doing anything but entering the URL, the screen reader starts to read all of the content on the site. The reader stops if I interrupt it, or if it reaches the end of the page. How can I prevent it from doing so, and make sure that it will read content only after interaction with the user (e.g. pressing arrow keys or Tab, clicking the mouse, ...) rather than automatically?
(I do not want to use aria-hidden, because I want the elements to be visible for the reader.)
Details:
Browser: IE8, IE9 and Firefox v34
JAWS: V15.0
The page has one div that has the aria-live attribute, but it is only for one title, not for the whole page.
This is not an HTML page issue. That's what JAWS almost always does with HTML pages. For example, when I went to stackoverflow.com just now, JAWS said:
page has 100 headings and 768 links //began reading the page
Don't worry about it. It's not related to your page. Besides, it only takes a control key to stop it.
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)
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).
I have a web page jammed full with a few hundred rows of tabular numerical data. It's fearsome. The user wants to see as many data rows as he can in one single view, without scrolling vertically. I'm thinking to serve that page with just a title bar -- no back or refresh button, no address bar, no Google toolbar, no status pane, nothing but a title bar. The user reaches the page by way of a normal html link.
Is there a way to do that in the CGI that writes the page? The CGI is already writing content and cache-control headers.
If not, then (next best thing) is there a way to do it with JavaScript, without opening a new browser window, perhaps in the onload event handler?
Thanks!
Is there a way to do that in the CGI that writes the page?
No.
If not, then (next best thing) is there a way to do it with JavaScript, without opening a new browser window, perhaps in the onload event handler?
Well, you could, on onload open a new ("chromeless") browser window with your page, but that's about it.
You can't control the user's current browser window from within an HTML page.
Pretty sure you can't do this cross browser and I'm positive you can't do it server side. However most browsers allow a full screen view which the user can get to.
In Internet Explorer and firefox the shortcut is F11. I know that's not the solution your looking for. However I'm pretty sure thats all there is.
I didn't see n0nick answer when I typed mine up. I agree with his answer I'm leaving mine in here for the F11 part.
I have an iframe that references an external URL that serves up pages that contain Flash adverts.
I need to track how often a customer clicks on one of those adverts.
The approach I am taking is to render a div element over the iframe. This allows me to intercept the click event, however I need to pass that click down to the iframe. Is this possible using JavaScript?
No, it's not possible. You can't simulate a real click in javascript, you can only fire click events.
I do not think that it is possible as well
But, assuming that the clicks redirect the user to the site of the advert, you could intercept the user click using redirections. Change the link to some script on your own server with some unique advert id. Register the click and redirect the user to the advertisement page.
Another possibility is to use this technique to load the contents of the iframe, so you known the amount of customers viewed the advertisement. But this of course might be an advertisement scheme your advertisement customer does not like/want.
You can't pass the click through by any legitimate means, and you'll run up against cross-domain problems if you tried to fake it in anyway. And I would definitely stay away from anything that looks like a clickjacking solution - it's bound to stop working (and feels evil too).
You may be able to hack something, depending on how accurate it has to be. This would involve tracking the sequence of events happening when user has put their mouse into the banner area and then left the page (inferring that they clicked on the ad). You'll miss some, and you may catch some false positives too.
It would work something like:
Leave the covering div in place
onMouseOver, hide the div and set an
onbeforeunload event handler that
registers a "click" through an AJAX post (or similar)
when the mouse moves out of the banner area it means they didn't click the ad, so show the div again and remove the event handler
I'd guesstimate you'd get about 80-90% accuracy, but you're going to have to test on a lot of browsers. It's also assuming the ad loads into the same window and not a new one. If it loads into a new one then I think it's going to be even harder.