(a) TIMTOWTDI =. there is more than one way to do it
(b) TIOOWTDI =. there is only one way to do it
i do not know if the case for this issue is (a) or (b), above.
The follow links may apply to this discussion:
https://developer.mozilla.org/en-US/docs/DOM/window.onbeforeunload
MSDN beforeunload | onbeforeunload event
http://dev.w3.org/html5/spec-LC/history.html#unloading-documents
http://dev.w3.org/html5/spec-LC/history.html#beforeunloadevent
... Note: There are no BeforeUnloadEvent-specific initialization methods.
please note: i am not discussing SO article 276660 "How can I override the OnBeforeUnload dialog and replace it with my own? which is about the text that the end-user sees in the dialog box; i found SO article 276660 via the first reply to this discussion: suggestion: change default for are you sure that you want to navigate away from this page? from OK to Cancel
My issue with how various browsers behave is the need to prevent the end user from losing her/his typed data because she/he accidentally clicked away from a page; such a disaster can easily occur if she/he happens to press the space bar shortly after the dialog box has been displayed; "disaster" may seem like a very strong word unless you are the end user who has just lost an hour or two of typing.
i. is JavaScript the only way to prevent this?
ii. is there some way to tell the end users' browsers to make Cancel the default?
Clarification (i hope): in a Windows O/S dialog box, it is possible to tell the Windows O/S which button to highlight as the default; for example, if the message were something like "delete all of my files", a default of "OK" is a bad idea.
SO frequently saves my text as i'm composing a question; other forums do not do the same.
i'm guessing that if my laptop were to crash as i'm writing this message then SO would give me some way to recover close to the point where i am at this moment.
Will someone please tell me whether there are one or more ways with regards to browsers, and, if there are, where to find more information?
imho, setting the default dialog box button to "OK" is far too dangerous because accidentally hitting the space bar could cause a lot of grief.
Thank you.
Related
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.
im trying to build a nice blackhoneyholepotdoom and something that annoys me is the fact bots are able to go back and/or switch tabs. Their behavior is: 1) hit login link, fail, go back. 2) hit register link, fail, go back. 3) Either leave or proceed to try again. I assume this is Xr*m*r behavior? I need to interrupt the "go back" as much as possible to make bot hell on earth.
Besides JS, is there any method ya'll know of to open a link in a new tab/window whilst destroying the previous, or all the others? It could be a popup, iframe trigga top, whatever -- to my knowledge, bots dont care and never get past your header/content anyways.
This has terrible dubious implications if used on humans, hence it doesnt seem to exist -- but figured maybe there was a workaround out there. You can email or spam me at dhaupin at gmail dawt com if you dont wanna share here.
Thank you!
I'm trying to make an existing FLEX application section-508-compliant, by getting it to work smoothly with the JAWS screen reader. It kinda sorta works, but one immediate problem is that when you first go to the login screen, your cursor ends up in the userid field, but JAWS doesn't read anything useful (like the label of the field you're in!) until you hit TAB or something.
Is there a way to force it to speak immediately on application startup, without making the user tab/backtab just to hear where they are?
For that matter, as cool as it is that it reads interactive controls as the user tabs around, sometimes you just need to make JAWS say something at a particular point in the logic, which might or might not be associated with a control, as if you could write AS code like jaws.speak('blah blah blah');. Does anyone know how to accomplish this?
check out the Tips and Tricks slide (page 16) on this page:
http://www.slideshare.net/fugaciousness/accessibility-in-flex
A few in particular you may find usefull...
start the tabIndex at 1 instead of 0.
Force focus into the app with ExternalInterface.call("s = function() {document.getElementByID('"+this.id+"').focus(); }");
Or force the tab to stay within the app... keyFocusChange="event.preventDefault(); focusManager.getNextFocusManagerComponent(event.shiftKey).setFocus()"
Sometimes a user will click on a link on a page, and it seems that there is no reaction -- nothing is loaded. It turns out that all the links on that page is targeting a window name, such as "news_content". The user previously already clicked on a news headline, and so when the user now clicks on another news headline, that window (usually another tab nowadays) will load the news, but the original tab is still the one being shown. To the user, this seems like nothing is happening.
Are those websites using <a href=" ... " target="news_content"> ? Is it a good idea to use something like that, or can it be changed a little bit so that the focus will go to that tab instead of staying at the original tab?
(is it better that the browser always switch to the target tab? if so, then this problem looks like will be solved).
In my opinion the user should always be in control of whether a link opens in a new window or not - If they're anything like me with numerous tabs endless new windows links are a mess.
What you seem to be asking is why the browser stays at the original page when a tab is updated with content, its simple, it sees it as another webpage, say you had a page that had realtime updating, your browser would not switch to that as it sees you are on another page - for all it knows you could be reading an article, watching a video etc.
All it takes to realise a different tab/window has updated is a little bit of awareness. With windows they would generally open over the current content, however as tabs are in one window this is not possible an it remains closed, but updated.
EDIT: In response to the title... I believe it to be better practice than opening something brand new each time however feel it should be the users choice whether to load a single new tab or stay in the same one. Hope this helps.
One caveat to add to the conversation.
I only use target= when I know the content is destined to be in an iframe and I don't want the link click to stay in the small window.
For example the graphs I embed here : http://webnumbr.com/stackoverflow-questions
Link behaviour should generally be left to the user to control. In some situations, a case can be made for target="_blank" (especially now that Firefox, at least, has a "New pages should be opened in: A new tab" option), but setting all links to open in the same new window is just bad.
I, for example, hate waiting for pages to load, so I'll read down a page middle-clicking each link that interests me, which will queue them up in a series of new tabs. Five interesting links become five tabs, each loaded in the background while I'm reading the first article, so no waiting. If you make all five open in the same window/tab, though, then each one disappears when I call up the next and not only do I have to 'pick one, wait for it to load, read it, go back to the original article, repeat', but, if I don't notice that this is what's happening, then I'll also need to go back and make a second pass through the original page to re-find the links to the lost documents (or, more likely, just say "not worth my time" and never read them).
Forcing newly-opened tags to the front has a similar problem: I opened it in a new tab because I want it to load in the background while I continue reading the original document. Don't subvert my intention. I cleared the "When I open a new tab, switch to it immediately" checkbox for a reason.
Yes, these websites are using target. Well. I can't imagine in which set of circumstances using the target attribute may be useful. But perhaps there's one. I haven't come across it.
Look, always switching to another tab solves the problem you describe, but it creates others. The biggest one is that switching to another tab may come as a surprise. Usability is by and large about never surprising the user. By the way, I greatly enjoyed the book "Don't make me think."
In an Access (2002 / 2003) data-bound form, a turn of the mousewheel moves to the next/previous record, even if the cursor is inside a multiline text field or a listbox. This is a major annoyance to users and cannot be turned off easily.
I recently discovered a DLL called MouseHook (http://www.lebans.com/mousewheelonoff.htm) which can effectively block this mousewheel behavior and replace it with more expected behavior.
However, when an external ActiveX control is added to an Access form, this module does nothing. For example, I have a form with a FlexGrid control on it, and it can contain a lot of rows. When a user tries to scroll in there using the mousewheel, Access again simply goes to another record instead, even with MouseHook DLL loaded.
Is there a solution like MouseHook DLL but which also works for external ActiveX controls? Or is the source code of the MouseHook DLL available so it can be modified to deal with controls like FlexGrid?
PS: I wanted to ask the author of MouseHook DLL, but he is currently "on a hiatus" until June 2009.
If you really have to alter the UI and change how the user expects the mouse wheel to work, I would actually recommend just disabling it rather than altering how it scrolls. While it's scrolling may seem odd to you, it is how the program works. What would you do if you had to read PDF's all day, and then one day one person decided that the way the mouse wheel scrolling worked wasn't good enough and changed to so it defaulted to huge jumps or horizontal or whatever. Yes, it may have been a better solution, however it is annoying to the user because it doesn't do what it is supposed to do.
Why are you using a flexgrid in Access? To me, this is a read flag that you likely are approaching the project with an Access-hostile point of view, since you seem to be choosing non-native controls to do things that are almost always much more easily accomplished with Access's native controls.
Hook the flexgrid, intercept the WM_MOUSEWHEEL message, ignore it and call your intended behaviour.
Not a direct answer to your question, but the way we deal with the mouse wheel movement is to prevent accidental changes of records after the user has started editing. When the user opens the form, the wheel moves the records willy-nilly as normal. As soon the user edits something on the field, and then moves the mouse wheel, the BeforeUpdate event fires, which causes our code to put up a prompt saying they must save the record first. We have a save button which the user must explicitly press to supress the warning in the BeforeUpdate event.