Where would the first focus be on when a modal window opens? Some say the focus order should be sequential, so the first tab stop should be on the close button and some say, it should be on the first logically actionable element.
According to me, it should be on the first actionable item. Let's say if a modal window is opened to Search something, then the focus should be on the search edit box.
What are your thoughts? Which is better and what are the reasons?
The answer is, it depends®.
In fact it's mostly a question of good sense. You should put the focus where the user is the most likely to do his first action in the modal. Therefore:
If you are prompting for input, the most logical is to put the focus on the first required field
If you are asking a yes-no or multiple choice question, the focus should go on the most probable or recommanded answer
Exception to the previous one: if you are asking a question about whether or not to proceed on a unrecoverable action such as "are you sure to delete ?", the focus should be set to the no button eventhough the most probable answer is yes, so that the user has a last chance to cancel something triggered by misstake
If the modal dialog is just showing a message, it's logical to put the focus on the OK or close button, since it's the only possible action
Putting the focus on the close button when something else is expected is kind of weird, especially for screen reader users, who don't necessarily know what the dialog is for immediately.
I always put it on the first heading or label, so blind users can confirm where they are after clicking the link or button which opened the modal. Then focus can move to the close button as the next item in sequence - if opening the modal was a mistake (happens often when you can't see the layout or with ambiguously labelled links) this makes it easy to correct.
Jumping to the first focusable item isn't technically wrong but gives poor usability for screenreader users while only saving one click for sighted keyboard users.
Related
I am trying to implement keyboard accessibility in one of my website for blind people. I have a hamburger menu on my website. While navigating using the "Tab" key on the keyboard, the focus moves to this hamburger menu item. While clicking on "Enter", it will expand and while press the "Tab" key again, it is navigating through the open hamburger menu elements. Once the last item reached, it will focus on the content.
In that case, is it possible to close the hamburger menu once the user focus-out using the keyboard "Tab" keypress?
Example here https://www.impressivewebs.com/demo-files/hamburger-menu/. It is possible to close the side menu after focus out?
Short answer
It's possible, but it isn't a good idea.
You'd better use a classic toggle button.
Longer answer
For a blind person, doing something on focus out essentially means that it happens without notice. It may be hard to understand and is at best a source of confusion.
The elements that are successively reached in tab navigation and their order aren't supposed to change without explicit conscious user action.
It's even more confusing if the way in which the menu appears and disappears aren't symetric (in your case, explicit press enter vs. focus out).
Both should be symetric. This means that, whether:
The same button toggle the menu on and off
The menu appears on leaving the link just before the menu (focus in), and disappears when leaving the last item of the menu (focus out)
There are several important cons in implementing the second:
Tab isn't the only way to navigate on a page for screen reader users. This concretely means that the menu may not be reachable for no apparent reason, and there may not be any way to make it appear.
Keyboard-only users having vision will probably be surprised of unexpected appearance/disappearance of the menu
Technically it isn't as easy as it looks like: you must think about it in the two directions (tab and shift+tab)
The toggle button hasn't these problems. Correctly implemented, it's always reachable, explicitly triggered by the user and has predictable behavior.
Additionally, it's much simpler to implement.
To wrap it up, the classic toggle button is therefore by far the simplest and safest solution, both for you and for users of various kinds.
I'm trying to display some extra contextual help as a result of a button click elsewhere (in this case it cant be the trigger)
I'd like to be able to have users dismiss via clicking the close x, or clicking the trigger, but continue to show if users click in places other than the ACTUAL trigger.
I've tried setting *clrIfOpen="false" or to about just about any other way I can think of blocking it, but it seems like some place the click listener is just telling isopen service that its open... meaning the clrIfOpen is really only good for an initial state.
Any hacks around this?
First I want to make clear that my problem is not a technical question. I want to talk about usability.
In my company we have a function to check if a scale works properly. We have the button you see bellow (1) to start a function named scaleCheck(). During the scale check the weight of the scale is set to 0 and then a specified weight is put on the scale automatically and when the weight matches the number set in a config file the scale is OK. So when you click on the button, it gets the white border (2) and when the check is finished the button turns normal again (3).
This is the automatic process, but not every customer has a scale which can put automatically a weight on it. So in this case the customer has to go to the scale an put a weight on it by his own. In our application the customer can configure, if he wants the process to be manual or automatic and the button will adjust to this. So when the configuration is set on manual we have to interrupt our function an wait for the customer until he is ready. Because we don't know how many time he will need, he has to click on the button again to tell the application that the process can continue. Therefore we changed the button a bit when we are in manual mode. As you can see below the button (1) changes the image, when the customer clicks the first time on it (2), to show that the weight has to be put on the scale. When he clicks the second time the process proceeds (3).
So this is the current state. The automatic mode works how the customers imagine it to be, but in the manual mode many people have problems with it and need a lot of time the recognize that they have to click on the same button again they clicked before.
And here is my question, is there a better way to show the customers that this button should be clicked again. Are there some people who have experiences with a similar kind of functionality? Or is there a better way to do it? I'm open for every idea which comes in.
We ended up with the opinion that it is not a intuitive solution to click twice on the button. We solved it by showing the user a message after the first click on the button, and accepting that message is count as the second click. With usability in mind this i by far a better solution and the customers can handle this situation much better.
In my Flex 4.9.1 application, at a particular point I put up a "sheet of glass" over the entire stage. It's purpose is to trap all mouse clicks until the user presses the escape key, which removes it. That part is easy and works well. It's just a FlexSprite, parented by the systemManager, which paints transparent pixels over the entire screen.
The problem is that, regardless of where the focus is before the glass is put up, or even if stage.focus is set to null, the user can press the tab key and focus text inputs beneath the glass, and enter text into them.
I tried listening for KEY_UP and KEY_DOWN events on the systemManager, with useCapture=true, and the highest possible priority (0x7FFFFF). When I get the events, I call stopPropagation(), stopImmediatePropagation(), and preventDefault() (even though the events are not cancelable) on them. Nothing works. No matter what, hitting the tab key several times will bring a textfield into focus, and typing letters will enter text into the fields.
So it appears that the text fields are not actually controlled by the key events they dispatch, as if the text is entered before the event is actually dispatched. Because presumably, if they were, they would listen at the target phase of the event flow. And as for the tab key, I have no idea why stopping its propagation doesn't prevent the focus switching.
Has anyone accomplished what I'm trying to accomplish before? If so, what worked?
You can use Application.application.enabled = false; to disable all the controls beneath the top-level Application while the "sheet of glass" is up.
See this answer for more details.
I nailed down a weird behavior on JQM.
Since the page is based on JQM Boiler plate, I do not include the full page here. I published the code on jsfiddle.
Here is a summary of the behavior click actions:
Here is the extract of the relevant code:
<div id="oneapart"
data-add-back-btn="true"
data-back-btn-text="List"
data-role="page"
data-title="Home page">
I do not understand why the last click on the List button (a jquery mobile back button) requires 2 click to actually act on the link. In fact, the weird behavior is that a first click highlight the button in blue, but it remains as is without switching to the previous page until a second click happens.
Any help will be appreciated.
Regards.
This issue can be fixed by adding the data-rel="back" to the button in the popup.
The issue posted on Github has been marked as resolved because of that.
The issue happens because data-rel="back" is missing in the link of the large cancel button in #jerone his fiddle. See "Closing dialogs" here: http://jquerymobile.com/test/docs/pages/dialog/index.html
The back button on pageTwo is dynamically created. When you don't use data-rel="back" on the link that brings you back from dialogThree (which is also a page) to pageTwo it adds an item to the history stack. That's why the back button on pageTwo then requires two clicks to actually bring you back to pageOne.
The active state is removed from a (back) button on the pagehide event. On the first click you stay on the same page, so this event doesn't fire and the button keeps the active state.
I added data-rel="back" and then everything works as expected: http://jsfiddle.net/jEesE/6/
Closing as resolved.
The bug you're describing consists of 2 parts;
why does it require two clicks to revert?
why stays the button active (blue)?
The first part of the bug is not a bug; you open a popup, but instead of going back (e.g. data-rel='back' you open a page that is the same as the previous one. So if you press the back button, it reopens the previous page that is actually the same page as you were on right now (if it make sense).
Why the button stays active, I don't know...
EDIT: I cleaned up your code a bit: http://jsfiddle.net/jerone/jEesE/3/