456 Berea Street
18th Apr 2007, 09:16 pm
Any web developer who has created a reasonably complex form is probably aware of the concept of multiple select elements that are connected – choosing something from one select box either makes a new select box appear or changes the options of one that is already visible.
There are usually two problem with this approach. One is that most implementations are completely dependent on JavaScript being available. Often there either is no submit button at all, or there is a submit button but without JavaScript there is no way to access the options that appear only as a result of changing the first select box. The other problem is that in some browsers, using the cursor keys to change the selected option triggers the onchange event immediately, so you can never get past the first option unless you know how to use your keyboard to display all options.
I normally work around these problems by requiring users to submit the form to get the next set of options from the server. Obviously that isn’t an ideal solution either. So what other options do we have? One option that looks promising is described by Christian Heilmann in Unobtrusive connected select boxes - yet another solution approach (http://www.wait-till-i.com/index.php?p=411). It involves using optgroup elements to create a two-level select box, which is then split into two separate select boxes if JavaScript is available. Neat.
The solution Chris describes solves (or at least mitigates) the keyboard access problem since it doesn’t reload the page when the onchange event is triggered. And if JavaScript is unavailable, there is a single select box with option groups.
The catch is that nested optgroup elements are not allowed in current versions of HTML, so this will not work when more than two connected select boxes are needed. Nested optgroup elements are allowed in the current Web Forms 2.0 Working Draft (http://www.whatwg.org/specs/web-forms/current-work/), so I guess there is a reasonable chance of that change making it into HTML 5.
Visit site to read or post comments… (http://www.456bereastreet.com/archive/200704/unobtrusive_and_keyboard_accessible_connected_sele ct_boxes/#comments)Add 456 Berea Street to your Technorati favorites. (http://technorati.com/faves?add=http://www.456bereastreet.com)
Posted in Accessibility (http://www.456bereastreet.com/archive/categories/accessibility/), JavaScript (http://www.456bereastreet.com/archive/categories/javascript/).
http://feeds.feedburner.com/~a/456bereastreet?i=AYiGzt</img> (http://feeds.feedburner.com/~a/456bereastreet?a=AYiGzt)
http://feeds.feedburner.com/~f/456bereastreet?i=62pySro3</img> (http://feeds.feedburner.com/~f/456bereastreet?a=62pySro3) http://feeds.feedburner.com/~f/456bereastreet?i=O7yncNuw</img> (http://feeds.feedburner.com/~f/456bereastreet?a=O7yncNuw) http://feeds.feedburner.com/~f/456bereastreet?i=eoquI8R1</img> (http://feeds.feedburner.com/~f/456bereastreet?a=eoquI8R1)
More... (http://www.456bereastreet.com/archive/200704/unobtrusive_and_keyboard_accessible_connected_sele ct_boxes/)
There are usually two problem with this approach. One is that most implementations are completely dependent on JavaScript being available. Often there either is no submit button at all, or there is a submit button but without JavaScript there is no way to access the options that appear only as a result of changing the first select box. The other problem is that in some browsers, using the cursor keys to change the selected option triggers the onchange event immediately, so you can never get past the first option unless you know how to use your keyboard to display all options.
I normally work around these problems by requiring users to submit the form to get the next set of options from the server. Obviously that isn’t an ideal solution either. So what other options do we have? One option that looks promising is described by Christian Heilmann in Unobtrusive connected select boxes - yet another solution approach (http://www.wait-till-i.com/index.php?p=411). It involves using optgroup elements to create a two-level select box, which is then split into two separate select boxes if JavaScript is available. Neat.
The solution Chris describes solves (or at least mitigates) the keyboard access problem since it doesn’t reload the page when the onchange event is triggered. And if JavaScript is unavailable, there is a single select box with option groups.
The catch is that nested optgroup elements are not allowed in current versions of HTML, so this will not work when more than two connected select boxes are needed. Nested optgroup elements are allowed in the current Web Forms 2.0 Working Draft (http://www.whatwg.org/specs/web-forms/current-work/), so I guess there is a reasonable chance of that change making it into HTML 5.
Visit site to read or post comments… (http://www.456bereastreet.com/archive/200704/unobtrusive_and_keyboard_accessible_connected_sele ct_boxes/#comments)Add 456 Berea Street to your Technorati favorites. (http://technorati.com/faves?add=http://www.456bereastreet.com)
Posted in Accessibility (http://www.456bereastreet.com/archive/categories/accessibility/), JavaScript (http://www.456bereastreet.com/archive/categories/javascript/).
http://feeds.feedburner.com/~a/456bereastreet?i=AYiGzt</img> (http://feeds.feedburner.com/~a/456bereastreet?a=AYiGzt)
http://feeds.feedburner.com/~f/456bereastreet?i=62pySro3</img> (http://feeds.feedburner.com/~f/456bereastreet?a=62pySro3) http://feeds.feedburner.com/~f/456bereastreet?i=O7yncNuw</img> (http://feeds.feedburner.com/~f/456bereastreet?a=O7yncNuw) http://feeds.feedburner.com/~f/456bereastreet?i=eoquI8R1</img> (http://feeds.feedburner.com/~f/456bereastreet?a=eoquI8R1)
More... (http://www.456bereastreet.com/archive/200704/unobtrusive_and_keyboard_accessible_connected_sele ct_boxes/)