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.
Related
$('#firstButton').focus();
<div id="liveRegion" aria-live="assertive">
This is a very long text
</div>
<button id="firstButton">First Button</button>
I am quite a newbie in accessibility issues. I basically have a button on which I want the focus to be on page load, but I also want a text to be picked up by the screenreaders in the liveRegion.
Right now, the text will be inteerrupted at some point during page load, and focus goes to the button.
Is there a way to have the screenreader not be interrupted?
Live regions can be confusing at first. The purpose of a live region is to announce changes to the page, not to announce page load information. After your page is loaded, if something changes on the page, such as the text within an element, or a new element is added, those changes can be announced if the aria-live attribute is used.
Most pages do not announce anything as they're loaded. A screen reader user will hear that the page is loading, and when it's done (usually there's an audible clue in the screen reader to let you know if the page is still loading or if it's done), the page title is typically announced and then whatever object has initial focus is read.
If you really need something read after the page loads, then it should probably have the initial focus. But be careful because putting focus on a non-interactive element such as a paragraph (<p>) or non-semantic elment (<div>) can be confusing. If you have to resort to that, make sure that element has tabindex="-1" so that the element will not be in normal keyboard focus order.
as such, there is no way to prevent the reading of your text by the button gaining focus.
The order of priority of what to say when heavily depends on screen reader / browser / OS combination, but usually, an element taking the focus has priority against any live region, including assertive.
What you can do is making the live region assertive text appear after the focus is moved to the button.
It has greater chances to be announced without interruption then.
IN any case, a live region present at page load isn't reliably read on all platforms.
To make sure that it will be effectively spoken, make it appear in the DOM after the page has completely finished to load.
I have a page with multiple tinymce textareas, using the browser's default context menu. The issue I'm having is that sometimes Chrome will show the correct textarea context menu (cut, copy, paste, etc.), but every second time I open the context menu (roughly), it shows the non-textarea content menu (back, forward, reload, etc.)
I've a sample Fiddle here demonstrating the issue: http://fiddle.tinymce.com/Bugaab
If you right click in either text area (in Chrome) a few times, in different locations, the different menus will appear.
I'm fairly sure I'm initializing the controls correctly. The problem doesn't occur with only a single textarea.
Any help appreciated.
Not quite. It's not a tinymce context menu at all. That's Chrome's context menu when it opens inside an input or textarea. It has different menu items depending on the context.
I said earlier that the issue didn't occur when only a single tinymce textarea was on page, but I see now this was incorrect. The issue happens for every tinymce textarea.
I think the problem is to do with the area of the textarea. Tinymce hides the actual native textarea control and draws its own, and it’s probably incorrectly mapping the dimensions somehow, confusing Chrome into thinking the mouse click is outside the control.
From what I’ve seen, the norm with this control is to use its own context menu rather than rely on the browsers, which is probably why I’ve had such difficulty finding mentions of the Chrome problem anywhere.
When clicking on an an input type=text, a keyboard comes up. Unfortunately, that changes the height of the web page, so that all the thinks that were "stickied" to the bottom of the page want to come up above the keyboard.
And, in my case, the element that's anchored to the bottom of the page (e.g. the Apply button below) ends up covering the next input element (e.g. Max textbox), so that when the user presses Next on the virtual keyboard, you can't see it at all because the button is still covering it.
My question is whether there is any way to prevent the keyboard from changing the height of the page?
P.S. On iOS it works like you would expect. Bringing up the keyboard doesn't change the dimensions of the page.
It is default behavior on Android devices. As I know, you can not prevent this.
My Issue
I am currently in the process of writing an application for iOS using Cordova. I have a page with a form on it like so:
When the user taps on a field, the keyboard appears as expected on iOS. However, to prevent my app from moving off the screen, I have enabled the following setting:
// Prevent the keyboard from pushing up the webview
cordova.plugins.Keyboard.disableScroll(true);
Unfortunately, this prevents a few things that are causing me issues:
When a field is focused, the screen does not scroll to that field so sometimes, the field appears behind the keyboard.
Even if I did have a solution to the above, for the elements that are at the bottom of the screen, I will not be able to scroll down far enough to bring them into view above the keyboard.
My Question(s)
Solution 1
Is there any way, in Cordova, to auto scroll to the focused field without moving the whole app off the screen?
If it is possible, then how can I handle fields that are close to the bottom and cannot be scrolled up any further into view?
Obviously, the first point can be achieved using JavaScript/jQuery and some clever logic with the keyboard_height, position() and scrollTop(). But, this then creates the issue with the second point about the input fields behind the keyboard...
Solution 2
If I apply the following code, it will fix the issue highlighted above, but it will create another issue (explained below):
// Enable the auto scroll when the keyboard is shown
cordova.plugins.Keyboard.disableScroll(false);
Is there anyway to fix my header (the 'Edit Profile' bit), to the top of the screen to ensure that part is always visible?
Use https://www.npmjs.com/package/cordova-plugin-keyboard#keyboardshrinkview and its Keyboard.shrinkView method.
I know what focus() and blur() are, they respectively are that an element gets focus and an element loses focus. In my question I would like to talk about those events on the window object.
What I want is the following, alternatives to focus(), blur() that do the following:
If the webpage is in the view of the client, then it should be in focus. Being in the view is defined as:
Normally looking at the webpage.
Having the webpage window in the view, but have focus on some other screen in the OS. For example you have Skype open, but the browser is still visible in the background.
If the webpage cannot be seen by the client, then it should be not in focus. Defined as:
The user being in full screen mode in some other application.
The browser being completely overlapped by another (set of) applications.
The browser being on a different tab and thus not rendering the webpage visible.
What are the alternatives I could use to accomplish this behaviour?