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.
Related
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.
I want to check whether (alt + tab) is pressed or not if pressed then I want (1) how to close present browser
2) how to disable (alt+tab)
You probably can't detect that it's been pressed,¹ and you can't cancel it — nor should you be able to. The user's workstation is theirs, not yours. Separately, it's mostly pointless (for instance, to prevent cheating during an online exam) in this age of people with multiple internet-connected devices.
Administering remote tests is a hard problem that I suspect hasn't been solved yet. It will not be solved by trying to lock users into the browser.
¹ A quick test using the keydown event, for instance, didn't even fire the event on my workstation. Alt+Tab to switch between applications is handled at a lower level than the browser.
It's possible, there are some examples:
You can create a desktop app using something like electron
Solution: Disable keyboard shortcuts Alt + Tab in electron application
Check out Page Visibility API (probably it's what you want to achieve) https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API
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.
The gist: What's the best way to escape a Flash object's focus on a webpage?
Context:
I have a hotkey listener (an AutoHotKey script) running in my tray. If the script detects the command Alt+Shift+F6 while I am clicked into a Flash object on a webpage, it activates and sends key combinations to Flash to pull certain data logs. After this process completes, I want to call up a JavaScript file on that same browser tab that requests additional information from the user - basically, a tiny UI with additional text fields available in a third-party bug tracker. To do this, I want to send a javascript: command to the address bar using Ctrl+L and having AutoHotKey paste in the full call to the JS file.
A visualization of a possible environment:
The problem:
I need the user to be clicked INTO Flash in order to pull the data logs. However, I need the user to be clicked OUT of Flash for Ctrl+L to actually work - Flash appears to eat all keystrokes at the browser-level when one of its objects has focus.
A possible solution: The easiest way to go about this would be to simulate clicking on the stage, which borders my Flash object on every side. This should work, but I must assume the stupidest possible user. Such a user would somehow limit their current browser window to only be as big as the Flash object (if not smaller), click into it, and attempt to use the hotkey. In this case...I have no idea where I should click, because it could be outside the browser. Further, I don't believe I can assume that all browser address bars are similar amounts of pixels south from the top of the window.
Additional complicating factors:
I want this to work for the user's default browser. (IE, Chrome, Firefox, Safari are my big targets.)
AHK does not provide any native DOM or COM hooks to anything except IE.
Ctrl+Tab and Alt+Tab shenanigans do not appear to work. That can get me to other tabs/windows, but returning to the tab/window with the Flash object still causes Flash to 'eat' further keyboard input.
While I'd be open to using another scripting language than AHK if it could overcome this Flash focus hurdle, I do not know how to create a keylistener that sits in the users tray until activated by a hotkey.
I have no access to the Flash object's code, and it contains no logic to interpret a key combination as a way to break focus or launch a script.
Would it be possible to use WinMaximize to maximize the size of the window? If you do that it should be easier to set up the script to avoid clicking outside the browser.
Perhaps look at ControlFocus and/or ControlSend (using the "edit1" control in IE and FF -- unfortunately, Chrome doesn't expose the "address bar" as a "control" this way but if you test for Chrome first, you can implement your "click outside the Flash box" method for that case).
I was intending to prompt my users to hold Alt+Shift for a particular aspect of my website. Having written the script, I discovered that in Windows where multiple languages are enabled, this toggles between them, which would not be desirable for the user.
Ideally, I would like to prevent this default toggle whilst on this particular web page or perhaps alternatively check first to see if multiple languages are enabled on windows. As far as I can tell it’s not possible to do either?
The following does not prevent the toggle:
e.preventDefault ? e.preventDefault() : event.returnValue = false;
This only detects the languages in the browser, not the OS:
navigator.languages ? navigator.languages[0] : (navigator.language || navigator.userLanguage)
The key combination is intercepted by Windows, it never reaches the browser, so there's nothing you can do from within a website. The browser doesn't even know about this functionality, so you cannot check for it, either. Choose a different key combination.