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.
Related
I am building a plugin using JavaScript,as part of this i have disabled all the keys but still unable to control the bellow keys , is there any way that i can block the fallowing?
New Window (Ctrl+N)
Restore Tab (Ctrl+Shift+T)
Select Next Tab (Ctrl+Tab, Ctrl+PageDown)
Select Previous Tab (Ctrl+Shift+Tab, Ctrl+PageUp)
Exit (Alt+F4, Cmd+Q)
(Alt+Tab)
i am trying with registry, is it possible to disable remote desktop when ever the plugin installed?
You could turn on kiosk mode for the window which makes it full screen and always on top so you can't go to another application.
You could also make the window transparent and position the login in the middle of the screen so it appears as if there is one window in the middle of the screen but you can't click on other areas of the screen.
To handle for Alt+F4 you can use the window.onbeforeunload event or call event.preventDefault() in the close event.
https://electron.atom.io/docs/api/browser-window/#event-close
I have a long angular form on my page, and on form submit if something is invalid, I call .focus() on the invalid input element. I also have a top navigation on the same page, and my content is scrolled under the navigation during page scrolling.
The problem is, that Chrome's behavior is that it scrolls the input element into the (approximately) middle of the page, so it's visible, but Edge & Firefox only scrolls it until the element is present on the page, but the top navigation hides it. Is there a way to make this thing behave like it behaves in Chrome?
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>
I have a jquery mobile popup, which has a collapsible set within it, and the popup has overflow-y = auto.
SCENARIO A
When I open the popup (which builds content in real-time (when the open-popup button is pressed)), then I open one of the collapsibles within, then click anywhere within the popup, the popup content automatically scrolls.
SCENARIO B
If I then close the popup (which includes an .empty() to clear out that dynamically built content), and then repeat scenario A, the problem does not occur.
SCENARIO C
If I open the popup, but do NOT open any of the collapsibles, I can click anywhere without the problem occurring.
I created a fiddle, but it Does Not replicate the problem.
Any ideas?
EDIT
SCENARIO D
If I do not declare the content divs to be data-role='collapsible-set/collapsible', but rather just drop the content into normal divs, then I do not have the strange scroll artifacts.
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.