I have seen several behaviors:
No element is focused.
The close icon (usually at top right of overlay) is focused.
Some other element inside of the overlay is focused.
If conforming to ADA / ARIA standards, should any element be in focus?
The current recommend behavior is to focus the first focusable element in the dialog. However, there has been some debate on that implementation recently as it poses problems for users who use screen magnification software and screen readers.
in cases where the focus on display moves to a control at the bottom of the dialog a few negative things happen:
For a screen magnifier user the focus moves to the control, due to the viewport containing only a small portion of the dialog content (typical magnifcation 400-600%) only the bottom part of the content is viewed, unlike the top of the dialog, the bottom content offers no context. users have to navigate around to get an idea of what is going on.
For an SR user (such as JAWS) only the content of the focused element is announced, users have to navigate around the content to get an idea of what is going on.
The debate doesn't appear to be settled, but consensus is growing towards a new recommendation:
If any element in the dialog has the autofocus element, focus that element.
Otherwise focus the dialog itself using tabindex=-1 and outline: none.
Focusing the dialog element itself allows screen readers to read the contents of the dialog to the user, giving them context right away, and a screen magnifier will start at the top left corner of the dialog so they can start reading it from the beginning.
Related
I'm implementing a screenshotting app that captures a portion of the screen. I'm currently:
listening for a keyboard shortcut
drawing a transparent view on top of the entire screen
having the user click and drag to select an area inside of that view
screenshotting the coordinates inside of that bounding area.
Here's an example of what it looks like (the transparent view is tinted blue):
This works, but it causes the mouse to stop focusing on whatever it was previously focusing on. In other words, if I'm hovering over a tooltip and I hit the screenshot shortcut, the tooltip vanishes before I have a chance to screenshot it.
It looks like macOS's own screenshot command does not have this problem. If I hover over a date in StackOverflow in order to see the time tooltip, I can press Cmd+Shift+4 and screenshot it pretty easily:
If I try and do the same thing with my own code, the tooltip vanishes after I render my transparent view, even if I haven't moved my mouse.
Is Apple doing something specific to maintain the focus state of the mouse that I could be doing? Alternatively, should I somehow take advantage of Apple's own screenshotting flow myself inside of this app? If it helps, I'm currently using CGWindowListCreateImage to actually take the screenshot.
I am looking for a solution for display a window over the page like a dialog box but this box will contains a lot of information. It is for my betting game, i display a list of game with a choice between 1 N and 2.
Here is an image of a betting game named netbet :
As you can see i have selected 2.10 in the game Slavia Mozyr/ FC Minsk and a window appears at the bottom of the page for set the amount of money i need to bet. I think it will be better,because mobile screen are very little, displaying a window over the page like a dialog box. Is there a solution for do that in flutter ? Thanks
You might want to use Bottom sheet which does the exact task. It opens a small 'page' (read: widget) over the normal app screen. It'll allow to place the bet etc. It vanishes when use taps anywhere outside.
Sample implementation is here. You can also check solid bottom sheet.
I'm working on a GWT application that has the following layout:
- on top there's Menu Bar
- below that screen is separated into two panel by Split Layout Panel
When user clicks on a label in Menu Bar relevant information is show below in the left part of the screen. Then user clicks on an action item on that left part of the screen, and relevant information on that action item is displayed on the right part of the screen.
Clicking on an action item on the right part of the screen may also change relevant information on left part of the screen.
I want to extend on this by giving a possibility to drag/drop the panel on the right part of the screen to another browser tab/window. After that the right and left part of the screen should remain connected as if they are in the same browser tab/window.
Also, that new tab/window should only display that right panel, while Menu Bar and left panel, along with Split Layout Panel should not be present (this is less important but it would be great if it can be done).
Another important thing is that current visual representation of application is not changed but only extended with this functionality.
Is that something that can be done and if it is how to do it?
Thank you for your help.
I think you would have to use "HTML5" native drag and drop to drag between browser instances, so that would limit browser support. Both tabs would already have to have your code loaded into them so they could respond to these events.
If you have a server back end (not just static HTML/JS) then you could communicate via the server. Otherwise maybe "HTML5" client side storage to store blobs of data describing the panel contents. Probably easier re-render in the new browser/tab.
I am building a site that has a header with a fixed position which contains a select menu. The header is supposed to stay locked to the top of the screen due to the position:fixed in css. However, when clicking the select menu in mobile safari on iphone, the header no longer stays locked to the top when the ios select menu opens. It seems that ios is centering the div with the select menu onto the visible area of the screen above the menu. This doesn't happen when the page is scrolled to the top, but when the address bar is not visible, it "breaks" like so. Haven't found any other answers, maybe I'm asking the question the wrong way. I can't post links to code yet, any help is appreciated.
http://selfconstruc.tv/menu-open.PNG
http://selfconstruc.tv/menu-closed.PNG
For now I don't think there is a perfect solution to deal with the focus jumping.
In my case I hide the header on focus in and show again in focus out and it works well.
I don't know if in your case this could be a workaround.
You can try this:
// detect ios device
if(navigator.userAgent.match(/(iPad|iPhone|iPod)/gi)){
// hide header on focus in and show on focus out
jQuery("#content").focusin(function(){
jQuery('#your-header-id').hide();
})
jQuery("#content").focusout(function(){
jQuery('your-header-id').show();
})
}
The #content is a div where you should have all your controls, the jQuery .focusin() detects the focus event on parent elements, so every control will trigger the focus event. You hide the header on focus and show after that. Hope this helps!
I'm having a sort out of my (Delphi) applications and I been visiting the floating form size and location persistence which seems to be increasingly important with larger screen real-estate and multi-monitors. Clearly it is often desireable to have a user's form reopen in the same place as they closed it, but maybe not always, for example a modal dialog might justify opening bang in front of the users vision, i.e on the primary monitor center screen. There seems to be little out there on the 'net about this and commercial applications seem inconsistent especially regarding multiple monitors. So, a few (probably contravertial!) rules to get us started...
Non-modal forms should always reopen at the size and location of closure.
Modal forms (i.e with OK/cancel, Yes/No buttons) should reopen at the
previous size (if sizeable), but inthe center of the monitor on which the application resides.
An information message box should open in the center of the monitor on which the application resides.
A warning or error dialog should open in the center of the primary monitor.
Thanks in advance,
Brian
"Non-modal forms should always reopen at the size and location of closure."
They must have a default position and size when they first open. Do you have
any rules about this?
I would add the qualifier: If the screen resolution/monitor count is
different from the last time this form was opened, then it reverts to default
position. So no inaccessible forms restored 400 pixels to the right and below
the screen area.
"A warning or error dialog should open in the centre of the primary monitor."
I don't understand why you move the messagebox from 'monitor where the app
resides' (henceforth MWTAR) to the primary monitor. You know the punter is
looking at the MWTAR; after all he has just done something 'bad'. Why are you
changing monitors now you have something important to say?
(After all, if it is an error dialog containing useful diagnostics, he won't
read it anyway. I don't see the need to hide it from him.)
A further thought. One problem with error modal dialogs is that, wherever they pop up, the user may hit 'Enter' accidentally while typing something else and dismiss it. I know I do this quite often.
One trick I have seen to overcome this is to disable the Ok button when the dialog is first displayed. There is a 3 second timer in the dialog which counts down, displaying the time remaining in a small label attached to the button. So the punter knows he will be able to dismiss the thing soon.
Obviously this must be used very, very sparingly, and only on the rarest and most important of dialogs. But it struck me as quite clever. Perhaps all that needs doing is to make Ok the default button after three seconds.
A dialog should never open in the center of the monitor. Consider one of the 30" monitors with 2560 x 1600 pixels resolution - using an application maximized on one of these monitors makes sense only in very specific cases. If an application form resides in one of the corners of that huge screen area then the user would need to move the mouse cursor from its current location to the center of the screen, and back after dismissing the dialog. Also, with a normal viewing distance it's probably impossible to have all of that screen in view at the same time, so center of the active window will be more "in front of the users vision" than the screen center. Any dialog that doesn't remember its position should open centered on its parent window. Exceptions should be made for dialogs that are bigger than their parent window (where it makes sense to leave a bit of the parent visible, which makes it more obvious for the user what's going on), and property pages that should appear near the objects they apply to.
I would also think about saving screen positions in percent of the screen area, not in pixels. This way using a laptop with and without a large external screen will always make optimum use of the screen area - using absolute coordinates will either have portions of the screen unused, or windows moved outside of the visible area.
Depending on the platform, when the application does not have focus when throwing up an alert it should avoid taking focus. Too easy for a user typing to dismiss the alert without any chance to read it.
E.g. on Windows make use of the ability to flash a task bar button.