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.
Related
Question: With Javascript, can you tell the web browser to begin loading a page, but don't begin rendering it yet?
Issue: A client wants his web page to show listings like a book. When you click on the next button, he doesn't want the next page to immediately load. He wants the book to close (a closing animation) and then load the next page.
Current status: All links go to Javascript. I show the closing animation. Then, I replace the window location. The issue is that there is a clear wait for the next page to load. It would be nice if I could load the following page into cache while the closing animation runs. In other words, I want to make that three-second animation useful time by loading all the HTML, CSS, Javascript, and images for the following page and then all that happens when I set the new location is that it renders.
Possible solution: I have the main page that had two full-screen iframes in it. One iframe is the current page. The other is hidden and is used to load the next page. After the animation, I flip which iframs is visible and which isn't. This is good except that the back button doesn't work properly. If you click back, you go to wherever you were before you went to the website. You don't hide the current iframe and show the one you just hid. If you click back twice, flipping iframes doesn't work. I have to keep a log of your history. Further, I have to hack the back button, which I don't like. So, I'd like to use a built-in cache method if I can.
Possible solution: I have the main page that had two full-screen iframes in it. One iframe is the current page. The other is hidden and
is used to load the next page. After the animation, I flip which iframes is visible and which isn't.
Yes, this sounds like a good approach.
This is good except that the back button doesn't work properly. [...]
I have to hack the back button, which I don't like.
Single Page Applications (SPAs) can't use the back button as originally intended because the entire application exists within a single document.
Partly in response to this, we have
history.pushState()
which is a really good extension to the History API, enabling new "artificial" entries (describing new states) to be added to the browser's history, which, in turn, enables the back button to work exactly as the user might expect it to.
Further Reading:
http://html5doctor.com/history-api/
https://developer.mozilla.org/en-US/docs/Web/API/History/pushState
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 decide to make my own "neverending" scroll page which suits exactly my needs rather than making comfortable with some extensive classes that could not have to work exactly the way I would like them to.
Now, when all works like a charm, last thing remains. Preserve the scroll position when the browser's back button is hit. Every time you get to the bottom of the page I change the hash # part of the url. When the back button is hit, it shows waiting icon and then loads dynamic content.
Firefox scroll after that exactly to place the page was scrolled (good).
Opera and Safari seem to load exactly the same state there were before, so dynamic content seems to be already prefetched and displayed (good).
But IE and Chrome want to scroll before dynamic content is load and they don't try again later. IE get stucked at the top of the page and Chrome somewhere in the middle (bottom of the page before dynamic content shows up).
Now, what could I do to solve this issue? I could in theory store the current scroll position to url hash when any click is detected. Then previous page is load and I could simply parse the hash and ScrollTop(). But for some reason, this
$(document).live("click", function() { window.alert("gotcha"); });
doesn't work for me anyway.
The document doesn't have anything to be clicked on. document.documentElement is the root <html> node, so attach events to that, or to the window if appropriate.
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 want to make my page viewed at full screen.
How can I programatically press F11 on page load. Is it possible?
Thank you
No - not possible without JavaScript. And only then, you can open a large new window, but not emulate pressing F11.
Also, changing browser window sizes without the user's consent is very frustrating for them.
It is not possible to open a window full screen on load. It is not possible to resize the page you are loading.
What you can do is to open a max size child window, say on click of a button etc (if you do it onload, popup blockers would block it).
If it is a corporate intranet then perhaps you can add a rule to all your browsers to add your site to the popup blicker whitelist.
You can also use flash (etc) to open a document full screen, but this is not probably what you are looking at.