Indiana University: IT Training Tips Blog

This entry in the “Web Accessibility Made Easy” series explains expanding abbreviations and acronyms so that, for instance, all users know that ARIA means Accessible Rich Internet Applications and not Automated Robot Integration Assembly.

ABBR and ACRONYM Tags

When web designers use the <abbr> or the <acronym> HTML tags, abbreviations and acronyms will be read as their full text. However, this is only true if the user has set their screen-reading software to do this. Web designers need to set the title attribute of the <abbr> or <acronym> tags to the actual meaning of the phrase. See code example below.

Example:

<acronym title="Web Content Accessibility Guidelines">WCAG</acronym>

Using this method a web designer complies with the guideline below. However, as mentioned above this coding only provides the desired result if the screen reader user has set their preference (settings) to automatically voice the entire text of the acronym or abbreviation tags. Therefore, as is common writing practice, it is important that for the first use of a phrase which will subsequently be represented by an acronym or abbreviation, that the phrase be entirely spelled out and followed by the desired acronym or abbreviation in parenthesis (e.g., World Wide Web (WWW). For subsequent uses the acronym or abbreviation tag should be used. Then, for screen reader users who have set their preferences correctly, the entire phrase will be spoken.

Guideline

IU Web Accessibility Guidelines

2. Specify the expansion of abbreviations or acronyms where they first occur in a document.

This guideline requires that the first time an abbreviation is used, it is expanded. Common writing practice is that the first time a name or phrase is used for which an acronym will be used later, the words should be spelled out followed by the acronym in parenthesis. Web coding should employ this same practice. After the first instance, it is up to the web designer to decide whether to continue to use the <abbr> or <acronym> tags to expand the phrase.

Tutorial

This tutorial will again be using the Bad example web page, Good example web page, their associated stylesheets and Dreamweaver.

1. The Bad Code – Acronyms not Expanded

<p>Web accessibility standards have been developed by the W3C (http://www.w3c.org)</p>

The code shown above will validate to the W3C standards. However, since this is the first instance of an acronym, it needs to be expanded.

2. The Good Code - Acronyms Expanded

Example 1…First Instance of the use of a phrase for which an acronym will subsequently be used:

<p>Web accessibility standards have been developed by the World Wide Web Consortium (W3C), http://www.w3c.org.</p>

Example 2….Use of the acronym tag for the second and all subsequent uses of the acronym:

<p>Web accessibility standards have been developed by the <acronym title= “World Wide Web Consortium” >W3C</acronym> (http://www.w3c.org)</p>

Simply expanding the acronym physically in the text (example 1) or using the <acronym> tag in conjunction with the “title” attribute to expand the acronym (example 2) is all that needs to be changed to have the acronym display correctly to all users.

3. All users will know understand the acronym

That is it. Because the acronym has been expanded once, if a user cannot remember what it means they can refer back to the original expansion. Using the <abbr> or <acronym> tag is also beneficial because it can be used over and over again with minimal interruption to the visual design.

Wrap Up

Expanding abbreviations and acronyms not only helps users of assistive technology, it is beneficial to all users. With each new day in this age of the internet and text messaging, new acronyms and abbreviations are emerging. There are even online dictionaries of acronyms and abbreviations. So it is very important that web coders follow the suggestion above regarding the use of acronyms and abbreviations! Physically expanding abbreviations or using the <acronym> tag to expand an acronym adds very little time to the design and coding of a website. However, this practice contributes dramatically to the understanding of a web page.

This entry in the “Web Accessibility Made Easy” series discusses two guidelines that are essential to well-formatted layout and design of data tables.

Tables on the web have been around since the early days of the web. Okay…not the early, early days of the web, but tables were first discussed in 1996 (IETF RFC 1942) and then later included in the HTML 3.2 specification. This specification ensured that tables were the formalized way to display data from a spreadsheet or database.
(more...)

This is one of the easiest web accessibility guidelines to implement. Though this is easy to code, creating a proper alt tag is not always the easiest thing to do. (And yes, technically the Alt tag is actually an attribute of an element, but the more common phrase will be used here.)

Alt tag basics

The Alternative tag, commonly referred to as the “alt” tag, is an attribute of the image tag ("img") in HTML. Alt tags are read by most browsers. They provide an alternative text description for images or other elements so that those using screen readers have access to information conveyed by graphics. Also, if the image doesn’t load or only loads partially, the alt tag provides information conveyed by the graphic.

(more...)

A number of laws have established precedence in issues of web accessibility. These laws continue to evolve and face legal challenges to establish benchmarks of web accessibility. Some laws related to web and information accessibility apply to just web sites and publications of the federal government. Others apply more broadly. Below are portions of the laws that may apply to web accessibility and higher education.
(more...)

This is the first in a series of posts about web accessibility that will give an in-depth look at the topic, using IU’s guidelines, as well as the web accessibility standards documents from which they were derived. Through these posts you can learn correct and easy ways to make your websites accessible so that they can be used by everyone.

Web Accessibility Myths:

1. The BIG one: Making a website accessible is a long, involved and costly process.

This is half-true. If your current web site is not accessible, it can be a lengthy process to make it accessible. But, if from the beginning, your web development work incorporates the techniques described in these blog posts, creating an accessible web site will add little time to the design process.

2. Web accessibility can be validated with an automated process just like HTML.

This is also half-true. Many web accessibility guidelines can be tested using automated validators. But this does not tell the whole story. For example, just because an image on a web page has an “alt” tag does not mean that the tag provides helpful, relevant information. Keep in mind that retroactive fixes to an inaccessible web site will take extra time. Including web accessibility in the design from the beginning will take no time at all. And a site that is accessible is will be more usable for everyone.

3. No one with a disability uses or visits my site

While this could be true, there is no way of verifying this statement. For one thing if an individual with a disability cannot successfully use a web site, they will quickly seek alternative web sites. The major disabilities are impairment of hearing, seeing, thinking (cognitive), and mobility. Some disabilities are visible, some are hidden. Some are permanent, some are temporary. 18.7% or 54.4 million people in the US report some sort of disability (US Census Bureau [pdf]). With these statistics in mind, it is fair to conclude that someone with a disability has or will try to view your site.

4. A text-only version of your web site is a great accessible alternative.

Does reading the book that a movie was based on give the same experience? Probably not. A text-only version is accessible and does meet some of the guidelines, yet the experience is not the same. And more importantly, while you may remember to update your web site with current information, maintenance of a current text-only version is often forgotten, creating unequal information access. Today most assistive technology programs today work with CSS, can access Flash movies and can deal with JavaScript. As a result, users with disabilities can access content that is correctly coded. So why limit them to a text-based version of your site?