A collection of tips, guidance and practical suggestions in developing accessible websites
form. And using a
fieldset to group these elements together is proving to be a very useful way of making them accessible.
Why would form elements appear outside of a
One particularly elegant use of scrollable image carousels is Flickr’s picture sorting tool. It allows a visitor to sort his uploaded photographs into sets and then annotate them either individually or in groups. The image carousel is a powerful metaphor for navigating through potentially thousands of images.
Another top notch demonstration of an image carousel is Apple’s Coverflow implementation which first surfaced as a means of scanning album covers in it’s much regarded iTunes media application.
It is clear we need buttons for navigating forwards and backwards through our list of images. Many developers use anchor links styled to emulate buttons, but a better method is to use a
button element. The
button element offers all the functionality of the simple link, plus you get the default button states for free. So semantically, a
button element is the appropriate element to use as a button.
The immediate retort I hear is that form elements only belong inside a
form, because otherwise it isn’t valid HTML. Surprisingly, the HTML 4.01 Strict Recommendation doesn’t impose this limitation at all. Form elements are not limited to being children of a
form. The DTD also doesn’t impose this limitation, and an English translation of it goes something like this:
All input related-elements (
button) belong to a group called ‘Form Controls’. The Form Control group is just a subset of inline elements.
This means that anywhere an inline element can validly go, so too can a form control element.
There are some exceptions, for example you can’t place a form control inside of a
What is even more surprising is that the
fieldset element also doesn’t have to be inside a
I suspect that allowing form elements and fieldsets to exist validly outside of a form isn’t an error by the HTML Working Group, but a particularly insightful forward thinking about the various alternate uses of these form input elements.
Many rich media pages on the web contain not just one single image carousel, but sometimes more than one. They also can contain similar enhanced widgets like video players, audio players, animation.
HTML5′s Canvas will probably be used as a means of visualising realtime data, like showing the spread of “swine flu” across the globe over time (with time annotated text-equivalents). It would be immensely useful to be able to move forward and backward through time and understand how the infection spreads at each time point. We would need buttons to allow a visitor to do that.
We quickly land in a situation where we may have more than one set of video-player controls, each one controlling a different widget or collection of content. (Much like every living room having multiple remote controls, and it’s a perennial game to remember which remote controls which device).
On the web we run into a two fold problem for screen reader users in particular:
It could be argued that buttons outside of forms should not be accessible in forms mode, but I find that argument has little merit because the buttons on the page still have a purpose to the user, and that equivalent should still be available to the screenreader user.
Otherwise we are not providing an equivalent experience. The interaction with video-player like controls doesn’t automatically mean that the output is visual only. We must not make that mistake.
To improve the accessibility of groups of buttons we wrap each group of
buttons in its own
fieldset. And every
fieldset has to have a
legend element that provides a succinct and short description of the collection of buttons.
legend text must be carefully thought out. It must be long enough to remove doubt about the purpose of the set of buttons that follow, but short enough for it not to be frustrating when prefixed before the description of every button.
But at this point, the
This adds another dimension to the
For example, when the visitor first focuses on an element inside of a
fieldset, the default
legend text can be an appropriate description of the purpose of these
button controls. As the visitor then interacts with the
legend can be updated on the fly to present more pertinent information, like the date of the currently displayed epidemic growth map, or some state information like the user is seeing the first four pictures of twenty.
Once again, as with so many other fine accessibility innovations at Yahoo, the credit and initial idea of using
fieldsets in this way was suggested by fellow Yahoo colleague, Artur Ortega, one of the real practical experts in web accessibility. He is a fertile source of excellent and creative ideas of improving the accessibility of interactive and rich media components. A true gem of an engineer.
Good info, cheers Mike!
Many thanks for an interesting and thought provoking article