What browsers are implementing the input attribute "accesskey"?
Is the behavior consistent cross browser?
Is it safe to use accesskey as just an extra data attribute (like the "rel" and "rev" are sometimes used on the a tag)?
Also, is there a way to capture the "onaccesskeypress" in JavaScript? Does it just fire an onclick event?
Browser support:
All major browsers support the accesskey attribute. Although there has been some discussion whether this is a good thing for accessibility, it remains part of HTML (as of HTML5).
Consistent behaviour:
Behaviour is only consistent across browsers & platforms in that pressing a particular set of control keys and the defined accesskey key will activate the link.
By definition, every web developer is free to define access keys as they wish, and there isn't an agreed standard for common links, such as 'Jump down to the main content', 'home', 'sitemap' etc., so there's no consistency from website to website. See my suggestions below.
Also the control keys for accessing these keyboard shortcuts differ from browser to browser and platform to platform, and occasionally there have been changes between browser versions too.
The Wikipedia page about access keys provides a list for a wide number of browsers and should provide you with an up-to-date list.
Safe to use accesskey as just an extra data attribute:
I'm not sure what you mean by 'safe'. Here is an example of how to use it:
<a accesskey="9" href="/sitemap.html">Sitemap</a>
Personal suggested access keys:
0 - Home
9 - Sitemap
8 - Accessibility page (listing the keys)
1,2,3... - Main navigation items, top-level only
accesskey has pretty spotty implementation. Firefox allows you to use any character as an accesskey value, while Safari seem to only allow numeric characters (for example, on this page).
The next button is mapped to the > accesskey. It works in Firefox (Ctrl>, on a Mac), but not in Safari.
In my opinion, if keyboard navigation is essential to your webpage, using JavaScript is a much better option.
Some resources I used to come to my conclusions: [1], [2]
EDIT: After a bit more experimentation, it appears that Safari honors accesskeys that are alphanumeric characters. The keystroke to execute them is CtrlAlt{ACCESSKEY}. I still think JavaScript is the best way to implement keyboard navigation, but I thought I'd add this information for clarity.
Every major browser supports accesskey (parses it and assigns keyboard shortcuts accordingly).
The problem with this is that the control key is different for every browser. On Internet Explorer, it's Alt + key, Firefox uses Shift + Alt + key, Mac uses Ctrl + key.
Related
I am trying to make my website accessible in high-contrast mode. In order to detect when high-contrast mode is enabled, I created a JavaScript method to detect if background images are disabled, because high-contrast mode disables background images. Then if the browser is in high-contrast mode, I append a CSS file to make fixes for displaying in high contrast. This works fine in Firefox, Edge, and IE, but Chrome uses its own extension to create high-contrast, and it does not disable the background images, so in Chrome the CSS for high contrast is not appended.
From searching I have found that Chrome adds a filter over the website as opposed to enabling/disabling/changing the website colors or images themselves. I have searched and searched, but I can't find anything to test to check if Chrome is using high-contrast mode. If there were a way to detect which extensions are being used that would also solve the problem, but I haven't been able to find a way to do that either.
My code actually works fine, all I need is to be able to detect the high-contrast mode in Chrome. Here is the method I use to check for high-contrast mode.
let highContrast = (options) => {
let hcDetect = jQuery(`<div id="jQHighContrastDetect"></div>`).css('background', 'url(../uploads/c-wht-small.png)');
hcDetect.appendTo(document.body);
if (hcDetect.css('background-image') === 'none') {
$('head').append('<link rel="stylesheet" href="../css/highcontrast.min.css" type="text/css" media="all">');
}
}
If you are asking about Windows High Contrast Mode, Chrome does not know when that is active.
In general, if a Windows user has chosen to enable High Contrast Mode, then that user is surfing in Microsoft Internet Explorer or Microsoft Edge (as these browsers support it). Both of them support the proprietary -ms-high-contrast #media rule.
Checking for a missing background image is a tactic that would work in IE/Edge, but using the media query is a better approach. Especially since Windows High Contrast Mode will soon allow background images in Edge.
If you are looking to detect when a particular extension has set its own high contrast mode in Chrome, it would be helpful to know which extension.
For example, with the High Contrast extension you can look for the following attributes on the <html> tag: hc="a3" and hcx="3" (the values may be different for you, but the attributes should match). If you open the browser dev tools you can see some other things it does. but those attributes are at the highest level of the DOM and probably safest to use.
If you are asking about Chrome for Android, that is also a different process.
...all I need is to be able to detect the high-contrast mode in Chrome
Solution #1:
In my React/TypeScript project, I used code similar to #Wesley Abbenhuis's answer, but found I didn't need the timeout for my component that took seconds to load. In fact, I created a demo React project that tested for the extension in the first loading component, and no delay was necessary.
const htmlTag: HTMLElement = document.getElementsByTagName(
'html'
)[0];
const isUsingChromeHighContrastExtension: boolean =
htmlTag.getAttribute('hc') !== null;
Solution #2:
Make your non-high contrast code accessible, and you shouldn't have to detect Chrome's high contrast extension in the first place.
From the WCAG Criterion 1.4.11: Non-text Contrast:
Success Criterion 1.4.11 Non-text Contrast (Level AA): The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):
User Interface Components
Visual information used to indicate states and boundaries of user interface components, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;
Graphical Objects
Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.
The Chrome Extension will inject some code to generate a highcontrast LAF.
The setTimeout could be required duo to the injection. In my case it was required.
This worked for me:
setTimeout(function(){
var htmlTag = document.getElementsByTagName('html');
console.log(htmlTag[0].getAttribute('hc') != null);
}, 150);
I am trying to "feature detect" IE's behavior when pressing enter in an input box that has a button element next to it (when they are not in a form element).
I'm saying IE's behavior because no one else fires a click event on the next button when pressing the enter-key while the input is focused.
Related question where the first awnser describes why IE behaves like this:
IE bug triggers click for 2 buttons?
JS-Fiddle where I try to simulate the key press via jQuery.Event and .trigger:
http://jsfiddle.net/DbVrn/
Behavior of said js-fiddle in IE:
When opening the page, the input gets focus, and then we try to simulate pressing of the enter-key.
The simulated enter-key does nothing, hence the input remains focused and red.
If you manually press enter while the input is focused, the button will become focused and green.
The problem i have with my current attempt to detect this feature is that:
$("input").trigger(jQuery.Event("keypress", { which: 13 }));
does not actually do the same as manually pressing the enter-key while the input is focused.
How can I successfully simulate the enter-key so that my test for this behavior is possible?
Or is there another way i can test for this behavior?
Edit: Updated title to more clearly state that this needs to be tested via javascript, and that the test needs to work in IE from version 8 to 10. Unless anyone else can provide a way of testing this, I will conclude that I need to use user-agent sniffing to see if browser is IE and choose code-path based off that.
Neither by using jQuery's trigger method nor by using the native methods it is possible to simulate key presses in the way that you would like to. The real and simulated key presses can both be captured, but the simulated key presses do not trigger the entire chain of event handlers that are caused by a real key press. This is easily demonstrated by putting this line above your trigger
$("input").keypress(function(event) { alert(event.which); });
As you can see the capture works fine, for both simulated and real key presses, while the difference between the handling of those two key presses obviously remains.
It also does not matter what you do with your keypress event objects. You may add a keyCode, which the real keypresses in IE have, but this will not change this. It seems nothing will. Unfortunately I cannot find any documentation explaining why, though this problem has been around for a while
http://forums.asp.net/t/1478871.aspx/1
So there seems to be no way from within the browser. You would have to do it from without. You could use something like InternetExplorerDriver for that.
Instead of feature detecting I would recommend simply recording which user agents have this 'feature'. Since Microsoft is usually pretty bend on backwardscompatibility it is unlikely they will change the behavior of an enter keypress on an input field in future version.
http://code.google.com/p/selenium/wiki/InternetExplorerDriver
Simulating key presses that change input/textarea fields
Using the TextEvent method it is possible in some browsers (e.g. chrome) to send text, including new line, to an input or textarea field, but this will not work in any version of IE up to version 10 as demonstrated by this fiddle:
http://jsfiddle.net/qz7kV/1/
It seems there is no way to test for this behavior via JavaScript.
I have tested IE 8, 9 and 10 and confirmed they all behave this way.
So for now, i am going to combine some ideas from
Javascript IE detection, why not use simple conditional comments? and
http://tanalin.com/en/articles/ie-version-js/ to create a test for IE that will work reliably as long as IE does not remove support for conditional compilation comments.
var ie = (/*#cc_on!#*/false && (function(){
var div = document.createElement("div"),
list = div.getElementsByTagName("br"),
version = 3;
do {
div.innerHTML = "<!--[if gt IE " + (++version) + "]><br><![endif]-->";
} while(list[0]);
return (version > 4 ? version : 10);
}()));
The ie variable will be the browser version in Internet Explorer, and will be false in other browsers.
I don't see a reliably way to trigger the bug from JavaScript alone. You have several other options:
Install IE in a VM and use a UI robot to drive the test. That takes a lot of effort but will reliably trigger the bug.
There are companies which offer remote testing; they use SSH tunnels to access a server on your side and can test your site against many different versions of IE. This is pretty easy to set up technically but might be hard to get because of company policies, FUD and politics. Google for "test web site with many different browsers"
Test it once manually and when it works, write a test case which just checks that the code is there (i.e. a test that fails when the JavaScript file or page source doesn't contain a certain fixed string). Pro: Very easy to set up, Con: Breaks easily
Just test it once and then rely on inertia (i.e. that no one else will touch that code for years).
When running the below code, it fails to display the text I wrote. Instead, it displays in the status bar the URI of the link. Why is this happening?
link here
window.status isn't a standard property. It has been eliminated for security reason. You can't do that on modern browsers (including IE9).
You'll have to find another solution, like for example making a small div at the bottom left corner :
<a href="link"
onmouseover="document.getElementById('status').innerHTML='your text';"
onmouseout="document.getElementById('status').innerHTML='';">link here</a>
<div id=status style="position:fixed;bottom:0;left:0"></div>
Being able to modify the status bar information is an excellent way to mislead users into thinking that a link will take them to Place They Want To Be instead of Place That Will Steal Their Password… so browsers don't let page authors mess with it any more.
Internet Explorer 7 limits the ability of Web pages to use scripts to write information to the status bar. This ability is restricted by default for the Internet Zone, and is subject to user-configurable settings for Trusted and Restricted Sites Zones. This is part of the work to ensure that users are not misled by Web pages. Calls to window status will fail silently in cases where updates are not allowed.
— Security and Compatibility in Windows Internet Explorer 7
HTML has a title attribute designed specifically to provide advisory information about an element. Use that to display status information.
link here
I am trying to use the ctrl and + combination within firefox for a different action for our web application. How could I prevent firefox from zooming when our web application is listening for this event? I do not want to change a setting within firefox, but would like the code to do this somehow. Any suggestions?
I don't think you can overwrite application shortcuts with website code. Imagine a site overwriting alt + tab, and suddenly you wouldn't be able to tab out of your browser window anymore. It is possible with some plugins, but that depends on the browser you're using.
Instead, use something that isn't a default keyboard shortcut to prevent other users from having the same problems. Everyone expects and counts on ctrl and +- to change their zoom level; overwriting this simply isn't a good idea usability-wise.
You could try Flash. Flash tends to gobble up a lot of shortcut keys, including Ctrl+T (new tab) which drives me mad all the time.
According to this resource http://www.arraystudio.com/as-workshop/disable-ctrl-n-and-other-ctrl-key-combinations-in-javascript.html, you should be able to prevent any control keys.
I have used similar techniques, by catching all events on the body tag, and if they are the F keys, then returning a false to veto.
Is there a way to add hotkeys (such as the media buttons) for the webbrowser?
This would need to cause a javascript event.
I except a firefox extension is required and i am ok if the solution requires greasemonkey as well (i seen growl use them both for javascript interaction. But thats javascript->pc not the other way around)
-edit- is this not possible ATM?
Firefox supports something called an AppCommand event. On Windows and Linux, only 7 commands are supported: Back, Forward, Reload, Stop, Search, Bookmarks and Home.
To implement extra commands, supported would have to be added to widget/src/windows/nsWindow.cpp and widget/src/gtk2/nsWindow.cpp to generate those additional types of AppCommand event. These events could then be intercepted by an extension to perform custom actions.
On Android, a different set of events are supported: Clear, VolumeUp, VolumeDown, Menu, Search. I don't know whether these events are used by Fennec.
For completeness, OS/2 builds of Firefox support Back, Forward, Reload and Stop.