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.
Related
On my website I am creating a dialog. When this dialog is visible I want to create a focus trap so the user is tabbing inside this dialog until the dialog is closed. I am able to set the tabindex of all items on my page to -1 so they can't be focussed.
But I have one problem. I have an iframe with a webform inside it. The field and submit button inside this iframe are still focusable after I've run my tabindex script. I know this is how it should work (I shouldn't be able to change iframes content) but how can I make sure these items are not focusable when the dialog is visible?
For now I just hide the form (display:none) when the dialog is visible and this is an okay option. But I have the feeling there is a better way and since I'm learning about accessibility I'm curious about what solutions there are for this problem.
Thanks in advance
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.
A lengthy Terms of Service (TOS) is displayed in a scrolling div so the "Accept Terms" button remains visible beneath it in small viewports.
Does the scrolling div violate accessibility conventions, because:
a. a sighted user may click the "accept terms" button without reading the entire document, while
b. a person using a screen reader must hear the entire TOS before accessing the button?
Does providing a screen-reader "skip" link somehow invalidate the TOS acceptance?
Imagine https://stackoverflow.com/legal/terms-of-service/public in a scrolling div, with an acceptance button visible beneath it.
Is it required to scroll the div to the bottom before the Accept button is activated?
If the accept button is always activated then the answer is simple, make sure that the accept button is a valid tab selectable target and is either a button (same page) or link (another page).
Screen Reader users are used to navigating past Terms of Service (ToS) by looking for the next link or button.
If the accept button is only activated once the div has been scrolled to the bottom - this is where you may need a minor redesign.
The whole purpose of the scroll to bottom is to 'confirm'** that a user has read the ToS.
Instead have a button that shows the ToS in a (second) modal and locate the close button after all of the text within that modal.
Only activate the Accept button once the close button in the ToS (second) modal has been pressed.
This way you can 'prove' that the terms have been read.
** I put confirm in quotes here here because let's face it nobody actually reads them even if you implement this out-dated practice, they simply just have to scroll a box before ignoring the ToS. If you can make the decision go with the first option of just a link or button to Accept.
Idea: If you want you could use some 'visually hidden' (CSS trick) skip link that says "yeah I don't read Terms of Service but I accept them anyway, take me to the accept button" and jump them to the accept button......no idea if that is legally compliant though :-)
In most cases there doesn't seem to be any visual indication which must be difficult for users who rely on the keyboard.
This seems a really simple question but I've scoured the internet and can't find an answer. My first idea was to use Firefox's developer tools to create a visual indication using *some element*:focus {outline: 2px solid red;} but of course you'd need to already know which element was receiving focus for that to work, so I tried the universal selector *:focus {outline:2px solid red;} but that didn't work.
So can anyone answer the seemingly simple question of what element is gaining focus ... and for bonus kudos can anyone provide a code snippet that would allow me to actually see what is happening?
In the case of a modal dialog box, the focus should go back to where it were before the box appeared.
For example, if the dialog box appeared upon clicking a button, the focus should return to that button when the dialog is closed, regardless of how it has been closed (mouse click or enter on a close button or escape key).
The most keyboard accessible apps and websites are those where you always know where the focus is. The blur function must be banned; it should never have existed.
It depends on the implementation where focus goes after closing the dialog.
However, the WAI-ARIA best practices for keyboard interaction state the following for dialog in a note:
When a dialog closes, focus returns to the element that invoked the dialog […]
In other words, the link or button that opened the dialog is focused.
I checked the native implementation of the HTML <dialog> element in Firefox and Chrome.
Chrome 78: After leaving the dialog by means of the escape key, focus is set back on <body>.
Firefox 71: Did not implement any focus logic yet. Focus is not limited to the dialog, neither is it put anywhere else after the dialog closes.
For all other UI libraries there is different ways to implement the dialog, which will result in different elements being focussed after closing:
1 Conditional rendering: The dialog doesn't even exist in the DOM if it's not visible
2 Hiding the dialog via HTML hidden=true or CSS only display: none
In case 1 focus will be set on <body> in Chrome and Firefox.
In case 2 both browsers keep the focus on the element inside the (now hidden) modal.
If accessibility is a concern, the evaluation of different libraries should take that into account.
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.