Accessibility Tips

The focus on using the most appropriate markup in JavaScript enhanced pages has raised an interesting problem about the use of form elements outside of a form. And using a fieldset to group these elements together is proving to be a very useful way of making them accessible.

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.

Knowing where the keyboard focus is at any time is critical for keyboard users to navigate through and to a particular page. It’s not only screen reader users who don’t use a mouse, many disabilities leave the keyboard as the only viable way to interact with a computer whilst still using a monitor.

The dotted outline on links is the main visual cue to where the current keyboard focus is on a page at any one time. By tabbing or shift-tabbing through the document the focus is set on the next or previous focusable elements.

This focus rectangle is removed because it makes things look unsightly, but they serve a very useful purpose. And that purpose is critical for a keyboard user to find their way through a page.

So it is essential that there is a clear focus indicator, both on links and form fields. Clear enough that a visitor looking at the page for the first time can spot where the keyboard focus is as quickly as possible.

We do this though CSS’ :focus pseudo-class on the target element. For example, to change the background colour of a link when it receives focus we use the following:

a:focus {
    background-color: #aaf;
}

We can do the same with input fields:

input:focus {
    background-color: #aaf;
}

In each case, the background colour of the focusable element changes colour when it received focus, and that background colour changes back when the element loses focus. By making this background color change enough it is possible for a visitor to find the focused region of the page.

The same argument can also apply to when links are active, using the :active pseudo-class. An active link is one that is in the process of being clicked, so for example when the mouse-button is being held down when over a link and just about to be lifted, this link is seen to be active. Using this active pseudo-class to style an element that is active provides a visible cue about what is going to happen.

a:active { color: red; }

And, we often overlook the usefulness of setting a visited link colour (with the :visited pseudo-class). This proves very helpful in distinguishing destinations a visitor has already been to, thus simplifying the choice of which link to try next.

a:visited { color: purple; }

A common pitfall is that certain browsers need these pseudo-classes in a specific order so as not to have one pseudo-class override the styles of another. The safest pseudo-class order is :link, :visited, :hover, :focus and then :active:

a:link { color: blue; }
a:visited { color: purple; }
a:hover { color: magenta; }
a:focus { color: magenta; }
a:active { color: red; }

When we have an image on a web page and that image conveys content, then we know it is important to provide a text equivalent of the content that image offers. The most typical (but not only) way of doing this is to add the text equivalent content in an alt attribute on that image. The text content of this attribute should convey the equivalent information that the image contains.

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

The title attribute is one of the overlooked attributes in the HTML collection. It’s most often used to mark up abbreviations with their expanded forms. Sometimes it’s used to rout around Internet Explorer’s tooltip behaviour of image alt attributes.

The attribute itself is meant to supply optional supplementary information. The most beneficial example is in conjunction with the abbr element, providing the knowing user with an expansion of an abbreviation. A second practical example is using it with forms to provide additional relevant information. (We also looked at using titles with form fields.)

But there are many examples of a title attribute being used to provide the same information that’s already available and accessible. The most common example is links, especially in navigation you see the following piece of markup:

<a href="/sitemap/" title="Visit our sitemap">Sitemap</a>

Here the title attribute is just a plain duplication of the link text. Sure, it may have two extra words of Visit our which don’t appear elsewhere, but this explains what a link does, and is just as redundant and irrelevant to site visitors. Most of them would need to have understood what a hypertext link is and what it does before even arriving at your site. Its just not necessary.

The extra text is a variant of the click here problem, it explains about how to activate a text link rather than succinctly describing the destination.

Some users have their screenreaders configured to read out both the link text and the title attribute. In this case, the above link would read out “Sitemap visit our sitemap”, and either prefix that with the word “Link”, or switch to a different voice to indicate the presence of a link. The duplication slows down the reading of the page, and is an unnecessary hiccup.

There is very little benefit to the title attribute in this code example. It is better, accessibility wise, to just drop the title attribute altogether in this instance.

Creating barriers for screen magnifiers

Screen magnifiers have the tendancy to make all title attributes appear when they have a titled element within the view of the magnifier. Any title, be it on a div, or a header, or a paragraph or a link, will appear in a tooltip like fashion. A significant use of titles may distract a screen magnifier user, even prevent them from seeing a particular piece of content because it has been obstructed by a tooltip.

There’s just no positive accessibility benefit to using a title attribute to duplicate existing content. The title attribute. when it offers no extra value, hinders more than it helps.

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.

There have been various discussions in web development circles about whether we can skip heading levels for various reasons, including structural consistency.

Repurposing headers

One of the benefits of a proper and consistent heading structure in an HTML page is that they can be repurposed to improve access to the content. For example, the heading structure could be extracted into a Table of Contents or an outline, providing in-page navigation or overview.

Screenreader users have header navigation, which allows them to go through the document on a header by header basis. It’s not perfect, but its very useful to find a piece of information quickly. The screenreader exposes a means of navigation to next or previous headers of a particular level, so a visitor can, for example, jump to the next second-level heading. So far there’s no indication of what header levels are available unless the user enquires.

Barriers in skipping headers

This means that if heading levels are skipped they may not be found by a screen reader user. For example, if a screenreader user is navigating down the second level headings (h2), and finds one that comes close to what he’s looking for, he may elect to navigate through the third level headings(h3). If this level is skipped in the header structure, the user will be informed that there are no third level headings. Without third level headings, the expectation is that there will be no fourth, fifth or sixth level headings there either. So those headings will typically not be found by a screenreader user.

Skipping a header level makes navigating by headers less usable for screenreader users.

The typical websites of today commonly have small forms in various locations on the page. These forms could be logins, subscribing to mailing lists, site search, blog comment form; they are ubiquitous because they tend to cover important use cases on a site.

It makes sense to inform screenreader users of these forms - particularly login and search, because they form an important part of getting things done on the site, or navigating to a personalised part of the site.

For that reason, preface all of these forms with a header. This allows screenreader users to use headers as a way of navigating all the elements in the page. Make the header text descriptive, for example “Login to your account”, or “Search this site”. It would be better to integrate these headings as part of the design, but they can be hidden by positioning it off-left if needed.

It’s more natural for this heading is placed before the start of the form, outside the opening form tag. That way a screenreader user can find the relevant header in heading navigation mode, and when they switch back to the normal page navigation mode the first thing immediately after the header is the form.

Ensure that the heading level makes sense in the document structure, and don’t skip a heading level. Use an h2 header for forms that appear before the h1 header; there ideally should be only one h1 header per page.

Related info

• YouTube: Importance of HTML headings for accessibility: shows how useful headers can be as a way of navigating a page of content in a screenreader (JAWS), and the difference when headers are not marked up.

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.

Hiding content from view with visibility: hidden in many cases prevents the screenreader from reading the content, so content styled this way is inaccessible. This technique is not appropriate for hiding content on screen because no screenspace is saved by styling this way - the visitor is left looking at a blank region the size of the hidden content.

In a number of cases visibility: hidden is used in conjunction with positioning the content offscreen (position: absolute; left: -999em;). This is unnecessary since positioning content off the viewport is sufficient to hide the content, and the visibility: hidden makes the content unavailable to screen readers.

There’s no reason to use visibility: hidden. Positioning the content offscreen is safer and has far less accessibility implications. If you fee that visibility: hidden is appropriate for your requirements, I strongly recommend revisiting the requirement and finding an altogether different solution.

In websites offering news, it’s common for there to be a story title and an image both linking to the actual story. The design requirement, or even a tracking requirement, may force there to be two separate links, one for the story title, and one for the story image.

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.