JavaScript keypress function and JAWS - javascript

I have a client that is required to be ADA-compliant. We found an issue when using IE9 and the JAWS screen reader. We have a jQuery function set up to scroll to another element on the page when the user Tabs down to a button and hits Enter. Here is the function:
jQuery('#ball_i5nqtjcVVB0CxYBJICklS6w').keypress(function(event) {
if (event.keyCode == 13) {
jQuery("#headofcurve").focus();
scrollTo("form");
liveballTag('Learn More');
}
});
The problem is that when JAWS is running, hitting Enter doesn't do anything. I must hit Shift + Enter in order for it to scroll to the proper section and begin reading.

This is normal behavior. It happens because of the way how JAWS (and most other moder screen readers, btw) handles webpages and other HTML-like content.
When a user opens up a webpage, he/she observes it with a so-called virtual cursor. That means that all keyboard commands change their meanings on webpages. This is done for the sake of quick navigation. For example, if you press h, you move to the next heading; if you press b, you move to the next button, and so on.
In order to type in something, you should be in forms mode. To enter the forms mode, you should press Enter on a form element such as an edit field or a combo box.
This said, you can't expect that Enter would be processed as you're used to do it without JAWS running.
You have two solutions here:
Change the keystroke to scroll to your element from Enter to, say, Ctrl+Enter (I'd suggest choosing another one since Ctrl+Enter is used for sending messages in tons of messengers and other software alike).
Assigning the application ARIA role to a part of your page. If JAWS encounters the application role, it passes all the keyboard commands through to the webpage itself. But be extremely careful with this mode since it's suggested by W3 Consortium not to overuse this role.

Related

Web Development - Screen Reader Blocks Keyboard Events

We hired an accessibility company (Acme) to evaluate our web pages. Our page has a group of buttons that can be clicked only one at a time, and among their requests are:
Prevent the Enter Key to click a button, instead, make Space Key do the click.
Make the Right Arrow key do the same as Tab Key (move to the next button).
Nothing extraordinary there. Just use javascript to intercept the KeyDown event, determine which type is pressed (Enter. Space, Right-Arrow), and do the appropriate action.
I got that working like a charm....Until I turned on the Screen Reader (NVDA) :-(
Then everything fell apart. NVDA blocks and overrides all the KeyDown events for all the keys except the Tab.
Anyone has idea on how to achieve what Acme is asking for with the Screen Reader turned on?
tl;dr:
Don't go against usual conventions, unless you have a very good reason.
Space and enter
Concerning space and enter, both will normally activate the currently focused control, whether a screen reader is running or not. For HTML controls such as buttons and other inputs, the keypress is converted into a click event. This is a general keyboard convention.
Unless you have a very very good reason, you shouldn't go against normal conventions, simply because that's what's expected by the user. If the user presses enter and nothing happens, he/she will more probably conclude that the site isn't working and quickly leave, instead of trying the spacebar or looking around if there isn't a note somewhere explaining this weird behavior.
Additionally, the user may be running another kind of assistive tool that simulates a keypress on enter based upon another event, for example winking eyes or blowing in a tube. Many assistive technologies behave like keyboards, even if they are not actually keyboards.
In this case, preventing Enter from working normally will just prevent those people from using your site.
If you are afraid of users pressing Enter at an unexpected moment, this is your problem, not user's problem.
If the form is incompletely or incorrectly filled, you should notify the user about it. If you want to avoid processing the same action twice, you should disable the button after it has been clicked on it or pressed enter after the first time, and again, show a clue to the user that something is processing in case it takes a while to complete.
Arrow keys
Several screen readers offer two different modes of behavior, depending on whether the content is operable or not.
When some screen readerd encounter non-operable content, it enters "browse mode" (aka. "document mode" or "scan mode") 'takes control' of the keyboard, offering shortcuts for "next heading", "next word", "jump to navigation" and so on. In this mode, your own keyboard and mouse event handlers will never be triggered.
This is the perfectly normal behavior of screen readers in browse mode and you shouldn't attempt to change it. Arrow keys allow to read the page like a document in a text processing program, for example.
Many keys behave differently when a screen reader is running in browse mode, because these keys are needed for navigation.
Conversely, when the screen reader is in forms mode (aka. focus mode or input mode), input events are not intercepted, and work as normal, arrow keys will behave as you specified in your script.
NVDA enters forms mode when an operable element (such as a button or a text input field) is in focus. In this mode, you can handle arrow key events. It is primarily the semantics of the element in focus which decides the mode of the screen reader.
There are particular keyboard operation idioms for complex UI widgets (such as menus or radio button groups), where it is the whole widget that gets focus with TAB, and then arrow keys are used to manipulate focus within that widget). You should aim to follow these idioms if possible.
But beware because if you nest your elements incorrectly - such as a list inside a button - the screen reader wont really know how to handle it, and this can make the page difficult to read and/or use.
For more information on browse vs. input mode of screen readers, you can make a search.

Permanent Full Screen in Browser

I am trying to create a simple quiz web app for students. They should not be able to access anything on the computer except the quiz questions.
So I found some methods like here to make the browser fullscreen. However, that does not prevent them from hitting escape key or F11 to exit the fullscreen mode, or they can hit the windows key to bring up windows menu (Hence accessing other programs in the computer).
Is there any way to stay in the fullscreen mode permanently and exit only with one of the admins' passwords (Just like TOEFL iBT exam). Is that possible through browser or I should write a native full-fledged program for that task?
function checkWH(){
if((window.outerWidth-screen.width) ==0 && (window.outerHeight-screen.height) ==0 )
{
alert('fullscreen');
}
}
$(window).keypress(function(event){
var code = event.keyCode || event.which;
if(code == 122){
setTimeout(function(){checkWH();},1000);
}
});
I think you can use something like this.
You can start certain browsers in "kiosk mode" which is meant to be used for running fullscreen applications on unmanned kiosks.
Based on this tutorial http://lifehacker.com/use-chromes-kiosk-mode-to-limit-someones-access-to-yo-1243433249
Open up Chrome's settings.
Under "Users" click "Add new user."
Give the new profile a name and picture. Make sure "Create a desktop shortcut for this user" is checked. Click "Create."
Right-click the newly-created shortcut and select "Properties."
In the "Target" field, add "--kiosk" (no quotes) to the end.
Click "Apply."
This puts the browser into a fullscreen mode and significantly reduces the ways you can escape from the browser but it isn't perfect; Alt+F4 will close the browser on Windows, for example.
You might be able to write a script to capture keypresses and discard any that press Alt or a function key, but this is fairly fragile and could affect the ability to actually type in answers.
The only other way around this is to not supply a hardware keyboard. Either build your quiz to only use pointing devices like a mouse or touch. If you need a keyboard, consider providing an on-screen keyboard with a limited key set.

How do I simulate a keyboard enter button press in JavaScript/jquery that is not selector specific?

I need a real, keyboard press simulation.Not one that is only selector specific. I need a way to simulate an actual enter button press on the keyboard, in JavaScript. This way the enter press will work the same every where i decide to trigger it , hence making it an actual enter button on a keyboard, simulation. Please help :) (I am using this in imacros and recording wont cut it because it is specific and not universal)
For security reasons, browsers won't allow you to simply simulate the pressing of a key from a browser context. If this were possible, then a user could load a web page and the javascript on the web page could take over the keyboard and do nasty things to the computer.
For a more detailed explanation, as well as some alternatives, see this post.

How to hide Find Bar in browser? (cancel Ctrl+F by javascript after it was already invoked)

When user presses Ctrl+F on keyboard, browser shows a find box where user can type some text and browser finds occurrences of that text on the current webpage. I would like to keep this feature, but once my users clicks somewhere on the webpage, for example on a certain input element, I want chrome to cancel the finding - to stop - to hide the find box.
How to do that in JavaScript?
At least in chrome...
I know there is a possibility to intercept all keyboard events and cancel the Ctrl+F keystroke in general so the find bar never appears, but this is not my goal, as I wrote I want this to be preserved, but auto-hide programatically.
I noticed that the find box disappears if navigating away from the webpage, I tried to 'navigate away' by adding a #hash to the location.href but this didn't seem to work. I actually cannot navigate away, but maybe some similar hack could help?
$(window).keypress(function (e) {
return !(e.which == 102 && e.ctrlKey)
})
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
Using jQuery this code is correctly working in Firefox. But Chrome didn't generate event if you are using Ctrl+F shortcut. And you can't rewrite browser`s behaviors using JS. You can rewrite it if you will write the plugin for browser

Javascript function is hijacking spacebar key

I'm using Firefox and I'd like to know how I can determine which function on a site that uses Javascript interrupts the normal operation of Spacebar key, which is supposed to scroll down a whole page (and in combo with Shift scoll up a page), and super-hijack it to work normally. How do I do that?
I don't want to disable Javascript on the whole site or everywhere, so Noscript is not a solution. I'm looking for disabling a single function.
In Chrome:
Open DevTools, choose Sources tab, on the right side expand Event Listener Breakpoints, here you choose Keyboard, and select keyup or keydown. Then use the website, it'll break on keyup or keydown, so you just have to press spacebar to find out where it's handled.
use Jonathan's answer to find what the issue is, but this will, as you call it, "super-hijack" it (probably):
function cancelUtil(e){
e.stopImmediatePropagation();
}
window.addEventListener('keydown',cancelUtil,true);
window.addEventListener('keypress',cancelUtil,true);
window.addEventListener('keyup',cancelUtil,true);

Categories

Resources