Consistency

In spite of the importance of consistency for navigation and presentation, not all Web sites on the internet have a consistent navigational structure or presentation. This can be a severe disadvantage for users with physical or cognitive disabilities. For those with cognitive disabilities, remembering the location of links or sections of a Web can be very taxing. If these locations change from page to page, the extra cognitive processing required to relocate links or web page sections may inhibit users from task completion. Similarly, people with other impairments (fine motor, vision, or dexterity issues) may find it physically exhausting if links constantly change position on a Web page.

Consistency also benefits those without disabilities. Because of the vast array of information available on the Internet and the wide variety of Web site design methods, the cognitive load on people without disabilities is great. If the navigation and presentation remain the same throughout a Web site, the cognitive load is lessened for all users and the time it takes for users to locate their desired content is significantly reduced. Consistent navigation and presentation, also known as user interface, is a big topic in the world of usability. Renowned usability expert Jakob Nielsen has written a book on this topic, Coordinating User Interfaces for Consistency (http://www.useit.com/jakob/constbook.html). With the advent of templates and content management systems, consistent navigation and presentation is becoming easier to maintain and more prolific throughout the Internet.

The Guideline

IU Web Accessibility guideline

4. Presentation and navigation style shall remain consistent throughout the document.

Wrap Up

Maintaining consistent navigation and presentation is not hard to do and is beneficial for both users with and without disabilities. It provides better usability and efficient navigation for all users. Take steps to help improve user experiences by ensuring all navigation and presentation of content on your Web site is consistent.

Lists

HTML lists are an accepted way to outline or organize information into related groups on a Web page. Lists are a particularly helpful means of organizing navigation links. There are three list sub-types: unordered, ordered and definition. Unordered lists, which are proceeded by a bullet, may be the most common type of list. Ordered lists are more commonly recognized as numbered lists.  Definition lists are a special list type, created to order and organize term/definition pair sets.  Below are examples of each type of HTML list. For more information on HTML lists, please consult the W3C HTML 4 List page.

Unordered:

• Fred
• Joe
• Johnny

Ordered:

1. Joe
2. Fred
3. Johnny

Definition:

Sesquipedalian

Given to using long words.

Hortatory

Marked by strong urging; serving to encourage or incite

Note: The Definition list has been faked above because the HTML definition list element is not recognized by WordPress.

Lists, whether unordered, ordered or definition, need to have opening and closing tags to be valid HTML lists and render correctly to user agents including internet browsers and screen-reading software.

Code Example:

<ul>
<li>Fred</li>
<li>Joe</li>
<li>Johnny</li>
</ul>

Many developers create fake lists using images and CSS style rules to create the visual appearance of a list.  This creates navigation roadblocks for screen-reader users, especially if there are multiple lists coded in the same manner.   However, with correctly coded lists, screen-reader users can jump from list to list using keyboard shortcuts for easy navigation. In addition, screen-reading software announces how many items are in each list and if nested lists are present, allowing screen-reader users to understand the hierarchical structure of the list.  For these reasons and many others, lists should always be properly coded, after which, the developer can use CSS style rules to control their visual appearance.

Guideline

IU Web Accessibility Guidelines

18. Mark up lists and nested lists properly.

Tutorial

This tutorial will be using both the Bad example web page and the  Good example web page, along with their associated style sheets.

1.   The bad code – Fake lists coded with images and CSS.

In the code below there is no actual list; the list is faked.  To a screen-reader user, each bullet of this fake list would be read out, “img/bullet,” which would get annoying to any person.  Instead of using <img> tags, the developer should have created a HTML list and used CSS style rules to change the bullet to an image.

<img src="img/bullet.jpg" width="7" height="7" />Learn about the federal statues<br />
<img src="img/bullet.jpg" width="7" height="7" class="float-left" />Research free and commercial tools that can aid you<br />
<img src="img/bullet.jpg" width="7" height="7" class="float-left" />Participate web accessibility training<br />
<img src="img/bullet.jpg" width="7" height="7" class="float-left" />Design the web site according to the standards provided<br />

2.   Create correctly coded HTML lists.

Add the opening and closing tags <ul> and </ul>. Then, replace the <img> and <br/> tags with <li> and </li> tags.  The CSS style declaration below changes the bullet into the chosen image.

<ul class=“cbullet”>
<li> Learn about the federal statues </li>
<li> Research free and commercial tools that can aid you </li>
<li> Participate web accessibility training </li>
<li> Design the web site according to the standards provided </li>
</ul>

CSS Style declaration:

.cbullet ul {

list-style-image: url(img/bullet.jpg);

}

Note: Having an image as a bullet does not affect how screen-reading software announces the list items.

Wrap Up

Properly coding all lists is an easy way to improve the accessibility and navigability of a Web site without impacting the visual design.  Properly coded HTML lists are particularly important for screen-reader users.  In addition, coding lists items properly helps web pages to validate and ensures the Web page renders accurately in any Web browsing software.

Cascading Style Sheets

Use Cascading Style Sheets (CSS) to add consistent styling to Web pages. CSS rules separate document presentation elements (color, fonts, spacing, layout, headings, etc.) from document content (written in HTML or a similar markup language). Separation of content and presentation does the following:

• Improves content accessibility
• Improves flexibility and control for specification of presentation characteristics
• Enables multiple pages to share formatting
• Reduces complexity and repetition in the structural content though web design that does not rely on tables. (W3C & Wikipedia)

Modern Browsers (Firefox, Opera, and Internet Explorer) allow users to substitute their own custom style sheets that render Web pages in a more accessible format for that user. Without the use of Cascading Style Sheets this is not possible because inline and embedded styles override external style sheets added by the user. The images below show an example of a user modified style sheet created to improve the visual accessibility of the Web page to meet their particular needs.

Normal View as set by CSS

High Contrast view (White on Black)

It is important to note, not all CSS style rules improve accessibility. If important content is added to a Web page by using CSS instead of through the underlying code, when Cascading Style Sheets are disabled or they are substituted to accommodate personal preference or adaptive technology, the content added with CSS might not be accessible to the user.

Good example with style sheets turned off

Below is the Web page used in the examples above. In this instance, the Cascading Style Sheets have been disabled. Cascading Style Sheets have been used correctly because all the information available with the Cascading Style Sheets enabled is available when Cascading Style Sheets are disabled. In addition, new content is visible that was initially hidden by the CSS. This hidden content aids users of adaptive technology with page navigation. It was hidden so that it would not disrupt the visual layout, but still be useful.

Bad example with style sheets turned off

CSS has not been used appropriately in the Web page below. Using CSS, the header image and contact information were coded as background images of an HTML division element (<div>). Neither the header image nor contact information appears when the Cascading Style Sheets are removed.

Guideline

IU Web Accessibility Guidelines

4. Presentation and navigation style shall remain consistent throughout the document.

12. Documents shall be organized so they are readable without requiring an associated style sheet.

16. Use style sheets to control layout and presentation.

Tutorial

This tutorial demonstrates Cascading Style Sheet coding for both the bad example Web page and the good example Web page.

1. Bad Code – Important content is coded as a CSS background image.

   To display the header image, the code below uses an HTML <div> element with a background image coded using CSS encapsulated in an HTML link element (<a>). The CSS style rule is linked to the <div> element’s id attribute, “headerimg”. Normally, there is no accessibility issue when using CSS background images. But in this case, the header image is the main heading on the page. Therefore, its content should be accessible to adaptive technology through the alternative text attribute. Unfortunately, alternative text can only be added to hard coded images not CSS background images. The CSS style rule is found in the screen.css file or below:

<div id="header">
  <a href="Bad.html"><div id="headerimg"></div></a>
</div>

CSS code

#headerimg {
  background-image:url(../img/Header.jpg);
  width:552px;
  height:150px;
  margin-left: 15.5em;
}

2. Good Code – The CSS background image is hard coded as an image with alternative text in a HTML heading element

   The header image and parent link element act as the main heading for the page and therefore should be encapsulated a HTML heading element. HTML heading level 1 (<h1>) opening and closing elements are added around the entire link element, which encompasses the HTML <div> element and header image. The HTML heading level 1 element was chosen because the image describes the main topic of the Web page, “Indiana University Web Accessibility Class.”

<div id="header">
  <h1>
    <a href="Good2.html"><div id="headerimg"></div></a>
  </h1>
</div>

As stated above, because the image is now part of a heading it should be coded as an image with alternative text, instead of a CSS background image. If no alternative text is present, the heading and link will appear empty to adaptive technology. The HTML <div> element is changed to an HTML <img> element. The image should have its height and width specified in the source code instead of in the CSS style rule to ensure the page layout does not expand when the image is loaded. Finally, a new CSS style rule is added to the image to reposition it in the center of the parent HTML <div> element.

<div id="header">
  <h1>
    <img src="img/Header.jpg" width="552" height="150"
    alt="Indiana University Web Accessibility Class" />
  </h1>
</div>

CSS code

.thrColElsHdr #header img {
  margin: auto;
}

Wrap Up

Properly using CSS can increase accessibility. However, when improperly used, CSS can adversely affect accessibility for those who use adaptive technology to access the web or who need to modify web pages to fit their specific accessibility needs. Remember, CSS creates the most accessible Web pages when used to style content that already exists in the underlying code. Therefore, a good rule of thumb is to create page content first and then use CSS to style it for presentation on the Web page. By following this rule, no matter what style is used, the content will be accessible to all users of assistive technology. In future blog posts more advanced CSS techniques will be discussed.

]]> http://ittrainingtips.iu.edu/accessibility/web-accessibility-made-easy-cascading-style-sheet-basics/05/2011/feed 0 http://ittrainingtips.iu.edu/xhtml/web-accessibility-made-easy-tab-order/01/2011 http://ittrainingtips.iu.edu/xhtml/web-accessibility-made-easy-tab-order/01/2011#comments Wed, 05 Jan 2011 20:32:01 +0000 ATAC Web Accessibility Team http://ittrainingtips.iu.edu/?p=1642 This entry in the “Web Accessibility Made Easy” series discusses an HTML attribute many web developers may overlook… tab order.

Tab order and tabindex

Tab order or “tabbing order”, “defines the order in which (HTML) elements will receive focus when navigated by the user via the keyboard.” (Tabbing navigation, W3C) All elements that by specification or scripting can receive focus will be present in the tab order. The tab order works with the following elements among others…. <a>, <area>, <button>, <input>, <object>, <select>, and <textarea> HTML elements. Normally, the tab order is determined by the order of elements in the HTML source code. The tab order may follow an unexpected order because of the way the web page is coded. Below is an example of an illogical tab order. The example shows the layout of an HTML form with elements that would be formatted in a two column layout with CSS.

Form

First Name                  Email
Last Name                   Confirm Email

If viewing the source code for the form elements above, it seems like they should appear in this order: first name, email, last name and confirm email. This order could easily confuse someone with a cognitive disability or someone using screen-reading software. They would expect the last name field to come after the first name field because these two pieces of information (data) are closely associated. On an extremely long form or a form with more than two columns of form elements the illogical tab order would be even more evident.

The tab index attribute can correct an illogical tab order. The tab index attribute, “specifies the position of the current element in the tabbing order for the current document. This value must be a number between 0 and 32767.” (Tabbing navigation, W3C) Use of the tab index attribute enables tabbing to elements in the correct sequence based on the value provided in the attribute(s), beginning with the smallest value and ending with the largest value.

It should be noted that all elements with tab index attributes are accessed prior to page elements without tab index attributes. So tab order consists first of all page elements with tab index attributes followed by all elements without tab index attributes. This may result in illogical tab order. Tab index attributes may need to be added to all focusable HTML elements to create consistent, logical document wide tab order. Therefore, if the tab order appears logical to users without including the tabindex attribute, it is best to omit the attribute all together.

Guideline

IU Web Accessibility Guidelines

19.    Be sure tabbing through links, form controls, and objects occurs in a logical order (sequence).

Tutorial

This tutorial will be using both the Bad example web page and the Good example web page, along with their associated style sheets.

1.      The bad code – illogical tab order

The code below has four form field elements, which are styled using CSS to control their layout. The problem is the email field comes before the last name field, so the tab order will be: first name, email, last name, confirm email.

<div class="formfield">
<input name="FName"/>
<font color="#FF0000">First Name</font>
</div>
<div>
<input name="Email"/>
<font color="#FF0000">Email</font>
</div>
<div>
<input name="LName"/>
<font color="#FF0000">Last Name</font>
</div>
<div>
<input name="Email2"/>
<font color="#FF0000">Confirm Email</font>
</div>

2.      Adding the tab index attribute to each of the form elements to correct the tab order.

The tab index attribute is added to each form element in the code below. Because this form is not the only content on the example page, a tabindex attribute of 1 is not used. Instead, the tabindex attributes begin with a value of 100. The higher tabindex attribute allows the developer to add tabindex attributes to other focusable HTML elements, preserving a logical tab order. These elements may precede the form in the source code.

<div class="formfield">
<input name="FName" tabindex="100" />
<font color="#FF0000">First Name</font>
</div>
<div>
<input name="Email" tabindex="300" />
<font color="#FF0000">Email</font>
</div>
<div>
<input name="LName" tabindex="200" />
<font color="#FF0000">Last Name</font>
</div>
<div>
<input name="Email2"  onblur="validateemail();" tabindex="400" />
<font color="#FF0000">Confirm Email</font>
</div>

Note: To ensure a logical tab order on the Good example web page, tabindex attributes should be added to all other <a>, <select>, <input>, <textfield> and <button> HTML elements.

Wrap Up

To ensure web pages have a logical tab order, use the tabindex attribute to control tab order. Logical tab order is important for people with and without disabilities because most people find it is very convenient to use tabbing navigation when filling out online forms. The next time you are filling out an online form, pay close attention to the tab order and the use of tabbing navigation. You will realize just how important tab order really is.

]]> http://ittrainingtips.iu.edu/xhtml/web-accessibility-made-easy-tab-order/01/2011/feed 0 http://ittrainingtips.iu.edu/xhtml/web-accessibility-made-easy-form-labels/01/2011 http://ittrainingtips.iu.edu/xhtml/web-accessibility-made-easy-form-labels/01/2011#comments Wed, 05 Jan 2011 19:28:35 +0000 ATAC Web Accessibility Team http://ittrainingtips.iu.edu/?p=1652 This entry in the “Web Accessibility Made Easy” series will discuss explicitly associating a label with a form control.

Label Elements

The <label> element is an HTML element that defines a label for a specific control on a form.  There are two different ways to use label elements to associate a form control with a meaningful, control specific label. The first way is to associate the label element’s “for” attribute with the corresponding “id” attribute of the form control.  The second way is to give the form control a title attribute, using the label description as the title.

Associating labels with form controls is essential to screen-reader users. Without explicit labeling of form controls, these users would have to guess what kind of information should be entered in each form control. Because by HTML specification label elements associate physical text with form controls, the associated label is always visually displayed. This may interrupt the flow and layout of the Web page.  However, Web developers can use a CSS style, like the one below, to hide content and keep it from being displayed visually on a page.  Although hidden content is not visually displayed, it is accessible to adaptive technology and keyboard-only users. Using the second method mentioned above, a Web developer can also explicitly label a form control, but not include physical text. This method is not recommended, but is useful for specialized form controls such as search fields. An easy way to check that all form controls have explicit labels is to use a tool like the Firefox Web Accessibility Extension from the University of Illinois Urbana-Champaign.  This tool allows Web developers to quickly identify which form controls are labeled and which are not.   Another way to do this is to look at the source code and verify each form control has and associated <label> element or a title attribute.

CSS Style to hide content

.auraltext {

position: absolute;
left:-9999px;
top:auto;
width:1px;
height:1px;
overflow:hidden;
}

.auraltext:focus {

position:static;
color:#000000;
width:auto;
height:auto;
outline: thin dotted black;
}

Guideline

IU Web Accessibility Guidelines

20. Associate labels explicitly with their form controls through positioning, coding or both.

Tutorial

This tutorial will use both the Bad example web page and the  Good example web page, along with their associated style sheets

1.      Bad code – No explicit label for the form control.

The code below has a form control that is styled using CSS to control its layout. The problem is that because the text label for the  control appears after the <input> element, screen-reading software does not correctly associate label with the form control.  Also, depending on the placement of the form control, screen-reading software may associate the text in front of the form control as the label for that form control.  If a paragraph of text were to come before the form control, this could become very confusing for a screen-reader user.

<div class="formcontrol">
<input name="FName"/>
<font color="#FF0000">First Name</font>
</div>

2.      Position the text label before the form control.

To make the form easier to read for all users, the form control label “First Name” has been moved to the left side of the form control from the right side. Because this is a text input form control there is no reason, aside from design choice, to position the label after the form control.  However, if it were a radio button or checkbox, the convention is for the label to appear after the radio button or checkbox.

<div class="formcontrol”>
<font color="#FF0000">First Name</font>
<input type="text" />
</div>

3.       Remove and replace deprecated HTML elements.

Next, to make the code XHTML compliant the deprecated font element has been replaced with a <span> element and a CSS style. Removing deprecated elements helps to ensure a Web page validates to the selected standards.

<div class="formcontrol">
<span class="red">First Name</span>
<input name="FName" />
</div>

4.      Add the <label> element to the form control.

The <label> element is then added.  The “for” attribute of the <label> element is used to explicitly associate the label with the form control by way of the input element’s “id” attribute.

<div class="formcontrol">
<label for="FName"><span>First Name</span></label>
<input name="FName" />
</div>

5.     Associate the label element with the input element.

Since the “id” attribute was not originally included in the input element, it must be added. The “for” attribute of the <label> element and “id” attribute of the <input> element must match exactly. Following these steps will ensure the form control is explicitly associated with the text label.  To make the rest of the forms on the web site accessible, <label> elements should be added, using the same techniques, to all the other form control.

<div class="formcontrol">
<label for="FName"><span>First Name</span></label>
<input name="FName" />
</div>

Alternative Label technique:

The example below uses the title attribute technique to explicitly label a form control.  In the example there is a search field and search button.  The title attribute is added to the text input form control, the submit input form type automatically uses the value attribute as the label.

<div id="search_container”>
<input title="search form control" />&nbsp;&nbsp;
<input value="Go" />
</div>

Wrap Up

Explicitly labeling form controls ensures that users of adaptive technology can accurately identify which information is supposed to be entered into each form control.  Rather than retrofitting a Web site so all forms are labeled, it is more expedient to incorporate form labels into the Web development work flow. Following this practice will add minimal time to Web site development, but will greatly  increase accessibility and usability.

]]> http://ittrainingtips.iu.edu/xhtml/web-accessibility-made-easy-form-labels/01/2011/feed 0 http://ittrainingtips.iu.edu/xhtml/web-accessibility-made-easy-primary-language/12/2010 http://ittrainingtips.iu.edu/xhtml/web-accessibility-made-easy-primary-language/12/2010#comments Thu, 02 Dec 2010 18:57:12 +0000 ATAC Web Accessibility Team http://ittrainingtips.iu.edu/?p=1236 This entry in the “Web Accessibility Made Easy” series will discuss setting the primary language of a web page and how to deal with language changes.

Language Attribute

The Language attribute of HTML, lang=”fr”, identifies the language of the document to user agents (browsers, search engines, assistive technology), in this case to French. Including the language attribute in the <html > tag at the beginning of a document sets the primary language for the entire document.  If the document will adhere to the XHTML specification, the xml:lang=”fr” language attribute should also be included. The xml:lang attribute is the standard way to identify language information in XML. Subsequent use of the language attribute changes the primary language to a different language, but only for that HTML element.  Language reverts back to the primary language at the end of the element.  

The syntax consists of primary code followed by an optional dash and subcode:

lang=”primary code (“-” subcode) “

Sample Language codes:

lang=”fr” : French.
lang=”en-US” : The U.S. version of English.
lang=”en-cockney” : the Cockney version of English.
lang=”i-navajo” : the Navajo language spoken by some Native Americans.
lang=”x-klingon” : The primary tag “x” indicates an experimental language tag (W3C)

Two-letter primary codes are reserved for language abbreviations that adhere to the [ISO639] standard. Likewise, any two-letter optional sub code should adhere to the [ISO3166] standard.

Guideline

IU Web Accessibility Guidelines

1. Clearly identify the primary natural language of the document and any instances when that language changes to another language including instances of text equivalents.

This guideline requires that in every document the language attribute is used in the <html> tag to  specify the primary language.  The guideline also stipulates that any subsequent changes of language be specified.  This allows for proper rendering of the text for all user agents including screen-reading software.

Tutorial

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

1.  Viewing the bad code – missing language attribute

The code shown below does not contain any language attributes to indicate primary language. Therefore, screen-reading software will attempt to speak the German text in the example as English assuming the default language for the screen reader has been set to English.  When the primary language is not specified, user agents – in this case screen-reading software – default to the primary language for which they have been configured, in this example English. This results in mispronunciation of any language other than English.  If web pages are coded to correctly to indicate primary and secondary languages, screen-reading software can be set to automatically switch to the appropriate language by the screen-reader user.

<html xmlns=”http://www.w3.org/1999/xhtml”>

<p>Netz-Zug&auml;nglichkeit ist wichtig, weil sie nicht nur jene Leute mit Unfähigkeit fördert. Sie hilft auch, die Web site allgemeinhin zugänglich zu bilden, indem sie Tastaturzugang, Lärmkontrollen, Aufflackernkontrollen und viel anderen Nutzen bewilligen.</p>

2.   Adding the Language attribute to the <html> tag and to subsequent HTML elements

To indicate primary language for a web page, add the Language attribute to the <html> tag as in the example below.

<html xmlns=”http://www.w3.org/1999/xhtml” lang=”en-US” xml:lang=”en-US”>

Simply adding both the HTML and XML language attributes to the <html> tag specifies the primary language for the entire document. All user agents should render the page content in the correct language as long as there are no changes from the primary language to another language. Adding the language attribute to subsequent HTML elements will accommodate language changes within the rest of document.

<div lang=”de”>
<p>Netz-Zug&auml;nglichkeit ist wichtig, weil sie nicht nur jene Leute mit Unf&auml;higkeit f&ouml;rdert. Sie hilft auch, die Web site allgemeinhin zug&auml;nglich zu bilden, indem sie Tastaturzugang, L&auml;rmkontrollen, Aufflackernkontrollen und viel anderen Nutzen bewilligen.</p>
</div>

The language attribute can be added to most HTML elements  including  <p>, <span>, <div>, <label>.  An important exception to this rule … the <body> tag.  Instead of including the language attribute in the body tag, it should be included in the <html> tag, as discussed above, to specify primary language for a document.  Adding the language attribute to the <div> tag in the  example above renders only the text in this HTML element in German for all user agents.

Wrap Up

Identifying the primary language is not only beneficial to users of adaptive technology; it is beneficial to all users. The language attribute helps to ensure that languages render correctly in any web browser. Additionally, search engines recognize the language attribute, which can help sort search results by language. Multiple language changes are supported without issue when the language attribute is used.  Using the language attribute adds little extra time to the development of a page. However, it makes a  big difference to users of adaptive technology, particularly for those who use  screen-reading software.

]]> http://ittrainingtips.iu.edu/xhtml/web-accessibility-made-easy-primary-language/12/2010/feed 1 http://ittrainingtips.iu.edu/xhtml/web-accessibility-made-easy-headings/10/2010 http://ittrainingtips.iu.edu/xhtml/web-accessibility-made-easy-headings/10/2010#comments Fri, 15 Oct 2010 16:47:10 +0000 ATAC Web Accessibility Team http://ittrainingtips.iu.edu/?p=1343 This entry in the “Web Accessibility Made Easy” series addresses the use of headings to add structure to the content of Web pages.

Headings

HTML headings have been part of the structure of an HTML document from the beginning.  The heading tags <H1> through <H6> are meant to give web documents structure. Therefore, headings should be properly nested to assign level of importance in the structure of the Web page.  Main topics of a Web page should be represented by <h1> tags.  Sub-topics should be represented by <h2> tags indicating a second level of importance in the structure of the document. The remaining <h> tags three through 6 are used to denote additional topics in descending order of importance.  Each level of HTML headings (<h1>-<h6>) has inherent CSS style rules applied by individual Web browsing software and which control the font size, font weight, padding and margins for each heading element.  Appearance of headings controlled by the inherent browser CSS can be over-ridden by CSS styles chosen by the Web developer.   This enables creation of web sites with specific design to the taste of the Web designer and the purpose of the Web site. However, a Web developer can add CSS style rules to heading tags so these headings fit his or her visual design.

Screen-reader users can discover document structure by creating lists of all the headings of each page of the Web site. The list of headings also enables screen-reader users to navigate around the Web page by selecting headings for topics in which they are interested. Screen-reader users commonly use keyboard commands to accomplish quick movement through a web site to desired content.

Guideline

IU Web Accessibility Guidelines

17.  Use heading elements to convey document structure and use them according to specification.

Tutorial

This tutorial illustrates both the right and wrong way to use headings on Web pages. To do this, the bad example Web page, the good example Web page, along with their associated style sheets will be used.

1.  The bad code – faking headings using visual styling

The code below is used to make the font of the text bigger and appear  to be  a heading to individuals who are can see. But coded in this manner, the document is given no structure and those visiting the page with screen readers cannot determine the relative importance of page elements/links. Appearance of the page could also be controlled by CSS style rules applied by the developer to control its visual appearance while additionally providing structure for the page.

<font size=”+4″>Indiana University Web Accessibility Class:</font>

2.  Adding the heading tags to replace the visual styling, <font> tag.

In this example above, the <font> tag is replaced with an <h1> tag.  As a result, the Web page now has more structure and is easier to navigate using screen-reading software.  If the developer chooses to code the heading style to match the bad example style above, they  create a CSS style declaration with CSS style rules (font-size: 36pt; and font-weight: normal;) and apply it to the <h1> tag. In fact, the <font> tag has been deprecated for XHTML.1.0 in favor of headings and style sheets.

<h1> Indiana University Web Accessibility Class:</h1>

CSS Style declaration:

h1 {
font-size: 36pt;
font-weight: normal;
}

Wrap Up

HTML Headings are a quick and easy way to improve the accessibility and navigability of a Web site for users of screen reading software, without impacting the visual design.  Unfortunately, headings do not offer explicit benefits to users who don’t use assistive technology. However, they do offer great benefits (structure, and ease of navigation for screen-reader users).

]]> http://ittrainingtips.iu.edu/xhtml/web-accessibility-made-easy-headings/10/2010/feed 0 http://ittrainingtips.iu.edu/accessibility/web-accessibility-made-easy-i-wish-i-could-skip-to-the-good-stuff/03/2010 http://ittrainingtips.iu.edu/accessibility/web-accessibility-made-easy-i-wish-i-could-skip-to-the-good-stuff/03/2010#comments Tue, 23 Mar 2010 20:25:38 +0000 ATAC Web Accessibility Team http://ittrainingtips.iu.edu/?p=375 This entry in the “Web Accessibility Made Easy” series will discuss something that is easy and quick to implement and can benefit all users. It is Skip Navigation links.

Skip Navigation

Skip Navigation is a same page or anchored link that can either skip past the navigation of a web site or can be used to skip past any content to what would be considered the main content of the page.

A good example of this would be a Yahoo news story like the one in the image below.



As you can see, there are several navigation links – a link to related stores, some ads, and a lot of other less relevant content – before you actually get to the text of the article. Normally, someone with perfect vision can skip to the text, but someone who is blind would have to navigate through all of that other content just to get to the actual story. This may not seem so bad for one page, but it would get very annoying if you had to view, say, 50 articles for a journalism class. That is where the skip navigation link comes in and allows a screen-reader user to skip right to the content – even if the skip navigation link is hidden using CSS. Many sites leave their skip navigation link visible for all to use, though.

Guideline

IU Web Accessibility Guidelines

15. A method shall be provided that permits users to skip repetitive navigation links.

Tutorial

This tutorial will again be using the Bad example web page, Good example web page, their associated style sheets and Dreamweaver. It is a very simple and straight forward tutorial. If you can create a link, you can create a skip navigation link.

1. Add the link to the named anchor in the content

<a href=”#content” class=”skipnav”>Skip Navigation</a>

This step is very similar to creating a standard link. The only difference is that instead of a web address in the href attribute, we use a “#”, combined with an identifier – in this case “content.” This line of code should be one of the first lines after the start of the body. Finally, to hide the skip navigation link from non-screen-reader users, we use the style “auraltext” which is found below. The “:focus” CSS pseudo-class selector allows keyboard-only users to focus on the link. This ensures compliance with other web accessibility guidelines because the visual focus on the web page is never lost.

.auraltext {
position: absolute;
font-size: 0;
left: -1000px;
}
.auraltext:focus {
position:relative;
font-size:1.5em;
left:2em;
color:#FFFFFF;
}

2. Add the named anchor

<h2 id=”content” class=”auraltext”>Main Content</h2>

Named anchors are elements on a page that are linked to by a link on the same web page. That is why they are commonly referred to as “same page links.” In this case, to make the named anchor even more accessible, it was made a heading. It was also hidden off the page using the style from the step above. Below is another acceptable way to do a named anchor, this time using the <a> tag:

<a name=”content” class=”auraltext”>Main Content</a>

3. That is how you do it! The page now has skip navigation. Try it out.

When the link is clicked, (you may have to remove the style so you can see it) the page should move to the start of the content, not very far for the example page.

Wrap Up

Skip navigation links are a fast and simple way to make navigation for screen-reader users and non-screen-reader uses alike easier. You can do multiple skip navigation links if you have multiple frames or multiple areas of content you want to highlight. Just remember that each named anchor needs a unique title, e.g., content and content2.

]]> http://ittrainingtips.iu.edu/accessibility/web-accessibility-made-easy-i-wish-i-could-skip-to-the-good-stuff/03/2010/feed 0 http://ittrainingtips.iu.edu/accessibility/web-accessibility-made-easy-abbreviations-and-acronyms/08/2009 http://ittrainingtips.iu.edu/accessibility/web-accessibility-made-easy-abbreviations-and-acronyms/08/2009#comments Mon, 17 Aug 2009 18:23:55 +0000 ATAC Web Accessibility Team http://ittrainingtips.iu.edu/web-design/web-accessibility-made-easy-abbreviations-and-acronyms/08/2009 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.

]]> http://ittrainingtips.iu.edu/accessibility/web-accessibility-made-easy-abbreviations-and-acronyms/08/2009/feed 3 http://ittrainingtips.iu.edu/accessibility/web-accessibility-made-easy-lets-not-table-this-guidelines-for-tables/06/2009 http://ittrainingtips.iu.edu/accessibility/web-accessibility-made-easy-lets-not-table-this-guidelines-for-tables/06/2009#comments Wed, 03 Jun 2009 21:29:53 +0000 ATAC Web Accessibility Team http://ittrainingtips.iu.edu/web-design/web-accessibility-made-easy-lets-not-table-this-guidelines-for-tables/06/2009 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.

Unfortunately, tables soon became the primary way for web designers to layout the elements of an HTML page to create enhanced visual design. Unfortunately, when pages are formatted this way they are linearized by screen-reading technology frequently making them difficult to understand because of the complexity of table-based layout.

This is not to say that tables are unimportant. In fact, some data is best represented using tables. And today most screen-reading technology has scripts that try to differentiate between tables used for layout and tables used for tabular data. Unfortunately these scripts aren’t perfect and sometimes still yield inaccessible results. Also, data appropriately represented in table format can be very complex, incorporating multiple rows and columns with spanning information. This makes accessible interpretation challenging if not impossible. Therefore, formatting tables according to accessibility guidelines is very important.

Making tables more accessible relies on two key elements: table headers and table summaries. Table headers are similar to regular headers because they provide clues about how the information is grouped. For example, header text in tables indicates to screen-reader users the data type contained in that column or row. If the column header text says “Dog Breeds” the column will contain a list of breed types.

Also essential for screen readers are table summaries. They provide an overview of the structure of the table which can be viewed prior to the user venturing into the table itself. In addition, users can quickly review table summaries if they get lost and need to reorient themselves.

Guidelines for Tables

-Data tables will have well identified row and column headers and data cells will be clearly associated with row and column headings across logical levels.

-Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers. This guideline is especially important for more complex table.

-Concise summaries of tables will be provided.

Here are some tips for accessibly coding tables.

First, here is a badly coded, inaccessible, simple table. This coding provides neither a table summary nor headings for rows or columns.

<table width="800" border="1">
<tr>
<td width="10"> </td>
<td width="66"><span class="style1">In 508</span></td>
<td width="109"><span class="style1">in WCAG 1.0</span></td>
<td width="123"><span class="style1">In WCAG 2.0</span></td>
<td width="458"><span class="style1">Guideline</span></td>
</tr>
<tr>
<td><span class="style1">1</span></td>
<td>a</td>
<td>1.1</td>
<td>1.1.1</td>
<td align="right">A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content). </td>
</tr>
<tr>
<td class="style1"><span class="style1">2</span></td>
<td>d</td>
<td>6.1</td>
<td>1.3</td>
<td align="right">Documents shall be organized so they are readable without requiring an associated style sheet.</td>
</tr>
<tr>
<td class="style1"><span class="style1">3</span></td>
<td>g</td>
<td>5.1</td>
<td>1.3</td>
<td align="right">Data tables will have well identified row and column headers and data cells will be clearly associated with row and column headings across logical levels. </td>
</tr>
<tr>
<td class="style1"><span class="style1">4</span></td>
<td>h</td>
<td>5.2</td>
<td>1.3</td>
<td align="right">Need definition of logical levels. Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.</td>
</tr>
</table>

As you can see this table is not the most complex, but without table headers and a table summary, it will be difficult for someone using a screen-reader to understand. Here is how it can be fixed.

1. Table summary coding example.

The code below demonstrates how to create a concise table summary which is functions as a roadmap for the table.

<table border="1" summary="This table contains a sampling of the web accessibility guidelines and shows how each set of guidelines parallels the other. The first column is the number of the item. The second column is the section 508 guideline designation. The third column is the WCAG 1.0 guideline designation. The fourth column is the WCAG 2.0 guideline designation. The fifth column is the guideline itself.">

The table summary is an attribute of the <table> tag. The best practice for a table summary is to first describe the contents of the table in general. Then describe the data that is found in each column and row of the table. Because the example table is not very complex, the row descriptions are left out of the summary.

2. Adding the column headers.

The following is an example of coding for column headers.

<tr>
<th width="7">#</th>
<th width="46">In 508<sup><a href="#1">1</a></sup></th>
<th width="79">In WCAG<sup><a href="#2">2</a></sup> 1.0</th>
<th width="81">In WCAG<sup><a href="#3">2</a></sup> 2.0</th>
<td align="center" width="355">Guideline</td>
</tr>

To add column headers, simply change the <td> tag, which defines a standard table cell, into a <th> tag which makes it a table heading tag. Be sure to change the closing tag as well to maintain valid HTML. The table header coding above includes width specifiications so the table will be appropriately displayed for those accessing it visually.

3. Adding row headers.

The following is an example of coding for adding row headers.

<tr>
<th>1</th>
<td>a</td>
<td>1.1</td>
<td>1.1.1</td>
<td align="right">A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content). </td>
</tr>

After adding column headers, add headers for each row. For the example table, change only the first <td> tag as the subsequent cells in the row contain data. Row headers are not necessarily needed for all tables, but it never hurts to include them.

This is all you need to do to create accessible data tables. Those accessing the table visually will hardly notice a difference; those using screen readers will actually be able to access and understand the tabular data.

Wrap Up

Tables were the primary tool for web page layout in the early days of the web. Today there are much better ways to design and control page layout and presentation. However, tables retain great value for presentation of data best provided in tabular format. Making tables accessible takes little time and requires minimal change to the code. And, most importantly, properly coded tables are understandable to screen reader users. Furthermore, if stylesheets are used, the visual look of the table remains the same.

]]> http://ittrainingtips.iu.edu/accessibility/web-accessibility-made-easy-lets-not-table-this-guidelines-for-tables/06/2009/feed 0