Today I will talk about a JavaScript behavior learned in one of the examples found in the book, related to JavaScript events inside Web pages.
Types of usable event
Using pure JavaScript, not all existing events can be used on every page elements. For example: one of the first things I liked when I started using jQuery year ago was the possibility to use
onclick event for whatever DOM page element, also in Internet Explorer (that commonly dosn't allow this event to be fired for all types of element).The example I found in the book talks about another event:
onkeypress.What kind of elements can react to this kind of event? Commonly only elements able to take the focus (like links, but more common are form elements like
textarea of input).The example shows how using another uncommon JavaScript attribute we can change this behavior, enabling all other page elements. I'm talking of tabindex attribute.
How to use tabindex
As I'm mainly a Plone programmer, when tabindex was removed from all templates of the CMS (don't remember exactly, but I think it was when Plone 3.0 was released) I was happy. Why? Because tabindex is commonly not needed in a well-designed Web page.
The tabindex attribute define the order in which a user navigate the page using the keyboard (the TAB /SHIFT+TAB key) but if you define the order of your DOM elements in a logical manner you will simply not need this attribute. However note that it is not deprecated:
- Some non-common pages can need this attribute to force the navigation first to a page section that isn't at the top (to be honest, I can't find a simple example of this)
- A value of tabindex of "-1" make an element, commonly navigable using keyboard, not accessible anymore.
Now the great tabindex magic I learned: when tabindex is used on a DOM element (with a value of 0 or more), it magically gain the power of obtain focus.
Let see some examples.
Please note:
- I tested examples with Firefox, Opera, Chrome and Safari, on MacOS. With older Internet Explorer versions you probably need some fixes in event handling.
- If you are on MacOS, use Chrome because the keyboard navigation with TAB is a mess. See below for more on this.
onclick and onkeypress on those elements raise simply an alert message (the text inside the node).<html>
<head>
<script type="text/javascript">
<!--
window.onload=function() {
var handleAction = function(event) {
alert(this.innerHTML);
}
var p = document.getElementById('foo');
p.onclick = p.onkeypress = handleAction;
var links = document.getElementsByTagName('a');
for (var i=0;i<links.length;i++) {
links[i].onclick = links[i].onkeypress = handleAction;
}
}
//-->
</script>
</head>
<body>
<a href="javascript:;">Link 1</a>
<p id="foo">
Test here!
</p>
<a href="javascript:;">Link 2</a>
</body>
</html>
First of all the mouse event: you will be able to click on both links and the paragraph (not sure of this in all IE versions as I'm not using jQuery there).Now let's try the keyboard navigation. Using the TAB you will be able to move only onto link elements. When one element get the focus, clicking a key you will get the same message you get for a mouse click.
If you look at the code you'll see that I'm trying to register the onkeypress event also on the HTML paragraph, but it is ignored.
This is right: a world where every DOM element can get the focus will make keyboard navigation painful. But: how can I do if I really need that a single DOM element (commonly not focusable) could take focus and keyboard events?
This is where tabindex help. If you look at the second example you will see that the only difference is the use of tabindex on the
P node.<html>
<head>
<script type="text/javascript">
<!--
window.onload=function() {
var handleAction = function(event) {
alert(this.innerHTML);
}
var p = document.getElementById('foo');
p.onclick = p.onkeypress = handleAction;
var links = document.getElementsByTagName('a');
for (var i=0;i<links.length;i++) {
links[i].onclick = links[i].onkeypress = handleAction;
}
}
//-->
</script>
</head>
<body>
<a href="javascript:;">Link 1</a>
<p id="foo" tabindex="0">
Test here!
</p>
<a href="javascript:;">Link 2</a>
</body>
</html>
However, the behavior difference is big.You can try again the page with keyboard navigation with all browsers used before (again: I suggest to use Chrome if on MacOS).
Now you are able to give the focus to the paragraph! Also, keyboard event is now raised on the paragraph. You probably get the point...
Tabindex attribute can make focusable whatever element of the page and you are able to use keyboard events on them.Isn't this great? I think that could be helpful sometimes.
Browsers differences (AKA: MacOS hate TAB)
Let's change the article focus.
Testing example one and two with all defined browsers shown some different behavior.
The tabindex definition says that element with tabindex are the first that take the focus (from the lower value to the upper), keeping the DOM order when values are equals; only then, all other focus capable elements are traversed (still, using the top-down DOM order).
For a reason I never deepen, on MacOS (but workarounds can be found on the Web) only form elements seems able to take focus (links not). Also with Firefox, that on other Linux/Windows environment works like a charm, I can't put the focus on links.
The only tested browser on MacOS that works as expected is Chrome, however also Chrome does something unexpected: if you test the second example you will see that the DOM order are kept (while the tabindexed ones must be the first).
But example 2 works also on other browsers on MacOS: you are able to put the focus using TAB key onto the paragraph.
So you can think "I can try to put a tabindex on every DOM page element I want to be accessible using keyboard to fix this MacOS problem".
If you test example 3 (that put "tabindex=0" also on
A elements) you'll that this is false. Still, links are not accessible using keyboard. Strange...
No comments:
Post a Comment