I'm testing my HTML on accessibility. While navigating the HTML with the TAB key, the focus ring sometimes disappears because the element that has focus is hidden. At that point i can't tell which DOM element has focus.
Is there a way i can track in Chrome DEVtools which element has focus while TABbing through the page?
Update
Official documentation
As of Chrome 70, which released in August 2018, Live Expressions provide an easier way to track which element has focus.
Open the Console.
Click Create Live Expression .
Type document.activeElement.
Click outside of the Live Expression UI to save.
As of Chrome 71, which was released in October 2018, when you hover over a Live Expression result that evaluates to a node (as is the case with document.activeElement), DevTools highlights the node in the viewport.
Original Answer
Thanks for posting. Seems like a common and useful workflow, yet I've never thought about it.
While focused on the hidden element, evaluate document.activeElement in the Console.
Right-click > Reveal in Elements panel.
The DOM Tree is highlighting the hidden element.
Here is the demo, if you'd like to try it yourself.
P.S. I tweeted out this workflow from the DevTools account.
Related
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.
I am debugging a big DOM with devtools:
I would like to "boomark" this div, so I can jump to it again easily.
It would be great if this bookmark would survive a page reload.
Is there a way to do this?
I'm not sure it qualifies as "Bookmark", but you can use the "Break on" mark, which survives reload and guides you to the right line, even when the elements are folded.
Break on mark
Break on DOM changes from google
With Bookmark no until and unless there is an href to your selector(which is not there in your case).
If you can add then this link can help you How to scroll an HTML page to a given anchor
If you can not use href then though scripting in your dev tools you can do everytime you want to scroll like below
document.querySelector('.panel-heading').scrollIntoView();
The other answers here as I write this will work. Yet another option (sorry the screenshots are so large):
Right click the element in the Elements panel
Select "Store as global variable"
The console will slide open, revealing the automatic name assigned to the element (temp1, temp2, etc)
Whenever you want, you may now type that variable name into the console to have it log the element
Right click the logged element, and click "Reveal in Elements Panel" to have the elements pane open with that element selected
Chrome devtools showing this popup with element xpath near selected element that is highlighted (div#mainbar). How to hide that popup and only highlight element?
In 2020 they've added so much info into that popup - so it has become a real nuisance when inspecting the page.
Partial solution:
Hold down Ctrl or CMD key (depending on you OS) while hovering over elements and the popup will not be displayed.
Credit goes here
As of December 2017, there is no setting for removing that popup. It seems like an uncommon use case, so unfortunately I don't think the team would implement that option.
I have an autocomplete dropdown box for city names as,
When i try to inspect one of the option elements using right click and Inspect Element, the dropdown menu disappears and inspect element takes me to the original page's dom.
How can one inspect dropdown menus using firebug inspect element?
With the suggestions dropdown visible and DevTools opened, press F8 and switch to the DevTools. You will immediately break at the JS blur handler for the field, so the dropdown will not be removed, thus you'll be able to inspect its DOM.
Edit HTML right click menu Chrome Dev Tool
In Chrome Dev Tool you can Right Click on the input where you type the adress, Scroll down to "Break On..." and select subtree modifications.
Go back to your input and start typing. It should Pause the app leaving you with the open suggestions dropdown.
Can't speak for Firefox, but in Chrome developer tools you can trigger a state on an element manually by right-clicking on the element in the developer window, and choosing the appropriate item (i.e. ':hover').
Inspect the dropdown/input element and remove the "Blur" event from the "Event Listeners"
On the Elements tab 'Find' functionality (cmd+F/ctrl+F) doesn't search through styles pane. Is there a way to type CSS property with HTML element selected and find it quickly in the Styles panel?
Bottom right corner, light gray text says "Find in styles". Click there and enter your search.
Unfortunately, such functionality does not exist in current Chrome Dev Tools.
But its present in Opera Dragonfly and its very handy, so, probably Chrome will copy it, eventually (but no such feature request exists in bug tracker now).
On the latest Chrome on Mac, I'm getting the filter at the top of the styles pane. I can't believe that I never noticed it given that I've needed it so many times!
Try using CTRL+Shif+F on the Elements tab