Using form elements outside of a form

Why would form elements appear outside of a form? Our typical use-case is an image carousel. In bare plain markup this is nothing more than an list of linked image elements. When we introduce JavaScript we can turn this plain list into an animated photo-gallery. A carousel of images a visitor can either let auto-scroll, or offer the visitor the option of manually scrolling through the images.

The practical use of image carousels

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.

Using the appropriate markup

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.

Is it valid?

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 (input, select, textarea, label, 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 button element.

What is even more surprising is that the fieldset element also doesn’t have to be inside a form.

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.

Multiple video-player like widgets

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.

Multiple remote controls

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 is difficult to determine which set of video player controls controls which group of content. Being adjacent to the actual content is sometimes not sufficient
• In forms mode these buttons are perceivable to the visitor, and without the surrounding context it is difficult to understand the purpose of these buttons.

The forms mode issue

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.

Grouping buttons by fieldsets

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.

Carefully chosen legend

The 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.

Dynamic legend text

But at this point, the buttons only make sense in a JavaScript context because the behaviour depends on JavaScript being available. Which means those buttons should added to the page by JavaScript, and consequently we can do the same for the legend and fieldset elements.

This adds another dimension to the legend text; it can be altered on the fly by JavaScript through a corresponding set of JavaScript events.

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 buttons 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.

Building on previous ideas

Dirk Ginader used this technique of updating legend text on the fly very successfully in Yahoo Finance’s accessible currency converter.

Acknowledgements

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.

Altered meaning

When a screen reader user, for example, reads the page all of the images are replaced with their text equivalents, and the resulting block of text is what the visitor gets. The two conceptually independent sources of text are merged into one block.

We need to consider the state of the merged content when that happens. Is the content still accurate, is the meaning and intention still clear.

When applying text equivalents to images we sometimes fail to consider how this new text will change the existing adjacent text content. The implications of this are:

• the content is not understandable
• the content becomes unintelligible
• the content changes meaning
• the content loses it’s accuracy
• the content becomes invalid or incorrect
• the content conveys a message that was not intended

Unintentional humour

Sometimes the end result is humourous. The late Dr. Alan Flavell in his notes on alt attribute howlers noted a real world example of two adjacent images, one was a picture of the page author in a canoe, and the other was a picture of a herd of buffalo. Two images of what interested the page author, and both with decent text equivalents. Unfortunately, in context, the block of text became: Photo of a buffaloes in the water canoeing, which was not quite the intended meaning.

Some simple punctuation would have avoided this unintentional joke.

Punctuating or extra markup

For this reason it is important to consider punctuating an image’s text-equivalent. A well-thought out comma or full stop, or parenthesis may be enough to protect the meaning and intention of existing text content from being changed when an image’s text equivalent is inserted where an image used to be.

If the text-equivalent can’t be written in a way that doesn’t hinder the meaning of the text content around it, then we need to consider moving the text-equivalent elsewhere; whether that means moving the image markup somewhere else, or leaving the image in place, and moving the text-equivalent to a more suitable spot (by using a null alt attribute and then inserting the text as a block of markup in the page).

Image links

A common mistake is to correctly determine that the text equivalent for the image is already present on the screen, in the form of the story title, and go from there to inserting a null alt attribute (alt="") for the image. When that image is the sole child of an anchor we are left with an anchor with no link text. And that’s an accessibility barrier.

The screenreader fallback when there is no link text for an image link is to extract something from the image’s src attribute – a URL – and this typically results in something unintelligble being read out by a screenreader.

What we need to do here instead is to populate the alt attribute with something that can be used as link text. In the case where the only appropriate (and succinct) text is the story title, it is fine to use that.

Redundant links

Its true that having two links with the same perceived link text linking to the same page is a redundancy, but this is much less of an evil than a text-less link. And much less of an accessibility barrier too.