Accessibility Tips A collection of tips, guidance, advice and practical suggestions in developing accessible websites

Posts tagged with “progressive enhancement”


Using titles on form fields

Form elements provide a decent range of accessibility options: label elements match up label text with their corresponding field elements, fieldsets group together similar input elements and the legend provides a succinct title for these groupings of fields. With those elements alone, forms are fairly simple to mark up in an accessible manner.

The difficulty comes when you need to add some supplementary information to an input field, or you need to provide a text equivalent to a non-text way of labelling a form field. Sometimes having one label per form field is a little messy, and can create accessibility problems when a visual requirement needs to be met.

The title attribute is mostly overlooked and underused. It is little known, but screenreaders read out the title attribute on form fields when in forms mode, even if titles are not read out by default. It's an exception to the general configuration.

Multiple choice questions

Many surveys offer a list of multiple choice questions where the possible answers are the same for each question. This type of form is normally marked up in a tabular-looking fashion, where the question is a row header, and the possible answers are labeled by a column header.

Marking this up as a table may be the correct semantic way, but the implicit association is not available to a screenreader in forms mode. The only elements that are available in forms mode are form elements (and their attributes). Thus, a form with a tabular structure needs additional markup to make it accessible to screenreader users.

Multiple labels, one per form field

One downside of labels is that one label can only be associated with one input field, so it proves a challenge to markup such a form without resorting to duplicate labels which then need to be hidden from view (and creating a unique id to map each label to its corresponding input field).

Implying column and row headings

Hiding most of the form labels brings another problem to the fore. When column and row headers are used visually to label a field it is visually fairly obvious that a relationship applies horizontally or vertically. There's a visual cue going on, and sighted people grok this cue almost immediately.

Unfortunately, this cue fails when the entire table cannot be seen in one go. People using screen magnifiers, or very large text sizes, only see a portion of this tabular form. They may not be able to make the visual connection because the column or row header may not be within the viewing region of the screen magnifier when the focus is on a particular form element. The further separated the form element is from its column and row headers, the more difficult it is for the screen magnifier user to figure out what information is being requested by the current form field. Scanning to find the column and row headers for a form field is prone to error, and makes the form more difficult to fill out.

Title attribute as a text equivalent

The overlooked title attribute provides a neat solution to this problem. Screenreaders will read out the title attribute on form elements in forms mode. Every form field with a title has a label that can explicitly identify a particular form field.

Screen magnifiers have the feature of displaying the title attribute when an element receives focus, so when a form field has focus, the title is presented as a tooltip adjacent to the form element. This alleviates the problem of the screen magnifier user scrolling around to determine the purpose of a form field.

Supplementary form field information

Another use of a form field title attribute is to provide supplementary information to a particular field. This can be, for example, a more descriptive variant of an existing label, a reminder that a field is mandatory, an example of a valid input (like the format of a date), or brief help text.

This supplementary information appears as a tooltip when that input field receives focus. This tooltip can be progressively enhanced, or stylistically improved, using JavaScript. The Content Management System Plone makes excellent use of the title attribute and JavaScript to present a visual cue for each for field on a form. This makes a form a little more usable, with very little cost, and that content is available to screenreader users too.

More accessible and usable forms

The title attribute offers an extra avenue for associating text to a form field. It should not be used as the first means of associating a label text with a corresponding form field. In situations where supplementary information is useful, the title attribute is helpful. In some situations where using labels results in masses of duplicated and redundant text that need to be hidden offscreen, it makes sense to use a title attribute instead. As with all accessibility problems, use the solution that best serves the needs of your visitors.

March 25th, 2008 / 1 Comment / Tags: accessibility, screenreaders, screen magnifiers, forms, labels, visual cues, tooltips, usability, title, progressive enhancement, input, form fields / Trackback

Deciding when display: none is appropriate

It's common knowledge that screenreaders won't read out content styled with display: none, but that doesn't mean content should not be styled this way. There are times when it is appropriate to style content this way, but we need to be careful.

Progressive enhancement with display: none

Core content should never be styled with display: none when JavaScript is not available. When JavaScript is enabled, it can hide content using display: none as long as there is an accessible means of reaching that content.

There are advantages to using display: none. We can make a page cleaner and easier to understand for screenreader users by hiding chunks of content that are not absolutely essential to be always available. And by having an accessible means of displaying that content, the screenreader user can chose to make that content available and read.

Drop-down navigation

A typical scenario of when display: none is appropriate is sub navigation in a drop-down menu. A screenreader user can then quickly skip through the top-level navigation items, or he can activate one of them, undoing the display: none on the sub navigation, and then navigate into that top-level's sub navigation.

The benefit for the screenreader user here is that they are not forced to wade through all the links of a navigation bar. They can deal with the navigation in discrete and easier to understand chunks of links. It makes a difference offering links in groups of seven, rather than expose the screenreader user to all 150 plus links in the navigation.

March 5th, 2008 / 5 Comments / Tags: screenreaders, accessibility, display, display: none, progressive enhancement, enhancement, javascript, dropdown, menu, dynamic, hide content / Trackback