TUPA presentation, 2003.02.11

This huge and neglected topic looms large over Web accessibility – at least as soon as accessibility to images (through alt text and other text equivalents) has been taken care of on any given page.

Nondisabled visitors can experience a site in random order, picking and choosing where to look and what to do based on a range of heuristics that are at least passably understood by usabilitistas. But if you’re using a screen reader or Braille display, or if you have a mobility impairment that precludes moving anywhere you like on the screen at whim, then your experience of a site becomes serial – one item after another after another.

Here, a New Brunswick homepage stacks multiple upper navbars atop an impenetrable nest of non-obvious blocks of links. You have to get past the navbars and somehow navigate among the blocks.

Merely to fill out the form on this PEI page, you’re stuck tabbing past the upper icon navbar (which traverses in rather surprising right-to-left order), then the PEI wordmark and the full left-hand navbar, and then finally arrive at the first textarea in the form.

Contrary to popular belief, it is not forbidden to use tables for layout – either in the HTML spec (which states merely that tables “should not” be used for layout) or under WCAG (“should avoid”).

Current screen readers contain a plethora of commands to navigate within tables. There’s even some intelligence to detect a navbar and give the option to skip that. Tables are still moderately inconvenient to use for this disabled group, but only moderately.

The issues, then, are:

• Multiple nested tables for layout
• Data tables without correct header information (typically the th element – the myriad other headers are not generally needed)
• Navigation within and across tables (as we’ll see in one example)

• Vastly too much information on the page, with an overabundance of form titles, few of which are meaningful or predictable to average people
• Invalid code and table markup (on plain reading, a violation of §6 of the ODA)
• Ill-advised location of multiple poorly-ordered navigation elements within the table:
  • 19 alphabet-letter links
  • a search box
  • a pull-down menu (that auto-actuates on selection)
  • Next and Previous links
• “Format” column uses icons without alt texts
• Table headers are links that perform a re-sort action (presumably – it’s not declared)
• Is the distinction between light blue and dark blue significant?

Here, the PrideVision schedule:

• Uses nested tables for layout
• Has an impenetrable tab order (discussed below)
• Uses confusable colour combinations (red on black or the converse is hard to read for a group with a certain colour deficiency known as protanopia)

Moreover and the two data tables on the page, namely the program schedule and calendar, lack adequate table-header markup.

Forms can be somewhat inconvenient for a mobility-impaired person in that simple movement among fields is as tedious as movement in general. However, the big issue is accessibility to screen-reader users. (I don’t have a clue how to fill out an online form using nothing but a Braille display.)

HTML offers several elements and attributes, including label, legend, and fieldset, to improve accessibility of forms. You can then “associate” the label of or explanation for a “form control” (check box, radio dial, input box, or similar).

It then becomes at least possible for a screen-reader user to know what the form control he or she is using actually refers to because the underlying HTML includes an unambiguous correlation between the control and the explanation.

In conventional Web design, we try to create online forms that look like printed forms – with labels right next to the control, all tidy-like. Generally these layouts are achieved with tables.

The problem?

• Due to limitations in the Microsoft Windows accessibility infrastructure, in most cases when you’re filling out a form your screen reader’s ability to read other parts of the screen are reduced. (“Forms mode” generally requires that Active Accessibility be turned off.) Layers of form labeling reduce the confusion in cases like these.
• When forms are placed inside tables, a screen-reader user can simultaneously be in tables mode and forms mode, which needlessly increases complexity in moving the cursor within and across table cells.

The easiest and most usable solution is to give up on side-by-side layout of form labels and controls and use every HTML accessibility feature to the hilt. The result will, in many cases, be single-column forms.

Now, if you’re very committed to print-typography-style forms, can stylesheets position form elements in a quasi-tabular way?

Note that I appear to have given incorrect information at the meeting. It appears that screen readers have no problem associating a label element across a </td><td> boundary. See the WAI-IG thread.

These remain hypothetical issues. I don’t know of any real-world commercial sites with really accessible forms. We could do a test case with a TUPA volunteer, if desired – setting up a conventional-style complex tabular form and an analogue using improved design techniques. We could then promote the test pages online and ask screen-reader makers and users to try to break the page.

We have some indication, then, that HTML used for forms as typically found on real-world Web sites unnecessarily replicates print typography and is too complex for mobility- or visually-impaired visitors.

Phew.

In this AmEx credit-card application, labels and controls span </td><td> tags and, in fact, appear on both sides of such tags. Examples: The labels “How would you like your name to appear on the card?” and “(Cannot exceed 20 characters)” et al., and in the case of month, day, and year entry. That latter case, to the designers’ credit, resists the temptation to make “Month” the first month in the option list, “Day” the first day, and “Year” the first year.

In this Visa example, too many competing functions are crammed into a single table. You the user are expected to:

1. Understand and select which of the “products” you are interested in. At the very least, these should be marked up as headings, or, to be extra-pedantic, in a definition list.
2. Find it in the table, disregarding the other seven options.
3. Fill in your preferred credit limit, an action with real-world consequences: You’re gonna sit there and play a guessing game with yourself, thinking “Am I asking for too much? If I ask for too much, will that mean I’ll be denied when I would otherwise have been accepted?”
4. Select whether the credit limit is a new application or an increase. The default “N/A” is the last item in each row rather than the first.

No amount of accessible HTML markup can salvage this example. It’s confusing for a nondisabled person and essentially unusable in serial access under a screen reader.

In a case such as this, it would be preferable to ask a series of questions (product type first? new or increase? amount?) either on consecutive screens, à la a shopping cart. Or use a form that auto-expands based on the context of the visitor’s responses. For a non-corporate example of the latter (PlanetOut personal ads!), see p. 294 of my book.