When we trap the focus inside a modal, should the focus cycle within the modal or should a user be able to reach the outside, like let's say the browser UI?
It's not clear from the official specifications for the web: https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal
At least in an example provided by said specifications, it's actually like so, that you are not able to reach anything but focusable elements in the modal: https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html
This comes with side-effects like breaking the developer tools:
Here's a video for further clarification: https://streamable.com/i4zcsp
Excellent question! My short answer is: It should not allow to tab outside the modal.
Long answer:
Like non-modal dialogs, modal dialogs contain their tab sequence. That is, Tab and Shift + Tab do not move focus outside the dialog. However, unlike most non-modal dialogs, modal dialogs do not provide means for moving keyboard focus outside the dialog window without closing the dialog.
This leads to two things:
Tab and Shift + Tab are trapped. Reaching the last (first) element will move the focus to the other end.
You have „means for moving keyboard focus outside the dialog”. But then, you must close the dialog.
So when you register a key event listener (and handle Esc to close the dialog and restore focus), you should also handle the mentioned Ctrl+L for reaching the URL bar (resp. Awesome Bar) and perhaps Ctrl+K for the search bar.
Find more keyboard shortcuts for
Firefox
Chrome
Chromium
Edge
Opera
Safari
Given the variety, you might want to dismiss the modal on everything that was not handled inside. User tests would give you a hint on what people expect.
Regarding the developer tools: Opening them in another window might do the trick.
You are only responsible for trapping the focus within the content. That is, anything that is HTML. You don't have to worry about the user moving the focus to other interactive elements that are part of the browser itself.
I often have several tabs open in my browser, looking at different websites. If one of those pages happened to have a dialog open that was trapping the keyboard focus, I would not want my focus to be trapped such that I couldn't get my focus on the browser's tab panel and switch to another tab. Nor would I want the focus trapped so that I couldn't get to the browser's main menu (File, Edit, View, etc). Nor would I want the focus trapped so that I couldn't get to the browser's address bar (alt+D or cmd+L).
One minor nuance in your OP. You mentioned the "official spec" for dialogs. There really isn't an "official" spec with regards to a normative language for a dialog. The "WAI-ARIA Authoring Practices" that you refer to is a fantastic resource and should be followed as much as possible, but not following it does not mean you aren't WCAG conformant. Notice in section "1. Introduction", the first thing it says is:
This section is informative.
You can see definitions of informative and normative. In particular:
Content identified as "informative" or "non-normative" is never required for conformance.
Related
Whenever I use Visual Studio Code in the browser (for me that’s always at GitHub.dev) I can’t figure out to put the focus in the address bar using a keyboard shortcut ( typically I want to do this so I can get back to GitHub.com). Usually I use CMD-L to put the focus in the address bar but it seems that gets intercepted by VSCode.
Surely I can’t be the only one frustrated by this? And idea how to put the focus back in the address bar using a keyboard shortcut?
I'm frustrating the same problem. I now use "Open Permalink in Github" from the command pallet but there might be a better way.
I'm usually a Gmail user but on my most recent gig have to use an Exchange account and so decided to give Apple Mail another try (after looking at a bunch of other options) but I digress.
I prefer the classic layout but don't like to group messages by conversation.
I'm looking for a way/script to use the "Show Related Messages" button, which you can add to the toolbar, so that I can bind it to a shortcut so I can quickly catch up on emails using no mouse clicks.
Is this possible or am I hoping for something not doable?
I'm running El Capitan in case that's an issue.
Thanks for your time!
If I'm understanding you correctly, you essentially want a keyboard shortcut to access the menu item Show Related Messages in the Mail application. You mention adding something to the toolbar, but then also say you don't wish to use any mouse clicks, so I'm going to assume that it doesn't really matter whether or not there's a shortcut on the toolbar—that your priority is using the keyboard to turn on/off the Show Related Messages option.
I'm using MacOS High Sierra, so my screenshots may look a little bit different to what you see on your system, but the process for El Capitan is the same or very similar.
Open up System Preferences and selected the Keyboard pane. In the left-hand list, select App Shortcuts:
Then click the + button to the right in order to create a new shortcut:
Choose the Mail application from the dropdown list, and enter the menu item for which you want the shortcut to apply; in this case, Show Related Messages. Note: It must be typed in exactly, including any capital letters that feature, and without any extra spaces that aren't appropriate. For example, "Show related messages" will not work.
Finally, highlight the Keyboard Shortcut box and press the key combo that you'd like to use as your shortcut. You can even use one that's already assigned in Mail to something else; the pre-existing shortcut will automatically get reassigned where possible.
Click the Add button.
From then on, you'll be able to use your shortcut to toggle the Show Related Messages option on/off.
I have this habit of looking into other source codes from different projects for a reference. However, this leads to cumulative issue of forgetting to close the tab. I may have around 100 source tabs opened up (which is related to current and unrelated projects).
Is there a preference or plugin to auto close unused tabs after certain idle period? Like say after 10 minutes of inactivity.
The issue I face is when I'm in a hurry the tabs pile up and consume lots of memory, and not to mention if you have opened up Chrome for reading documentation and StackOverflow digging. Finally slows down my system due to swap usage.
[ Update ]
Found some interesting tips from this link
So how to quickly close unnecessary tabs in Eclipse?
Closing tabs one by one by clicking on the tab with a wheel/MMB. It’s faster than clicking LMB on a small cross icon, because it’s enough to click anywhere on a surface of a tab. I do it when there is few tabs to close (like one or two) and tabs that I want to closearen’t hidden.
Closing current tab using Ctrl+W keystroke. I do when tab to be closed happens to be an active tab. And when I just visited some class to check something and I won’t need to revisit it anymore soon.
Using Ctrl+Shift+W keystroke to close all tabs. I do it when I’m starting completely new tasks or at the moment I’m too lazy for 4 or 5. :-) .
Right-clicking on the tab that should stay open and selecting “Close all others” option. It’s handy in cases where only one editor is significant and others are a result of code exploration.
This is my favourite one: Using ctrl+shift+e keystroke to display “Open editors” dialog, selecting editors that should stay open (with ctrl pressed), “invert selection”, “close all selected” and finally hitting esc to close the dialog. It may seem complex but trust me it isn’t. It took me only a few attempts to learn how to use this trick effectively. I often do it when I forgot to close tabs for a while and I have a lot of tabs open and what’s worse, some of tabs aren’t visible on tabs bar (arrow icon needs to be clicked to see the hidden tabs).
There is a feature General > Editors > Close editors automatically which closes unused editors automatically.
There is no auto-close feature/plug-in in eclipse. Because user opened all the editors manually and he/she has to close these on their wishes but not automatically.
For your problem I suggest you to use Mylyn plug-in so that you can stick to only those editors(context) you frequent used, hiding all other editors, packages, classes etc.
Also there is an eclipse plug-in for pinning editors refer my answer for the post Eclipse - How to pin editor tabs?
I'm trying to get a window to cover the whole screen. Its positioning and dimensions is fine but it gets covered by the Gnome panel. To complicate things I have two monitors and this app needs to support people with multiple screens.
WINDOW_TYPE_HINT_SPLASHSCREEN is a good start. It covers both screens but not the panel. It's still there, just behind the panel.
WINDOW_TYPE_HINT_DOCK looked ideal but I need this window to take focus to listen to a keyboard event. _DOCK seems like it purposely ignores keyboard events (which kind of makes sense). Can I force it to take keyboard focus?
Is there some way I can force a hinted window to cover the panel?
There's window.fullscreen() which you can call on a normal "un-hinted" window. I assume this lets the window manager decide whether the window should cover the panel or not.
If you use the WINDOW_TYPE_HINT_MENU, you can give the focus to the window by calling the gtk_window_present() function.
However, I don't know if you will be able to cover the panel.
Another hint: the panel probably change its _NET_WM_STRUT property so that other windows cannot cover it. Maybe you will have to play with this property (or another) in your window.
I could have sworn I saw it once before in a screencast where someone had the find/replace window docked in their Eclipse environment.
However looking through the list of options in "Window > Show" the closest thing I can find is the Search window.
I find that I use it quite a bit and with larger monitors these days I figure I could afford to have it open in my perspective all the time.
Is this possible?
Thanks.
One poor-man's workaround is to dock a view that you don't need in a part of Eclipse where you want the find/replace view and then place the find/replace dialog on top of that like this:
Clearly this is a huge kludge but it does work.
I am not sure about that, since Fast views are:
icons allowing users to quickly display different views that have been created as fast views
And the search/replace is a Dialog, not a View..
(source: bpsite.net)
(That Dialog box is not like Views, which support editors, also have their own menus. Some views also have their own toolbars.)
The help page mentions:
Fast views are hidden views that can be quickly opened and closed. They work like other views except they do not take up space in your Workbench window.
This might not be an exact answer for the question. But this works like a charm.
Press ctrl + j and keep typing...
Use ctrl + k to go on
Use shift key wherever required.
Use Edit > Incremental Find Next (Ctrl+J) or Edit > Incremental Find Previous (Ctrl+Shift+J) to enter the incremental find mode, and start typing the string to match. Matches are found incrementally as you type. The search string is shown in the status line. Press Ctrl+J or Ctrl+Shift+J to go to the next or previous match. Press Enter or Esc to exit incremental find mode.