I keep >80 tabs open as I multi-task through various goals. A time comes when I need to bulk close multiple tabs. This is where the problem of tab-tooltip clicks in.
I don't want to open each tab (and wait for it to load from memory). Instead I just hover over the tab's title for the tooltip to show the name of the tab and then close it if it's not needed.
It takes almost 1 second for the tooltip to appear. Is there any way I can set this delay to 0 for Chrome?
Related
I have a modal that consists of tab layout to enter some form data. The form is a list of radiogroups that can be quite long.
For a user to get back to the tab, currently they have to shift+tab all the way back through the radio buttons to get back to the tab.
I know escape should close the modal. What is the expected keyboard navigation to return to a tab from a tab panel, so the user doesn’t have to shift tab through all of the radio buttons?
There is no predefined standard keyboard shortcut to go back to a tab control from inside its content.
IN a native app, you can go to next/previous tab with Ctrl+Tab/Ctrl+Shift+Tab or Ctrl+PageDown/Up, or sometimes Ctrl+number.
However, on the web, these shortcuts are of course already taken to control the tabs of the browser itself. You won't be able to intercept them for your own use, and even if you could, it would be a terribly bad idea because you would prevent the user from changing browser tab.
If your modal dialog is so big and so long, maybe you can think about modifying the behavior of the escape key.
On first press, you go back on the tab control, and if you area already on the tab control then it closes the dialog.
The user whould have then to press escape twice to close the dialog completely. This is a change from standard escape behavior, but it's maybe more acceptable than defining a completely new keyboard shortcut that no one will use because it's unknown or they didn't get the information at proper moment or didn't remember about it.
More generally, it's maybe the sign that your UI design is too complicated and that you should simplify it or organize it differently.
What about splitting into different dialogs (e.g. one per tab) ? Making groups that you can expand/collapse ? etc.
A big part of accessibility is also about making things simple. If it's too complicated to do it accessibly, maybe you should simplify.
There is no such keyboard shortcut defined for this action in web applications. If you take a look at the "keyboard interaction" section of the W3's Authoring Practices document on "Tabs":
For the tab list:
Tab:
When focus moves into the tab list, places focus on the active tab element.
When the tab list contains the focus, moves focus to the next element in the page tab sequence outside the tablist, which is the tabpanel unless the first element containing meaningful content inside the tabpanel is focusable.
When focus is on a tab element in a horizontal tab list:
Left Arrow: moves focus to the previous tab. If focus is on the first tab, moves focus to the last tab. Optionally, activates the newly focused tab (See note below).
Right Arrow: Moves focus to the next tab. If focus is on the last tab element, moves focus to the first tab. Optionally, activates the newly focused tab (See note below).
When focus is on a tab in a tablist with either horizontal or vertical orientation:
Space or Enter: Activates the tab if it was not activated automatically on focus.
Home (Optional): Moves focus to the first tab. Optionally, activates the newly focused tab (See note below).
End (Optional): Moves focus to the last tab. Optionally, activates the newly focused tab (See note below).
Shift + F10: If the tab has an associated popup menu, opens the menu.
Delete (Optional): If deletion is allowed, deletes (closes) the current tab element and its associated tab panel, sets focus on the tab following the tab that was closed, and optionally activates the newly focused tab. If there is not a tab that followed the tab that was deleted, e.g., the deleted tab was the right-most tab in a left-to-right horizontal tab list, sets focus on and optionally activates the tab that preceded the deleted tab. If the application allows all tabs to be deleted, and the user deletes the last remaining tab in the tab list, the application moves focus to another element that provides a logical work flow. As an alternative to Delete, or in addition to supporting Delete, the delete function is available in a context menu.
Notably absent is any shortcut for the operation you are envisioning. You may look to QuentinC's answer for some alternative solutions from more of a UX perspective.
With Chrome DevTools open I can place a breakpoint in a Javascript file and step through the code displayed in the "Sources" tab as it executes. The problem is that every time I hover over a variable I get an unwanted tooltip that pops up with the value of that variable.
For example if a section of code is let a = 1; then any time my cursor happens to pass over a I get a popup displaying 1. Some variables such as DOM elements can be quite large and frequently get in the way as I am trying to look at the code. I find this annoying and would like to disable this feature. Is there a way to NEVER see these tooltips?
I am trying to analyze what happens when I click a button in my web page. After clicking the button, a spinner element will show up.
The problem is, there is a short delay between the click and the spinner. And the delay varies. I wish to measure the time elapsed between the click and spinner appearance.
So, I'm recording the page using the Performance tab of DevTools.
I can see Mouse Move in the Interactions section, but I cannot find the mouse click.
There are some good questions on using the DevTools here and here but not quite what I need.
How can I capture the moment of the click?
Here is what I got from Chrome Performance when I clicked I'm feeling lucky button. You can see "Mouse Down" event.
But you should know the statistics is less reliable than logging a time between the events you expect to track.
I know you're talking about Chrome, but Firefox has this functionality:
I want to create a popup next to some data that contains a few input fields. Let's pretend that the we have the following document structure
<input name="before-the-data" type="text />
<div id="the-data"><!-- presents some data --></div>
<input name="after-the-data" type="text />
When you tab forward from before-the-data the popover should open and focus should go to the first input in this popover. This popover is appended to the body kinda of like Modal from material-ui so that it lies above the rest of the content. Similarly the popover should open when you tab backwards from after-the-data.
The popover should behave as if it were inside #the-data for navigation purposes but the actual position would be at the end of <body> for presentation purposes.
To achieve this effect, I set tabindex="0" on #the-data and trigger opening the modal and shift focus into it. This works fine so far.
Now for the question: How do I best create the following effect?
You should be able to navigate back out of the modal. My idea was this: When focus shifts from it or the user clicks outside the modal, we close it and restore focus to the element that had focus before it opened up. This can be done with a simple onblur handler and a onclick on a backplane. To support tabbing, the resulting modal looks like this:
<div id="backplane" onclick="closeAndRestoreFocus()"
onfocusout="checkCloseAndRestoreFocus()">
<div id="beforecanary" onfocus="shiftFocusBefore()" tabindex="0"/>
<!-- popover content -->
<div id="aftercanary" onfocus="shiftFocusAfter()" tabindex="0"/>
</div>
You can see that I added two divs that you can tab to beforecanary and aftercanary. When they get focused they shift focus to before-the-data and after-the-data respectively, to simulate as if the popover was actually inside #the-data.
At this point, you hopefully have understood what I am trying to create. Thus, the question: How good is this approach in general with respect to accessibility and how can I make sure I follow best practices of WAI-ARIA?
we close it and restore focus to the element that had focus before it opened up
That might be considered a tab trap, 2.1.2 No Keyboard Trap. Isn't the element that had focus before the popup the #the-data? So if I tab from before-the-data to #the-data, the popup will open. If I press esc to close the popup (you didn't mention that esc would close the popup but it should), the focus goes back to #the-data, which will automatically open the popup again, won't it? (Because onfocus() ran again.)
If I just tab through the entire process, I think it would work. It's just the dismissing of the popup that causes the problem. Tabbing straight through everything would move focus from before-the-data to #the-data to the elements in the popup to after-the-data then to the rest of the page, right?
When tabbing backwards, from after-the-data to #the-data, is the focus moved into the last element in the popup? Since I'm tabbing backwards, it needs to be on the last item so that I can continue tabbing backwards through the popup and then to before-the-data.
The popover should behave as if it were inside #the-data for navigation purposes but the actual position would be at the end of <body> for presentation purposes.
If the popup is in the DOM at the end, that would not allow a natural tab order. You can certainly put it there but then you have to manage the tab order. It would be much simpler if the popup was truly part of #the-data. Then the browser handles the tab order naturally.
You also have to be careful with automatically opening a popup but it might be a violation of 3.2.1 On Focus. See "Example of a Failure: A help dialog". It sort of describes what you are doing but is a little different. In the failure example, focus is moving to an input field, and the popup opens automatically and the focus moves from the input to the popup. Your case is a little different because you move the focus off the input first (or before-the-data) and then the popup displays, which would not violate 3.2.1. I just wanted to point this out in case you change your interaction model.
So in summary, your current behavior is kind of like a skip link. Skip links are often implemented as "hidden" links that only become visible when you tab to them and allow you to jump to a location on the page. The fact that they become visible upon focus is how your popup works (since it too becomes visible when it receives focus). The difference is that skip links do not dismiss if you press esc. They do dismiss if you click outside of them. I think that's the behavior you're trying to mimic. If you ignore my comment earlier that esc should dismiss your popup, then you'll be ok. I only had that comment because it sounded like your popup was like a modal dialog.
I'm using the Network tab in Chrome Dev Tools to profile how my page is loading.
It shows a blue line after the DOM is loaded, then a red line after the page finishes completely loading (all the ads, etc).
However, there are apparently AJAX requests that continue to happen periodically in the background and then network tab keeps timing these -- the result is that the granularity and detail of the initial page load gets lost as the scale keeps being increased.
The DOM usually loads within 1 second and the page is usually done loading in under 8 seconds, and there are dozens of resources to closely examine within these first few seconds, but the network tab tracks events that happen 1 minute and 3 minutes and 8 minutes out, etc. which results in 99% of the horizontal space being dedicated to tracking things I don't care about and 99% of the things I care about being squished into about 1 horizontal pixel.
I would like the network tab to stop timing after it reaches the red line.
There is a button in the upper right corner with the tooltip Record Network Log. If this button is red, then recording will continue. To stop the recording, press this button and toggle it to gray. Just wait until you see the red line indicating that the page is done loading, then hit the button to stop the recording of network events.