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 often have a lot of tabs open in Chrome browser(s) when developing. I always use the Chrome DevTools un-docked, in a separate window.
Lets say I have opened DevTools for a given tab, then did some search on SO in another tab...
Then if I focus the Chrome DevTools window again, how can I easily find the corresponding browser tab that belongs to this debug window?
I do have a solution, but it is not that straight forward:
in DevTools, go to tab 'Elements'
right-click any element inside the tag
select 'focus' (at the bottom of the list)
This will bring the corresponding browser to the front and will focus the corresponding tab and will focus the selected element.
This is OK but too many steps and forces to leave the current panel in DevTools (need to go to the Elements tab)
I would like a simple shortcut that just focuses the corresponding tab in the browser.
This question already has an answer here:
Why are buttons discouraged from navigation?
(1 answer)
Closed last year.
The community reviewed whether to reopen this question last year and left it closed:
Original close reason(s) were not resolved
From my understanding, buttons are used to carry out functions and links are used to navigate the user to a different page. But what is best practice in terms of opening and closing a modal?
<a id="testModal" href="#">Open Modal</a>
or
<button id="testModal">Open Modal</button>
<button>
Change the <a href="#"> to a <button> and put your event handler on it.
Some more context on which elements belongs where....
Does the Control Take Me to Another Page? Use an Anchor
If, when clicked, tapped, or activated by keyboard or voice (or insert novel interaction method here), the user is whisked to another URL (including an anchor on the same page), then use <a href="[URL]">. Make sure you use the href attribute and that it has a real URL, not a “#” (otherwise you’re probably relying on JavaScript, which is not at all necessary for a hyperlink). If an href points to just a “#”, then you’re probably doing it wrong. If it points to a named anchor as part of your progressive enhancement efforts, then that’s totally valid.
Does the Control Change Something on the Current Page? Use a Button
If, when activated, the user is not moved from the page (or to an anchor within the page), but instead is presented with a new view (message boxes, changes in layout, etc.), then use a <button>. While you could use an<input type="button">, it’s more likely you’ll get into conflicts with pre-existing styles and subsequent developers (like me).
Does the Control Submit Form Fields? Use a Submit
If, when activated, information the user has entered (either by manually typing or by choosing items on the screen) is being sent back to the server, then use an <input type="submit">. This has better live within a <form>. If you need more styling control or have to embed more than just a simple text string, use a <button type="submit"> instead.
Keyboard Considerations
Think of keyboard users for a moment. A hyperlink can be fired by pressing the enter key. But a true button can be fired by pressing the enter key or the space bar. When a hyperlink has focus and the user presses the space bar, the page will scroll one screenful. If there isn’t more to scroll then the user just experiences nothing. Given a set of interface elements that look the same, if some work with a space bar and some don’t, you can’t expect users to have much confidence in how the page behaves.
I think it’s also worth mentioning that events triggered by a space bar only fire when the key is released, whereas using the Enter key will fire the event as soon as you press the key down (prior to releasing it).
I think there are two possible cases.
Your content is only visually hidden in page or visible in page (can be read by screen readers) and can be hash linked, then an anchor tag might be appropriate (this case is not so common, eg: use case is if you are highlighting a paragraph or image on the page as a modal).
In almost all other cases, your modal is loaded on the same page and is in no way navigated using a url link (except through ajax for accessing data possibly, which doesn't count). Hence it is a custom functionality and a button is the appropriate choice.
Sort of by definition, a dialog is something that will pop up over the current window. You're not really leaving the window, it's just temporarily unavailable. Once you're done with the dialog, you typically go back to the window. So in that respect, you don't want to use a link because you're not going to another page. You're doing some action on the current page. Use a button.
When using a screen reader, I will often bring up the list of links (Ins+F7 in JAWS) to see what pages I can link to. I'll also bring up a list of buttons (Ctrl+Ins+B) to see what actions are available on the page. I would expect the action to bring up a modal dialog to be in my button list.
What keystrokes should one use to navigate tabs on a web page using JAWS Screen Reader? I'm talking about tabs within a web page, not separate web pages opened in different tabs. Such tabs usually appear in the middle of web pages.
What I want to know is how to navigate from one tab to its associated content area. Also, once I'm done reading the tab's content, I want to go back to tab titles, switch to another tab, and then read that second tab content.
I help to build websites that are accessible to screen reader users. An answer to this question would allow us to test what we develop.
Within tabs user will expect to use left/right arrow to navigate between tabs.
1. User press tab key to focus to the tab strip; the first tab item gets focus.
2. Then will use left/right arrow to jump between tabs.
3. Pressing tab key again, will move the focus out of the tab strip to the next focusable element.
Complete aria guidelines for tabpanel is here: https://www.w3.org/TR/wai-aria-practices-1.1/#tabpanel
Once a tab control has focus, use the apostrophe key to navigate through tabs.
I'm on Chrome Version 41.0.2272.101 m (newest), and this update is messed up. They put it, when you have inspector open, that any DOM change will flash with purple on the changed element (like in Firefox), but now I cannot inspect any hovered object (also like in FF, which is why I don't like to use it when doing front end developing).
I'm talking about js triggered events, like superfish for instance. Before, I could hover the menu, and cover the menu with the inspector, and the menu would stay opened, and I could go in the inspector see what pseudoelements are created, change the paddings and such directly, and see the change. Now, when I hover the menu, and right click to inspect it, the menu closes, and I cannot inspect it!
I tried dragging the inspector over, but nothing helped. This new 'feature' is annoying as hell. Is there a way to inspect js triggered events, without putting break points on elements (which works, but is kinda pain in the ass)?
Hover over the element with your mouse and press F8 (this will only work in Chrome) to pause the script execution. The hover state will remain in visible to you. If you're on a Mac, you may have to open system preferences and check off "Use all F1,F2,etc" check box (Or simply use fn + F8).
Sometimes it only works if you are in the Sources tab of the inspector.
*Yes, you should be in the source tab and MOST IMPORTANT is you should close all the opened tabs in the Sources tab before you press F8(win) or Fn+F8(mac). *
Depending on the menu element type, I ran into this issue with drop-down input menus. The reason it's disappearing when I inspect it, is because a blur or focusout event is always triggered on the element when I click anywhere outside the element.
One way I was able to inspect the element is to prevent these events from being triggered is by removing their event listeners:
Inspect the input element on Chrome
Go to the Event Listeners tab and remove the blur or focusout event
Once the event listeners are removed, you can open the menu and inspect it without disappearing
In Chrome, press F12 to open the developer console, then click on Settings (cogwheel icon) or press F1:
then find & check the "Emulate a focused page" option.
Update: as noted in comments, this option is now in another place. See this answer.
On Mac, you can press cmd+\ to pause the script after having opened the dropdown. You can then use shift+cmd+c to inspect elements.
Adding to "In Chrome, press F12 to open the developer console, then click on Settings (cogwheel icon) or press F1:" above;
In Chrome 86 and above you can find "Emulate a focused page" option here:
DevTools >> Elements >> "Kebab" menu (3 vertical dots by the settings cog) >> More tools >> Rendering.
Alternately: With Devtools open: Hit CTRL/CMD+SHIFT+P to open the command menu HUD, enter "emulate a fo" to narrow the search results and enter (or click) to toggle the setting.
Now, when I hover the menu, and right click to inspect it, the menu
closes, and I cannot inspect it!
I faced the same issue and what I used was Expand recursively option on chrome dev tools:
The steps are:
Inspect the dropdown field
Find the dynamic DOM (the purple highlight)
Right-mouse click on that dynamic DOM
Choose Expand recursively:
We can see all elements are there
Here is a demo:
In Firefox
In Inspector, right click on a node that contains the dropdown, select:
Break on... > Subtree modification
This will pause execution the moment dropdown is... well... dropped down.
Only way that would work for me was doing setTimeout(() => { debugger }, 3000) in the console and opening the dropdown while timeout was running.
Pressing pause button in dev tools UI or F8 key to pause script execution would both close the menu.
I just used emulate a focused page and it worked like a charm
go to settings
go to more tools
find Rendering
find "emulate a focused page" and click the radio button
voala now you can inspect your select element
You can set an interval that writes out the content of a given element in the JS console every second. Drop this in the console and open the dropdown.
setInterval(() =>
console.log(document.querySelector('.Select-menu-outer').outerHTML),
1000)
None of the above referred remedies worked for me.
As our drop down (React based) will close on any single click (right or left)
So we found out the below workaround:
In Chrome Open developer tools
first click on the drop-down in collapsed state & let it expand with options
then under the element section, right-click on the div node (make sure not to left click before right clicking), which contains details of the drop-down items
Then select option 'Expand Recursively'
Then required details were shown
I think you can use the CSS Editor in Chrome to apply a state, for instance, the state of 'hover'.
In the Developer Tools, you select an element. On the right hand you have a square with an arrow over it. Click that and you can choose a state. For instance, pick hovered and you'll see both your window and your CSS update as if the element is being hovered right now.
On Windows, press F12 first, at the page with the menu, then point your mouse to the element menu (the menu will drop down), then press CTRL + Shift + C. Now you can inspect all the elements.
in my case i do following steps
Open developer tool or inspect page
click three dot button at top right
click on More tools -> Rendering
then check on Emulate a focused page option.