Web Accessibility Gone Wild
Now even wilder!

Alt text blunders

Despite being rule #1 of web accessibility, missing and inappropriate implementation of alternative text is still the most problematic aspect of web accessibility. While at a technical level, adding alt text is dead simple, understanding the finer points of alternative text can be rather difficult.

Descriptive alt text

We continue to see images described in alternative text. Any time alternative text contains a description of an image, the alternative text is likely not optimal and is often just plain bad. Alternative text must convey the content and functionality of an image and should rarely be a description of the image. Rather than providing what the image looks like, alt text should convey what the content of the image is and what it does.

This misinterpretation results in things like, alt="bullet", alt="red arrow", alt="swirly line at the top of the footer", alt="blue corner with drop shadow", and other less than useless alternative texts. This is also evidenced in alt texts that contain file names (alt="logo.gif").

Going a step further, developers often convey the presence of an image through alt text:

It is not important that most images be identified as images. If it is absolutely vital that you identify the image as a painting or photo, then this should be part of alternative text, though this should be the exception, not the rule.

"Smiling lady" images

The web is full of decorative images. For accessibility purposes it is often hard to distinguish between images that are truly decorative and those that convey content. Many images are used to enhance content or to provide a mood or feel or design motif to the page. Often such images are incorrectly given alternative text.

Many of these types of images are actually more decorative than informative. Most screen reader users tend to agree that they don't really care much about the mood, feel, or aesthetics of a site - they want the important content without these extraneous bits of less important information.

This, however, becomes much more difficult when designers place great effort in strategically choosing and positioning images to convey something. Again, while it is ultimately up to the content author to determine if and how much alt text provides, our recommendation is to err on the side of minimalism, and most often, this means alt="" for these types of images

Linked images

Perhaps the fastest growing accessibility issue in recent years has been the alarming trend of linked images that are missing alternative text.

In the instance above, the image and the text below are separate links. The image in this case must be given alternative text. If an image is the only thing within a link or if it's a button, it must have adequate alternative text to provide users what the link or button will do if activated. This is true even if that alternative text is the same as adjacent text. In the example above (a representation of something very prevalent in online stores), the best solution is to simply combine the image and the text into one link and give the image empty alt text (alt="") because the text now adequately provides the alternative for the image AND the functionality of the link.

Additionally, because screen readers identify links, you do not need identify linked images and being links. In other words, avoid alt="Link to Apple Iphone".

Complex images

The content of complex images, such as charts and graphs, cannot always be adequately provided in alternative text. How long is too long for alternative text? If you were forced to listen to it in a screen reader and it becomes even slightly burdensome, it is too long. If that is not definitive enough for you, 100 characters is a good measure.

The longdesc attribute is intended to provide the URL of the long description page (e.g., longdesc="chartdata.html") and should not contain the actual long description (e.g., longdesc="This chart...").

Additionally, sometimes complex images are included, but the actual content of the image is rather simple. In these cases, don't beat yourself up providing the full long description containing all possible data points in an attempt to address accessibility. Simply providing a brief summary of the data in alternative text will likely be sufficient. In the example above, if you don't think the typical site visitor will care that sales in 2001 were 13 million, then why bother providing this data to them in text?

Accessibility options are are rarely a good solution

The above statement is certainly a generalization, but typically accessibility options and preferences (e.g., font resizing widgets, high contrast settings, etc.) indicate a poor or noncommited decision in the design process. If your default font size may be too small for site visitors, then make it an adequate size. If your contrast is insufficient, fix it. Accessibility options and preferences usually are in place to accommodate a weakness in the default accessibility of a site or indicate that the developer couldn't choose between options and instead forces that decision to be made by his site visitors.

Any time an accessibility option is provided, it may benefit one group of users but at the same time will disadvantage almost all other users. Font resizing options may be useful to those with low vision that do not have a screen enlarger or increased fonts already, but such options will make the page less accessible to everyone else. All browsers allow the sizing or scaling of the page content - why duplicate this browser functionality?

Until user agents...

They do.

The Web Content Accessibility Guidelines 1.0 provide several checkpoints that are only valid until user agents automatically do something to account for the issue being addressed by that checkpoint. In almost all cases, these checkpoints can be ignored. This includes checkpoints requiring default text in form fields (e.g., "Enter your name here"), placing non-linked printable characters between adjacent links, and providing redundant text links for image map hotspots.

Accessibility > Compliance

A common theme in the accessibility field is a belief that compliance with a set of guidelines means you are accessible. You can be fully Section 508 compliant, for example, yet totally inaccessible. Guidelines and standards, even the WCAG guidelines, should be used as tools, not as a true measure of accessibility. While guidelines might help us determine that a page is INACCESSIBLE, they cannot and never will be able to tell us if our page IS accessible.

We've seen many cases where guidelines (particularly Section 508) are taken so literally that accessibility suffers. We've seen it suggested that you can't provide a page that lists resource links without an option to skip over these "repetitive navigation links." And that you can't provide a Word or Excel document as an alterative to a web-based page or data table because you can't provide a link for users to freely get these programs. Nonsense! The goal of guidelines is to support accessibility, but when extremists focus more on compliance than on accessibility, accessibility is ultimately what suffers.

Accesskeys and tabindex

Don't use them.

They almost always result in decreased accessibility. Even when implemented properly (which is rare), they are typically used to account for poor design decisions. For instance, the natural navigation order is illogical, so tabindex is used to fix it. Or search is not prevalent within the page, so accesskey is implemented to provide quicker access to it. The benefits of accesskey and tabindex rarely outweigh the problems they introduce.

Hidden content for screen readers

WebAIM was perhaps the first to introduce a method of hiding content visually, but allowing it to be read by screen readers (content hidden with CSS's display:none or visibility:hidden is not read by most screen readers). Current implementation of these techniques, however, are now resulting in some disturbing trends.

Presenting content only to screen reader users should only be done when the additional content presented is already evident to sighted users. There are several standard design practices that result in very clear visual phenomena that may not be initially apparent to screen reader users who are accessing content in a linear manner. For instance, on this site, the search terms input box at the top of each page is clearly evident despite the fact that a visible label is not provided. The adjacent "Search" button acts as a visual label for it. In this case, a hidden label is provided that indicates the functionality of the text box. The breadcrumbs at the top of the page are a design element that are typically well known because of their overall visual presentation, something not available to screen reader users. In this case, we have added hidden "You are here:" text immediately before the breadcrumbs to cue screen reader users as to what is coming next. Finally, the Google advertisements at the bottom of each page are evident as being ads to sighted users. For screen reader users, we identify the beginning of the ad block.

Hidden text for screen reader users should not be used to provide features or content that may be useful to other users not using screen readers. As is mentioned above, when content or functionality is provided for one particular group of users, it typically decreases accessibility for other users.

Gratuitous skip navigation links

One of them is almost always sufficient.

Some sites have taken the approach that if one skip link is good, then 5 is even better. Providing a solid document heading structure is much more effective for page navigation than providing multiple links at the top of the page. Multiple skip links are usually an attempt to provide quick access to elements of an overly complex page. Having more than one 'skip' link also introduces overhead and additional navigation actions for all keyboard users. At what point do the 'skip' links become repetitive and would justify a 'skip the skip links' link? (The previous question was entirely sarcastic. It is not suggested that this would be necessary - though we have actually seen one of these 'skip the skip links' implemented.)

Skip navigation (by the way, we would recommend "Skip to main content" as this describes where the link goes to, not what it skips over) links are useful to all keyboard users, not just those that are blind. As such, they should be made visible within the page, or at a minimum, be made visible when the link receives keyboard focus.

Fixing screen reader deficiencies

Screen readers generally suck. While very powerful technologies, they suffer from bugs, inconsistencies, and sometimes illogical oddness. This is particularly evident in the way some text and page elements are read. For instance, WebAIM's host institution is Utah State University or USU. USU is read by most screen readers as "oosoo." Some developers, when encountering such screen reader oddities will make attempts to rectify these issues by methods such as replacing the text USU with an image that has alt text of "You Ess You."

For the most part, you should ignore such deficiencies in screen readers and focus on how accessibility SHOULD be provided. Screen readers are improving all the time - it is not the developers job to account for their current weaknesses.

Improperly associated form details

Do you know what the previous form elements are for? Probably not. When the purpose of groups of radio button or checkbox are not apparent from the labels themselves, then a fieldset and legend are necessary.

Because screen readers will read the legend before every form element within the fieldset, the legend should be succinct and accurate.

Screen readers usually utilize a "forms mode" when completing web forms. When in forms mode, only form elements and their properly associated labels are identified when the user navigates through the form. As such, any instructions and cues that are not part of a form label or a fieldset legend are not likely to be read.

Be sure to put vital form instructions and cues such as indications of required form fields, data formatting requirements, etc. either before the form, within a form element label, or in a fieldset legend.

Title attribute

The title attribute, by definition, can be used to provide advisory information. It should:

• NOT provide vital information or information necessary for accessibility.
• NOT provide the same information as is available in text or alternative text.
• NOT present the obvious. If the advisory title does not provide additional, useful information, it can be removed.
• BE used carefully on small links and navigation items because the title tooltip may cover the underlying item.
• NOT be used as a replacement for alternative text, form labels, table headers, etc.
• ALWAYS be used on the frame element (e.g., <frame title="navigation">)

The title attribute is not read for most elements by default in most screen readers. Exceptions are the frame element and form elements that do not have a label. When a form element does not have a label, but does have a title, the title will typically be read. This approach, however, is often a misuse of title - if the title attribute is necessary to ensure accessibility of the form element, then it is certainly contains more than simply advisory information. A better approach is to insert an associated form label, and if necessary, that label can be hidden with CSS.

Layout tables

As long as they do not introduce an illogical or unnatural reading/navigation order, layout tables have virtually no impact on accessibility. While there are many reasons why layout tables are not optimal, accessibility is not one of them.

Table summaries (<table summary="....") should not be used on layout tables. Because summary may be displayed as a browser tooltip, this may cause confusion for sighted users. Imagine placing your mouse on a navigation item that is positioned in a layout table and seeing a tooltip of "table used to layout the navigation items."

Invisible link focus

As documented before, do not style links with outline:0. It makes the focus indicator, the dashed lines or 'marching ants' that surround focused links and buttons, invisible.

Noncompliant HTML != Inaccessible

Some time ago I received an anonymous e-mail from a site visitor that said, "I can't believe that you claim to care about accessibility and present yourselves as accessibility experts when your page doesn't even pass the W3C validator!" He did not, ironically, indicate WHICH page didn't validate (if you find it, let me know).

While anyone that is passionate about accessibility should advocate standards compliant code and while proper code supports accessibility, there are many pages that have very broken, non-compliant HTML that are totally accessible. On the flipside, I'm sure there are XHTML compliant pages that are very inaccessible (though these are much harder to come by).

Accessibility statements and compliance badges

We don't need no stinkin' badges!

Unless there is a legal reason for identifying your site's level of accessibility or compliance with guidelines, standards, and tools, there is little usefulness in adding accessibility statements and badges (e.g., W3C, Bobby (rest in peace), Section 508, etc., icons or symbols) to your web site. While developers may take pride in their compliance and may want to evangelize standards and tools, doing so on every page of a web site introduces unnecessary complexity and overhead. Of course, if your typical site visitor knows what "W3C WAI-AAA WCAG 1.0" means, then page complexity may be the least of your worries. :-)