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
Related
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 :-)
I have a tab control object on my Access form and have changed the style to none so that the tabs are not visible, however when I click on where the tabs would be it still changes the pages like as if they were there.
Is this normal behaviour and is there any way to prevent the tabs from being able to be clicked?
This is by design. You could take advantage of this setting to display images where the tabs would otherwise be so that it appears to the user that they are clicking on the image to change tabs.
As you've already figured out, you should set the Visible property to False if you want the tab to be both hidden and disabled.
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.
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.
I am creating a small form where the user
Enters some text in an input box
Chooses from a bunch of options
regarding the actions that need to
be taken with the data
Clicks a submit button
Disconnect does something similar in a better way:
you can click on any of the five divisions here. This is wonderful because it makes it easier for users to perform the same task and simplifies choose and click to click.
What technology is used to display such a menu?
A nice way of doing this is - which doesn't need javascript - is to use radio buttons, but make them invisible. The clickable text and icon go inside of the label for each radio button, so you can click the label or icon to select the radio button.
This ensures a few important things:
Only one item can be selected
The selection is passed back with the form
The browser's native form handling still works
Accessibility options still work
You do have to be careful to make the labels obviously clickable, since you lose the visual cue of having the radio buttons visible.
IE6 & 7 also require a hack - they have a weird behaviour that a display:none or visibility:hidden radio button or checkbox cannot be selected by clicking its label.
Here's an example: http://www.spookandpuff.com/examples/clickableToggles.html
(I haven't included the icons - you can easily add these by setting them as the background in CSS for each item (don't use <img> tags).
Edit Oh man - I just read the question properly! Sorry, you want the behaviour to be 'choose' rather than 'choose and submit'... An easy way to do this is to add some javascript to the inputs to have them auto-submit the forms when they're selected. I've updated the example to show this.
Looks like JavaScript: https://github.com/disconnectme/disconnect.me