I am working on react based application for mobile screen readers. Use case is that for a dialog with menu items, I have to keep one button to dismiss the dialog, which will be on top of the dialog. I have to set it's tabIndex to 0 to make it accessible, which results in dismiss button being the first focusable item.
Expectation is that after screen reader lands focus on first menu item, the dismiss button should be accessible. How to approach this problem?
I have tried the following:
<Dialog open={this.state.menuOpen} className="hide-default-dialog-container"
content={<div className="actionsheet-view-bg" onClick={() => {
this.setState({menuOpen: !this.state.menuOpen})
}}> {this.getDismissButtonForActionSheet()}
<div className="actionsheet-view-container"> {this.getActionSheetItems()} </div>
</div>}
/>
You have four options here:-
Option 1. Move the close button to the end of the dialog next to any save / update buttons.
The 'x' in the top right of dialog boxes is expected, but there is no reason why you can't add a close button at the bottom of your dialog instead, placed after any save / update buttons.
So in the footer of your dialog have
<button>Save</button> <button>Cancel</button>
You could still maintain the 'x' in the top right but use aria-hidden="true" on it without a tabindex.
Option 2. Change the button to be after the content in the DOM but use absolute positioning to place it visually
You could move the close button after the content (in the DOM) and then use CSS to position it in the top right of the dialog.
This is a bit of a grey area on whether it would constitute a logical tab order but I think it is still accessible enough to be a good pass.
Option 3. Manage the focus programatically.
When the dialog opens you could just programatically focus the first item. Just make sure you trap focus within your dialog so the close button can be reached.
Option 4. Do nothing
This is the best option
There is nothing wrong with the close button being the first focusable item (in fact it may be preferential to allow users who accidentally open the dialog to close it quickly).
Screen reader users are used to exploring dialogs and so it won't impact them if the first focusable item is the close button. It may even be reassuring to know that you have provided an accessible close button (as many developers forget about keyboard users and make buttons inaccessible to close dialogs).
Semantics, Escape and Focus Management.
To further increase the accessibility change your close div into a button as that way you don't have to worry about adding tabindex as it is semantically correct. (I have assumed the close button is a div as you said you added a tabindex="0" - if it is already a button then the tabindex is not needed)
Secondly make sure the dialog can be closed using the Escape key as that is expected behaviour.
Finally ensure focus remains confined to the modal (not just via the tab key, you need to add aria-hidden="true" to all the content outside of the dialog while it is open as screen reader users navigate with more than just the tab key, in fact it is a secondary way of navigating, screen reader users navigate by headings 1-6, links, forms, buttons etc.).
This may require structuring your page to make it easier
For example:-
<header aria-hidden="false"></header>
<main aria-hidden="false"></main>
<footer aria-hidden="false"></footer>
<dialog aria-hidden="true"></dialog>
would turn into the following when the dialog is open (and reverted when the dialog is closed).
<header aria-hidden="true"></header>
<main aria-hidden="true"></main>
<footer aria-hidden="true"></footer>
<dialog aria-hidden="false"></dialog>
Related
I have a navbar that uses HeadlessUI's Popover on mobile for the hamburger menu. By default, this menu closes when you click out/focus on an element that is not in it.
Now I'm trying to add a modal (HeadlessUI Dialog) that I want to open when clicking on a button that is in the popover menu. The modal is used within a ModalButton component definition (<><button><dialog></>). This is done for separation of concerns (everything relating to the modal is within ModalButton).
The issue is: when I'm in the navbar's popover menu and click on the button to open the dialog. The browser focuses on this new dialog, and so the popover loses focus, making it close. Since it closed, the button (and thus the dialog sibling) are no longer rendered, and so the dialog disappears instantly.
For reference, this is a pseudocode of the react tree:
<navbar>
<popover>
<> {/* "ModalButton" containing both the button and the dialog */}
<button /> {/* Button that opens the dialog */}
<dialog /> {/* This uses a portal internally (with HeadlessUI) */}
</>
</popover>
</navbar>
I can think of a few ways to solve this but neither are very good:
Pull the modal higher in the tree, outside of the popover/hamburger menu but still inside the navbar. But that breaks separation of concerns since the navbar now has to worry about the open state of the modal.
Put the modal somewhere at the top of the tree, and use some kind of global state (requires a state management library) to handle the opening of the modal.
Maybe there's a way to prevent the Popover from closing when focusing on the dialog? (but still allow it to close when focusing anything that is not the dialog)
I'd love to hear any ideas on fixing this issue.
You should put the dialog higher up in the tree. Usually these can go at the page level, or even the app level, depending on how global these dialogs are.
You can then use your favourite global state manager or the useContext hook to tell these dialogs to open programmatically from anywhere in your app.
In which case the popover closing automatically shouldn't be an issue anymore.
In the 1001st implementation of carousel I would like to "properly" handle the focus.
A few quick questions related to UI/UX of this component:
the arrows and the page navigation can accept focus if the TAB key is used. Should I keep the focus on the arrow button after a click event? Is it possible to do it wo calling element.focus() method - like pure HTML/CSS solution?
the page navigation area is suppose to handle the arrow keys inputs - the same question for it: Should I keep the focus once a page navigation button is pressed? Is it doable wo element.focus()? What should be ARIA role for this component?
the design requires 4px height navigation buttons - really hard to click on mobile. In order to make them useable, a div is added as a child of a navigation button so the height of click zone is extended to +20px. Is there better way to extend the "hot zone"?
how can I exclude the additional divs so as not to contribute to area of focus rectangle
Regarding focus, you ask if the focus can be kept on the buttons without using focus(). Absolutely. In fact, when you click on a button, the focus will not move unless you specifically move it or if the element you clicked on gets hidden. So if your desire is to leave the focus on the button, then you don't have to do anything.
That's the preferred behavior - leave the focus on the button. If I'm exploring the carousel slides and I'm a keyboard user, I will navigate/tab to the "next" button and press enter. I'll review the slide and if it's not what I want, I'll press enter again (assuming my focus remained on the "next" button) to see the next slide. If you force the focus to move away from the button and to the carousel content, then I have to navigate back to the "next" button before I can view the next slide. It can be annoying to have to keep navigating back to the element I just selected.
I don't understand your third or fourth questions.
Have you looked at the two W3.org references regarding carousels?
https://www.w3.org/TR/wai-aria-practices/#carousel
https://www.w3.org/WAI/tutorials/carousels/
On click of an input field, a projected popup window opens (have used z-index).
Now when i press TAB, i want the focus to automatically move from background screen to the popped up window.
Is it possible to achieve this flow of TAB navigation through built in properties or styling ?
NOTE 1: I tried setting focus to the outer div of the popup programatically.
So that the focus is moved from background to popup.
But it fails in IE11 and IE10 because, the cursor remains in one element and the focus remains in another element when navigation passes through an empty field. I DONOT WANT HELP FROM COMMUNITY MEMBERS TO DEBUG THIS CODE.
NOTE 2: I won't be able to set the tabindex for the popup window elements statically. Because in that case, the TAB moves to those elements even when the popup window is not visible.
If you have a jQuery dialog window such as this, and lets say you have a vertical scrollbar (E.g to much text where container has a specific height).
In IE you can then use arrows up and down alongside page up and down
however in chrome / firefox you can't they just scroll the outside page.
Is there anyway to make the behave the same?
This is more of an usability or accessibility issue with the modal dialog box.The best approach is to trap focus of the modal dialog i.e. tabbing should not move focus out of dialog box. And also put a tabindex=0 on ui-dialog-content so that div must get focus on tabbing and then you can use up and down arrow key to navigate content of modal dialog.
I have a pop-up window that I have enabled with tab stops via tabindex=0. When I interact with the page without a screen reader, I can use the tab key to move between the window and form elements that it contains.
When I use my screen reader client (Window Eyes 8.4) to view my website, I cannot consistently tab into the window.
Are there any special cases with code structure that I should be considering that would cause the window to either lose focus or prevent the screen reader from interpreting the markup of the pop-up?
For reference - I'm in a ASP .NET MVC4 web app (page is HTML/CSS/JS) that is generating the pop-up with a Kendo UI [Kendo] Window.
03/17 Update -
The pop-up is intermittently announced by the screen reader as a dialogue box but as soon as the pop-up loads, I can - occasionally - tab into the div and focus is not lost. I am not able to consistently reproduce this and only found this out after pressing the tab key rapidly after pressing the button to show the pop-up.
On the other hand (when not hitting the tab key rapidly), the focus consistently lands at the pop-up without focus outlines (screen reader announces "Foo dialogue box") but on first tab keypress, focus jumps back to the underlying page at the last actionable element before the footer. Pressing tab at this time will then move me into the footer UL element.
It is difficult to answer without a demo, but there are a couple of areas to investigate.
I did a page on the accessibility requirements for a content based pop-up, i.e. one that is not a form. That also includes code on how to manage the focus.
If the pop-up is essentially form based, you might want to try this one on dialogue boxes.
You'll see from those examples that adding tabindex to the container is only part of it, you should manage the focus as well, so that the focus is moved to the pop-up.
The sporadic nature of the issue might be because screen readers generally don't read things that are display:none, and tabbing to something that isn't there may not activate reliably.
If you can post an example I can update this answer.