Forms and interaction

AUTHOR’S NOTE – You’re reading the HTML version of a chapter from the book Building Accessible Websites (ISBN 0-7357-1150-X). Copyright © Joe Clark, 2002 (about the author). All rights reserved. ¶ Back to Contents

Your visitors can do more than just sit there and admire your Websites. Through forms and a few other mechanisms, they can “interact” with your site, to use a heavily-debased buzzword – typing into type-in fields, pulling down pull-down menus, checking check boxes, and engaging in other intellectually taxing pursuits.

Without doing anything special at all, typical forms are not very inaccessible. The additions you can make to bring forms up to spec are not onerous.

Goals

In this chapter:

Who are we serving?

Forms contain information unto themselves (the names of buttons, the labels for fields, the values of check boxes and radio buttons). Forms also accept information, as in type-in boxes. We have to make forms’ own information accessible, make it easy to manipulate form controls, and facilitate entering new information.

As is pretty much always the case in Web accessibility, we’re mostly trying to make life easier for blind visitors (as such – visually-impaired people have very few barriers). But given that adaptive technology has had a long time to adapt to the use of forms, the improvements you can make are actually quite modest. Mobility-impaired people stand to gain quite a bit through keyboard access – namely our old friends accesskey and tabindex, which we flogged to the point of stupefaction back in Chapter 8, “Navigation.” (We are stuck with the same old compatibility problems with those attributes, of course.) Also, we can make minor contributions to the accessibility of forms for learning-disabled people.

Issues with adaptive technology

If you’re using a screen reader, it is possible to get lost inside forms. Even if developers write a form that validates as proper HTML, some screen readers are incapable of telling you where the cursor is located or what any adjoining text might say.

These quirks bring back unpleasant memories of nonstandard browsers (not including Netscape 4, shurely?!) that are unable to interpret anything vaguely resembling proper HTML. There seems to be an expectation that you, the author or designer, are required to know all about these quirks and do everything necessary to accommodate them, rather after the manner of writing nonstandard HTML just so a browser (in an entirely hypothetical example, Netscape 4) will not actually crash.

I cannot support this approach. This book often suggests the use of HTML structures that, while fully legit, can be interpreted by few, if any, browsers or devices. Someday that will change, and you always have the option of writing more minimalist HTML that, while valid, does not make use of unsupported features. It is improper, however, to be expected to attempt nonstandard modifications because some makers of adaptive technology haven’t figured out how to interpret standard HTML. I’ve suggested accessible approaches that exceed very conservative HTML, but I’m not about to suggest a practice that fails to meet even that basic and simplistic level of programming.

Besides, without vast testing of particular Websites and combinations of browsers, platforms, and devices, I could not diagnose the problems in sufficient detail to actually tell you how to fix them.

What you need to do is write valid HTML, including accessible form tags and attributes where possible. If certain screen readers or other devices cannot handle valid markup, it is not your problem. Yes, arguably it is blind visitors’ problem, and they’re the ones who suffer, but they need to seek redress from the adaptive-technology developer, not you or me.

One more issue is relevant. To make a form look tidy and resemble paper forms, we often resort to the use of tables for layout. That is not a prohibited practice and never was, but screen readers sometimes fail to make it clear which cell containing text (that is, a field name) relates to which other cell containing the actual field. This phenomenon is not universal, but it is actually avoidable through better HTML coding, as we’ll soon see.

The basics

Note: If you’re already familiar with basic HTML, you can skip this section.

Forms are doggedly complex and intricate structures rivaling Stonehenge and the Mayan ruins. I really am going to give you just the basics here (and not a lot of examples), since it is quite possible to write a book half the size of this one purely on forms design. (Indeed, in the print medium, you can find a range of such books, not to mention books on PDF forms.) I did say at the outset that basic HTML knowledge is required to understand this book; forms, however, are well beyond basic.

I ask the reader’s forgiveness for my inability to reinvent the wheel when it comes to teaching forms. I regret that I have but one life to give to writing an accessibility book, not one and a half.

Forms, unsurprisingly, sit inside <form></form> tags. A range of form controls are available, including input, <select></select>, <textarea></textarea>, and <button></button>. But since <form></form> is a so-called block-level element, you can use all sorts of regular HTML markup inside it (like paragraphs and headings), turning forms into documents inside documents.

What do these form controls do? Defining them becomes an exercise in tautology, actually (that is, input is for inputting, <select></select> selects, the options for <select></select> are called options), but here we go anyway. I’m leaving out the accessibility tags and options for now.

Setting up a form is one thing, but processing its contents is another – using the famous method="get" and method="post" attributes of the <form></form> tag, among other methods. And boy, is that topic ever not basic. I would suggest entry into one of the leading Silicon Valley monasteries to learn the full manipulation of the runes of the <form></form> tag.

Jukka K. Korpela wrote a bit of useful explanation for me on dynamic forms: “Form processing itself takes place behind the scenes, so there are no direct accessibility issues. But usually the processing ends with sending a result page to the browser, and the accessibility issues of that page are very important. In particular, it should present the most essential information first, details later, and if it contains a new form, the form should appear after the results proper. However, these accessibility issues might be beyond your control, or you might have just a few things you can do, by selecting among available forms-processing software and perhaps by setting its parameters.”

Accessible additions

Fortunately for all of us, there isn’t a whole lot to do in making forms accessible. Let’s start with navigation.

Keyboard control

Improving keyboard access to forms isn’t of huge benefit to blind people, but it certainly helps someone typing with one finger or using switch access. (You’ll recall – from Chapter 3,“How do disabled people use computers?” – that switch access involves using a single control to cycle through all keyboard and mouse commands in descending order of generality until you encounter the command you wish to actuate. “Slow” doesn’t begin to describe it.)

Moving to the form

All the standard barriers related to bypassing left-hand navigation or other links and content remain in force. If the purpose of the page is the completion of a form, or if a form is a small but high-profile component of a complex page (e.g., “Type in your E-mail address to subscribe to our newsletter”), you definitely want to be able to skip to the form and move conveniently through it.

Make sure any form on a page – and I do mean any form – becomes one of the landmarks accessible by tabbing. For this, we use the tabindex attribute, which cannot actually be added to the form tag. Among the tags that can take the tabindex attribute are input, <select></select>, <textarea></textarea>, and <button></button>. You’ve got two options:

Either method will make it possible to simply tab from landmark to landmark on the page and eventually hit the form. Now, if the entire raison d’être of your page is a form, even if it has a few paragraphs of introductory text, a case can be made that you should use a very low tabindex value (like tabindex="10" or tabindex="200"), possibly even the lowest (tabindex="1"), so that the visitor can tab to it early, if not first. In this case, getting right to the form may be more important than getting past a navbar or getting right to a search field.

(And a search field, you will note, is actually a form. Of course, if there’s a search field on every page but the content of the page in question consists of a separate form not duplicated elsewhere, then that big form is what takes precedence.)

Moving inside the form

Getting around within the form is sometimes more complicated, but the complications are often beyond your control. Macintosh users are not very accustomed to manipulating forms entirely by keyboard – anywhere, in any application, not just Web browsers. Compared to Windows, it’s virtually impossible. (Mac OS X 10.1 was the first system version to permit global keyboard usage, and even then there were bugs.)

On Windows, in fact, there are a whole host of keyboard shortcuts to move among and within form elements – Tab, downarrow, spacebar, the Return key (which Windows insists on calling Enter). You can select check boxes and radio dials, pull down menus, and type in your own entries, among other actions.

Most blind people relying on screen readers use Windows. They’re all very conversant indeed with keyboard commands, particularly since screen readers themselves demand exceedingly obscure, finger-mangling keystrokes just for basic operation. (Actual examples from the screen reader Jaws: Hold down the Insert key on the numeric keypad and type the 5 key there twice quickly; Ctrl-Insert-F; Ctrl-Shift-[ pressed twice quickly.) The standard keystrokes for moving around form elements are child’s play compared to the necessary overhead of the screen reader’s keystrokes.

We have the accesskey attribute at our disposal in marking up forms. It is perhaps superfluous for blind visitors for the reasons just described, along with the perennial issue of making the accesskey actually visible to or detectable by any visitor with any disability or lack thereof. accesskey is, however, useful for mobility-impaired people, though exactly how we make them aware of its presence is a source of frustration.

For this application, you can intelligently add accesskeys to form fields and controls to which people would want to skip directly – the high-profile controls, you could say. Nothing’s stopping you from adding accesskey to most or all form controls (though you might run out of letters and numbers soon enough, and they must not conflict with accesskeys defined elsewhere on the page), but it’s a lot of work with minimal benefit.

Why? If you have two type-in fields (city and state/province/territory, for example) close enough that you could move from one directly to the next via the Tab key, it is actually more trouble for the mobility-impaired visitor to press the accesskey, assuming he or she knows what it is. Tab is Tab is Tab; it’s a primitive, an irreducible key on a keyboard. To actuate an accesskey, you typically have to hold down a modifier key and type the accesscharacter (which you’ll recall is what they actually are, not keys per se). That’s two or three or more keypresses depending on circumstances. If your switch gives you a chance to make an actuation of any kind only every few seconds, every keystroke counts.

Some criteria for selecting high-profile controls:

This entire approach represents another instance of the practice of placing landmarks throughout a page in an order that can be selected by keyboard access.

Reset buttons

In general, Reset buttons are a miserable idea. Real-world visitors are quite likely to hit the button by accident and wipe out everything they have entered in the form. Web developers seem to include Reset buttons because HTML makes it easy. I’ve been online since before there even was a Web and I can tell you categorically that I have never once found a Reset button that truly needed to be there.

If you absolutely must be contrary and include such a button, do not give it any kind of keyboard control. Make it impossible to actuate accidentally by keypresses. Do not under any circumstances give the Reset button an accesskey. It is too easy to press the accesskey accidentally, especially because today’s browsers and adaptive technology do a very good job of keeping the accesskey secret in the first place. Not knowing which key to avoid pressing, you might end up pressing it anyway.

Don’t give a Reset button a tabindex, either. You don’t want to make it easy to select the button. Leaving the button bereft of access features merely makes it no better or worse than a plain, standards-compliant HTML button. It might make sense to give tabindex values to whatever item precedes the button and whatever item follows it so that the button will be skipped.

If you must assign a Reset button a tabindex, give it the very last numeric value of the page. I’m sure a number like 32767 will do (one less than the very maximum). In fact, let me advance that as a convention: If you absolutely must, inexplicably, include a Reset button in the first place and if you stubbornly demand to give it a tabindex, let’s all use 32767.

Grouping options

Think back to the difference between reading a Website with the naked, nondisabled eye and with adaptive technology like a screen reader. The difference pertains to random vs. sequential access.

Forms give the deceptive impression of being perfectly suited to sequential access. You’re dealing with one form component at a time, right? So your attention is focused on one item at a time, isn’t it?

Yes, true enough, as far as it goes. But real-world Websites pack a lot of information into a single form field. Have you ever had to specify the country you reside in via a pull-down menu listing a couple of hundred of them? Or had to select certain occupation categories from a job site? (If you want more than one category, you must use particular keyboard commands.) Have you filled out a poll or survey online, whose dozens of questions all have exactly the same seven response options formatted as radio buttons?

Usability specialists (“usabilitistas”) would argue that two of these examples constitute bad form design. You should be able to type in the name of your country (or its two- or three-letter code) and type in a number from 1 to 7 corresponding to your poll response. Arguably, you should be permitted to type in keywords in a text-entry field to specify job categories.

Web developers favour overly complex and regimented form interfaces like these because they preclude errors. There is no chance of mistyping Liechtenstein, or entering a response value of 0 or 3.7, or of requesting a job category of despoiler of worlds, smithy, or yo mama. If it’s hard for the user to make a mistake, programmers don’t have to worry about fixing up errors after the fact, which, frankly, is a programming hassle.

Further on the topic of form design, one entry on a form may be listed right after the previous entry. (It’s quite possible to include intervening text or graphics, but that is not common. Fields tend to follow one after another.) On a credit-card application, for example, address may be related to city and name may not be unrelated to both, but credit and employment history, income and expenses, and other required information really are islands unto their own. Yet, when read sequentially, one topic bleeds into the next.

This approach creates a few barriers.

Solving the problem

In HTML, you can group related fields and options.

Fieldsets

You can use the <fieldset></fieldset> tag to chunk up form fields into “sets.” There is no preordained arrangement you must adhere to. Instead, think about the conceptual groupings on your form. In the example of a credit-card application, all the following are viable fieldsets:

The HTML technique involved is ludicrously simple, so I won’t dress it up: Just slap a <fieldset> tag at the beginning of a set and a </fieldset> tag at the end. It’s analogous to using <div></div> tags to break up chunks of content anywhere else in a Website.

Optionally, you can add a <legend></legend> tag directly after <fieldset>. Between the opening <legend> and closing </legend> tags, you can enter a name for that fieldset:

Such a legend acts exactly like <caption></caption> in <table></table>, with the same alignment values: align="top" or bottom or left or right. You may add an accesskey to a legend; what support there is for this usage appears to give focus to the first item in the fieldset. (I got it to work in Netscape 6, but not iCab.)

At time of writing, browsers that support <fieldset></fieldset> surround each of them in an ugly bounding box. I suppose it can be argued that these fieldsets should be visible, in part because they benefit a learning-disabled person who can see the groupings. But perhaps it should be possible to turn this visibility off and on. To turn a border off, add this line to your stylesheet:

fieldset { border: none }

You may have to add padding to produce an adequate visual appearance, and in my experience fieldset margins require tedious fiddling with width or percentage parameters. If you can produce a reliable and tolerable visual appearance for your target audience’s browsers, then you must use fieldsets. They’re simple and effective.

If, however, you are saddled with a stylesheet or browser incompatibility that refuses to make the intrusive bounding box go away, this may be one case where the overt visible form of an accessibility provision is too intrusive to be justified in any site that attempts to control its general appearance. (Not all sites do.) The Web Accessibility Initiative tells us: “Content developers should group information where natural and appropriate.” fieldsets may be natural, but they may not be appropriate in the (possibly rare) case where their default visual display cannot be modified and clashes intrusively.

Use this exemption sparingly, if at all. I have not found a reasonably-standards-compliant browser yet that is unable to deactivate the default border. You may be stuck with one of them, in which rare case you may refrain from using fieldsets.

On the other hand, you may kind of like the overt visual clustering. You could experiment with other border settings (like dotted 1px gray) to make the border more visible and yet also more palatable.

Option groups

Meanwhile, options in a <select></select> tag (a pull-down menu, effectively) can be grouped together using <optgroup></optgroup>.

The use of the tag is simple and quite akin to <fieldset></fieldset>. Surround any related option tags with an <optgroup> and an </optgroup>. Always add a label attribute to the tag (which must be unique per page). A generic example looks like this:

<select name="country" id="country">
<optgroup label="A1">
<option></option>
<option></option>
<option></option>
</optgroup>
<optgroup label="A2">
<option></option>
</optgroup>
<optgroup label="B1">
Any number of option tags
</optgroup>
</select>

You cannot nest <optgroup></optgroup> tags; they may contain nothing but <option></option> tags.

Browser handling of option groups varies, but is not entirely bad.

In practice, the exact content of your menu will likely not be compatible with this approach. Not every option list can be subcategorized. Maybe only a minority ever could be. In the worst-case scenario of a vast list of every country name on the planet, you could divide everything up by continent. More-current browsers will group the list of options in a way that most people will find helpful. Reading the lengthy menu may be made less onerous by the submenus or visible headings in browsers that provide them. But this case is perhaps exceptional.

Since you have only one level of grouping to play with, this facility is somewhat limited, but it is substantially better than nothing, it actually improves the appearance of menu items, and it is terribly slick and clever. Use option groups whenever possible.

As Jukka K. Korpela points out, in form designs where optgroup might help, it may be better better to ask the visitor to make choices in different steps (using server-side intermediate processing when needed) than to create nested menus.

Do not, however, succumb to the temptation to use the <optgroup></optgroup> syntax to provide instructions, add advertising, or be cute. (Do you still use <dl></dl> to indent text?) Don’t enter option-group text that does not actually categorize the option group. Do not flout the laws of Nature.

Field labels

There’s a rather oddball tag called <label></label> that lets you “associate” textual or graphical labels with specific form controls.

Some older screen readers have a hard time linking a form control to nearby text, particularly across the boundary of a table cell. The <label></label> tag solves the problem two ways:

Questions of display

<label></label> takes a form rather similar to <span></span>. It can contain any “inline” element, like text or even an image (with appropriate alternate text, of course). That means the inline text, image, or other material will be overt and visible, as labels generally are in the real world.

Accordingly, even though you can place a label for a form control anywhere on a page at any distance from the actual control, wherever you place the label is where it will show up.

Usage

If you do want to separate a label and a form control in your HTML, you must use an identical assignment of id (not name) for the form control and the label. The “oddball” part comes into play here. The syntax to specify the id looks like this:

<label for="idvalue"> Label text </label>

It seems a bit baldfaced and contrived to use “label for x” in HTML, but since the label tag was added to HTML only very late in the day (in version 4.0), these syntactic oddities must be tolerated.

In any event, having set up your label tag in that manner, all you need to do is add id="idvalue" to the form control, wherever it is. (Note that you must use id, not name.) Any kind of form control will work – buttons, check boxes, radio buttons, menus, text inputs, file selectors, and anything else that’s valid HTML.

It makes a bit more sense to enclose a form control, and any necessary plain text, in a <label></label> tag. In this case, you may use for="idvalue", despite the redundancy. Preferably, just surround the form control with <label></label>. Some examples using a simple control like input:

Titles

As in that last example above, you can add titles to essentially everything in HTML, including the entire range of form tags. Even if you’re also using the accessible HTML catalogued in exacting detail here, there is no harm and possibly quite a bit of benefit in using titles in forms.

There is some indication (which I was not really able to verify) that certain screen readers have trouble wading through forms whose elements lack a title. That really means every single element – every check box, every radio button, every text-entry field, the lot. I am something of a title fetishist and do tend to use them religiously, but I am not quite willing to advise you to add a title to absolutely everything. Why? Screen readers, like all other HTML-aware devices, must be upgraded to understand standard HTML. Requiring an optional attribute like title just to use a form suggests that the screen reader in question needs to be fixed.

I would say it is most useful to assign titles to input and textarea fields – anywhere you must enter your own information. Since titles provide “advisory information,” use this facility to advise what you want us to include in that field. Examples:

Imagine you’re a disembodied voice piping out of the speakers of your visitor’s computer. What advice would you give on how to fill out that field? Take that advice, write it succinctly, and include it in a title.

Radio buttons are another application. To use a previous example, a poll in which you are expected to select one of seven response buttons, duplicated in the dozens all the way down a page, can become confusing. Which button refers to Strongly Disagree? Strongly Agree? Agree Somewhat? Adding a title to each button makes that information clear to most visitors (through tooltips, status-line display, and screen-reader output).

A perennial goal of accessibility is to provide redundancy of information. Using all the HTML accessibility tags customized for forms along with ever-present titles gives us about as much redundancy as anyone has a right to expect.

Keyboard access

A label may also take an accesskey; the HTML specification tells us simply: “When a label element receives focus, it passes the focus on to its associated control.” Selecting the label via accesskey, then, is the same as selecting the associated control. Kookily enough, this also means that a label and a form control associated via id="idvalue" can theoretically be actuated by the accesskey irrespective of the distance between the label and the control. I suspect this was one of the many unintended consequences of undertested Web Accessibility Initiative modifications.

Graphical buttons

As elsewhere in accessible Website design, you must use text equivalents for graphics, including alt, title, and longdesc. alt is the standard method for the img and embed tags, as you well know, and you are free to use either of those tags for, say, a graphical button.

However, input type="image" itself can carry an alt, which is a good thing, since there is no actual img tag that could carry it within that usage. But we’re dealing with a new addition as of HTML 4.0 here; older documents won’t have alt inside input. (Or if they do, it wasn’t legal at the time the code was written – people did improvise in the old days, sometimes with good intentions.)

Text-only browsers and graphical browsers with image-loading turned off could always avail themselves of two other attributes of the input tag, namely value and name. Back in the day, oldschool browsers used one of those entries as a text equivalent, substituting for the alt text that was not legal at the time.

Nowadays, though, you have all those at your disposal, plus id and title. That’s five possible text equivalents or text equivalents manqué: alt, name, value, id, and title. Based on my own research (I’ll spare you the details), I would suggest the following:

Syntax like the following is legal:

<input type="image" src="button-6.gif" alt="Continue" name="Continue" id="Continue" value="Continue" title="Proceed to checkout" />

It’s redundant, redolent of outdated coding kludges, and vaguely laughable, but legal nonetheless.

(With all five text equivalents present, Lynx displays value; using only one at a time, or simply deleting value, my testing shows that Lynx displays alt by preference but no alternative text at all if you use only title, id, or name. The details are somewhat academic, I know.)

Prefilled form fields

The Web Content Accessibility Guidelines list the following as a Priority 3 (advanced) measure: “Until user agents handle empty controls correctly, include default placeholding characters in edit boxes and text areas.”

Evidently some very early screen readers could not detect the presence of an empty text-entry field at all. It simply ceased to exist. This is yet another case of adaptive technology’s inability to interpret standard HTML, and in this example the cure may be worse than the disease.

One of these outmoded screen readers may be able to detect your form field due to the default placeholder text it contains, but the visitor must then listen to the text. Fine so far – but where did the text come from? Is it text adjoining the field that attempts to provide instructions on how to fill it out, or is it indeed text inside the field? (You may have to hunt around with keyboard commands that force readings of nearby objects to find out.) Further, if a field carries prewritten text, you must delete the text to use the field.

As a nondisabled person who has been online forever, is a quick typist, and knows all keyboard shortcuts in wide use, even I very often have to struggle to delete every last character inside a field. I know all about key sequences like Select All and Delete, but half the time I’ll mistype the Select All command (selecting everything in the browser window), or I’ll try to select the text with the mouse and click the adjacent button instead, or delete everything but one character. It’s nothing but trouble. And I’m not blind and I have no trouble manipulating a keyboard and mouse. Imagine how much of a bother it is for those groups.

Besides, we can’t keep working around the quirks of nonstandard devices, be they an Ebola-like browser (could it be Netscape 4?) or creaky old screen readers. It is probably a bad idea to prefill your text fields if this is the only reason you’re doing it.

One does occasionally happen across a Website whose text fields (a search box, for example) are prefilled, though the text disappears instantly when you deposit the cursor in the field. Based on queries submitted to screen-reader makers, screen readers are not confused by this technique and indeed do not bother to read the prefilled text once the cursor is deposited in the field. This practice seems to be gilding the lily anyway; thousands of Websites get by just fine with entirely blank text-entry fields.

Rethinking layout

You now have a lot of knowledge about forms, but how do you apply it?

Apart from adding these accessibility tags, you may wish to rethink the layout of your forms. The access additions, particularly label for="idvalue", allegedly solve the problem of associating form controls with their labels.

We wouldn’t have had to go to all this trouble if designers had not resorted to hacks like the use of table cells to align form fields and text. There seems to be an effort to emulate the design tropes of printed forms – in particular, a desire to place the label of a field to the left of the field itself. Side-by-side positioning is difficult in a linear language of expression like HTML. So the table hack and its ilk were not unforgivable, though they brought up unforeseen problems with noncompliant screen readers, which made it difficult or impossible even to detect certain form elements when dispersed through tables. Moreover, the task of navigating table cells is always slower using serial access; depending on your settings, your software may let you know every single time you pass from one cell to another. It is all unduly complicated.

Maybe the online medium needs to make a virtue of necessity. If it’s difficult to align components horizontally, then let them appear stacked on top of one another. That might not be such a dire fate. The Web is not print, as they say.

If you use structural groupings like <optgroup></optgroup> and even <p></p> (abetted with stylesheets for acceptable appearance), there is very little chance that a visitor relying on adaptive technology won’t be able to figure out what goes with what. It’s merely a suggestion.

Error-checking

It is helpful to provide error-checking that does not merely alert us to a mistake we’ve made but attempts to correct it.

If you take my advice about providing type-in fields rather than menus for, say, country names in forms, and if I type “Gremany” in that form field, it is better practice for your system to map that misspelling to “Germany” or at least present a list of likely options. (I suppose that is not a very good example given that few country names are confusable. Mistyping “Austlia” could mean Austria or Australia. Or a state name like Dakota or Australia could be ambiguous – is it North or South Dakota? Western Australia or South Australia?)

Error correction of this sort provides improved accessibility for dyslexics. And for bad typists. It’s a very good idea. A bother to program, but useful nonetheless. Retrofitting functions like these might be too much to ask, but I would be pleased if all readers who create complex forms promised themselves that they would add error-checking to any new forms they create and over whose back-end programming they have influence – even something as simple as a search interface that would check mistypings against likely correct entries.

If you need to alert us to an error, you must use redundant methods. You may not simply present the form to us again with the erroneous fields marked in red. An entire chapter of this book (9, “Type and colour”) explains why that method will be inaccessible to pretty much anyone who is colourblind or reliant on a screen reader.

Dynamic forms

Forms that don’t just sit there and let you use them as plain-Jane HTML – as though this were still 1994 and our expectations were pretty low – are increasingly common. You’ve probably run across dynamic forms: As soon as you make an entry in one field, the rest of the form changes altogether.

This approach can be intelligent and well-conceived. Localization is one reason to design a dynamic form. To return, yet again, to our example of a vast list of country names, you could set up your form so that only the most relevant fields for postal address or phone number appear once the visitor specifies a country name. The form may default to U.S.-style addressing (street address, city, state, ZIP) but change to province and postal code for a Canadian address or provide something more free-form for a Swedish visitor, given that Swedish addresses aren’t as structured as those in the U.S. or Canada. Or a phone-number field could assume a country code and provide just the right number of possible digits for area code and number (an issue Americentric forms, with their demands for three-three-four number formations, flub notoriously).

Another example is found at the PlanetOut.com personals. When setting up an advanced search, the system asks you to select first a continent, then a country, then a city. But only one of those options appears at a time, building up from top to bottom in reaction to your inputs. (What am I doing searching the PlanetOut personals, you ask? The accessibility specialist–author, lonely and dispossessed in his northerly garret, is sometimes forced to cast his drift net wide.) It’s a very intelligent and respectful method of handling a worldwide (though still English-speaking) visitorship.

But by far the most common dynamic form device is a pull-down menu that actuates as soon as you make a selection. Usabilitistas have a fair bone to pick with this approach:

The solution is easy, actually. Always provide a valid HTML button or control to advance to the next step. A Go button next to a pull-down menu is perfectly standard. A Continue or Proceed button in a sophisticated form will do fine. If you use a graphical button, all necessary text equivalents must be supplied. (You may also wish to enclose a Go or Proceed button in a <noscript></noscript> element so that only JavaScript-unaware browsers even render it.)

Another questionable technique: Instead of assigning the menu any kind of label (even plain text outside the <select></select> coding), the first entry in the menu options acts as the title or explanation of the menu. Funnily enough, though, there is no nation called “Choose your country,” nor does anyone speak “Choose your language” – but you’d never know that from the way developers rig up their menus. You now have a range of accessible methods (even the use of plain text outside various form elements) to solve such problems.

Real-world issues

Our goal here is accessibility and not a narrow form of compliance with published standards. It is not enough to code a form accessibly; you must also accommodate accessibility in the real world.

Telephone numbers

If a form you design has an entry field for a telephone number, aren’t you assuming that every visitor can use a voice phone? Newsflash: Deaf people typically cannot talk on the phone; they use TTYs, which consist of a keyboard and a display (usually single-line) with a modem that only other TTYs can connect to. Deaf and hard-of-hearing callers, and those with speech impediments, can type back and forth in real time. TTY software and modems for personal computers are also available and are employed by power users who spend a lot of time on the phone.

If your Website form assumes that a visitor’s home or office phone number is voice only, your staff are in for a rude surprise when they actually dial the number and hear the distinctive TTY tones (which actually do not sound like a fax machine or a modem).

There would seem to be two telephone-number issues at work here:

Depending on context, your form may not need to take location into account, but I am telling you that your forms must take modality into account, even if you don’t care about fax numbers.

You will not have much of a problem making this accommodation. Everywhere in the U.S. and Canada (and some U.S. territories, like the Virgin Islands), Australia, and the U.K., relay services are available. (The U.S. federal government has its own relay service.) You call a hearing operator who acts as an intermediary between a TTY and a “voice” caller, typing what a hearing person says and reading what a deaf person types. (There are other variations: If you can speak but not hear, voice carryover is often available, for example. The range of relay services is quite extensive. There are, however, no really comprehensive Websites on the topic.)

In any event, a hearing person can always call a TTY user (any TTY user anywhere) wherever there is a relay service in the hearing person’s location. There is no extra cost for the call, and very often there is a discount due to the longer times required to communicate this way. Similarly, TTY users can call any voice number (at all – anywhere in the world).

Yes, it’s a bother, and you do have to train your staff to handle TTY calls through relay services, but it is still a notable improvement over having your staff dial a TTY number without knowing it actually is one. If you’re looking for training on relay-service use, call the relay service itself. In most parts of the United States, dialing 711 (just those three digits) connects you to local relay service. In Canada, 711, when it works at all, connects you to the TTY-to-voice end of the relay system; there is no uniform national phone number for voice-to-TTY service. Other numbers are available; since there are literally dozens of relay services operated by different vendors in North America alone, you need to check your local phone book or do a Google search on the keyword relay service plus whatever state or province you live in.

In Australia, call the Customer Relations department of the Australian Communications Exchange relay service at 1800 555 630 (TTY) or 1800 555 660 (voice). In the U.K., call Typetalk Customer Support at 0800 500 888 (TTY) or 0800 7 311 888 (voice). Elsewhere in the world, consult your local listings.

Now, ideally your business would own an actual TTY device or TTY software, and probably have a dedicated TTY number. But unless you’re a large retail concern with a lot of TTY callers or have a known demand from TTY callers, it is unnecessary to own your own equipment. That’s why we have relay services in the first place.

For each phone-number field on your forms, then, I want you to specifically add another field that allows visitors to specify voice or TTY (or fax). I would not worry about the somewhat common case of a household or business that can handle either TTY or voice; in practice, individual Website visitors always have a preference and will select one or the other.

Markup like this will suffice:

<input type="radio" name="telephone" value="voice" title="Voice number" id="voice" accesskey="v" checked="checked" />Voice
<input type="radio" name="telephone" value="TTY" title="TTY number" id="tty" accesskey="t" />TTY

Or you could create a small pull-down menu, or a type-in text field, or any of several possible interfaces. The exact approach is up to you; I just want you to do it.

Alternate formats

If one of the forms on your Website invites visitors to fill in their postal address to receive printed information by snail mail (poste escargot), do keep in mind that not everyone can read print, very much including the blind.

Now, it is clearly unreasonable to expect an online bookstore to stock all its products in Braille, large print, and/or audiotape; the central activity of the business is selling (inaccessible) printed books. On the other hand, a company that sells products or services other than books to the public should take into account the need to provide its information in accessible formats.

I am not advising you to have your company brochures Brailled, retypeset in large print, and/or audiotaped in advance of any known demand for those. I will, however, advise you to allow Website visitors to request such formats.

All you need is a plainly apparent indication on the form used to request the literature that says something like “Alternate accessible formats available on request.” You could add a little text area in which the visitor could type a request (if there isn’t one already – good design of feedback forms generally requires a Comments field), or simply let the visitor check a box saying something like “Contact me to discuss accessible alternate formats for this information.”

If someone actually takes you up on your offer, you will then be faced with having the literature in question converted to Braille or audiotape. Leave that job to the professionals. I would suggest another Google search using keywords like blind braille conversion or blind audiotape conversion plus the state or province you live in (if you are in Canada or the U.S.), or a similar approach for residents of the U.K., Australia, or elsewhere.

Large-print production you might be able to handle yourself. Provide the customer with the original, unaltered source brochure with regular or small print and a separate document with all the brochure’s text set in large type (at least 18 point, with lots of leading). Don’t use Arial as typeface, and do not use any kind of fancy or novelty font. The American Printing House for the Blind, APH.org, is a good resource, and indeed for U.S. readers, APH can convert literature into Braille, audiotape, or large print.

It may seem archaic to have to worry about print in the first place; we are, after all, building accessible Websites. I am, however, responding to the real world here. We do use the Web to order printed literature; I’ve done it myself. You must take disability into account in providing such a service.

Similarly, if your organization offers a promotional or informative video or audio product via Web ordering, it may be incumbent on you to provide captioned and/or audio-described video and, at the very least, a transcription of an audio product. Chapter 13, “Multimedia,” describes this process.

How far do we take this? Do all products a disabled person could even theoretically order via the Web need to be accessible? The blanket answer is yes. The reality is that they are not. Only a minority of products are accessible; so-called universal design is a rarity, and indeed universally-designed products are usually the most custom-designed products there are. In any event, you should consider the issue and take necessary steps.

Bottom-Line Accessibility Advice

Basic accessibility

Intermediate and Advanced accessibility

Previous   ¶   Contents   ¶   Next