Guidelines
| Section 508 | Priority 1 | Other Issues |
Section 508
While ideally, IDDL developers should strive to make Web documents accessible to as many users as possible by conforming to all Priority Levels of the W3C Guidelines, as a practical matter, Section 508 compliance can be viewed as the minimal standard that all web developers should attempt to meet. Therefore, this section will deal first and foremost with how to implement the 508 requirements.
Rule a)
A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).
This is a major rule that, fortunately, is relatively easy to implement. Every non-textual element (such as images or animations) must be made accessible to people who cannot see the element. To do this, we can use the alt attribute of the <img> tag. Here is an example:
<img src="camp.jpeg" width="100" height="150" border="0" alt="Portrait photograph of Dr. Camp.">The text string assigned to the alt attribute will be read when users experiencing the page with a screen reader encounter the image. Additionally, this makes the image accessible to those viewing the page through a text-based browser such as Lynx, or to those with image display turned off in their browser, since it will enable meaningful text to be displayed instead of a generic image placeholder.
Of course, the text assigned to the alt attribute must adequately describe the non-textual element to be useful. In some instances, where the image conveys more information than can adequately be described in a short sentence, it may be necessary to provide a link to a page that contains a lengthy text description of the non-textual element. While the HTML 4.0 specification includes the longdesc attribute for this purpose, this is only implemented in the very latest browsers. The longdesc attribute provides a URL for an annotated description to be retrieved for users who see the non-text element. Here is an example:
<img src="chart.gif" width="500" height="400" longdesc="chart.html">where "chart.html" is a web page containing a detailed text description of the chart.
As mentioned, longdesc is only implemented in the latest browsers. Therefore, an acceptable alternate implementation is to accompany any non-textual element requiring a lengthy description with a text link to a page (or anchored point on that page) that describes in detail the non-textual element. A commonly understood symbol for such a description in the disabled community is the capital letter "D." Thus, this would be implemented in HTML as follows:
<img src="chart.gif" width="500" height="400"><a href="chart.html">D</a> where "chart.html" is a web page containing a detailed text description of the chart.
Any chart, graph, or image designed to convey detailed information will require such an implementation. Since describing such non-textual elements is a time-consuming process, often requiring specialized knowledge of the subject matter, IDDL staff should inform faculty that they must provide such descriptions when asking us to incoporate media of these types.
Often web developers will use transparent gifs to maintain positioning in tables used for layout. In these instances, and where the images contain no relevant information, developers should still include the alt attribute, but assign it an empty string. This way images will not be presented with the mysterious a generic image placeholder, leaving the user to wonder what they are missing. This would be implemented in HTML as follows:
<img src="spacer.gif" width="5" height="1" alt="">Rule (b)
Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.
The long and short of this rule is that closed-captioning should be provided for any audiovisual presentation such as digital video (QuickTime, Real, Windows Media) or multimedia presentations using Flash, SMIL or similar technologies.
The most common tool used for producing such closed-captioning is MAGpie
. This free program allows developers to easily create captions for Quicktime, Real and Windows Media. For information on how to use MAGpie, view the MAGpie tutorial at WebAIM. The National Center for Accessible Media (NCAM), the maker of MAGpie, has also created a free captioning extension for Flash that helps ensure content created with that tool is accessible. This tool is somewhat limited in that it doesn't maintain synchronization of the captioning when the presentation's flow is interrupted by rewinding, fast-forwarding or pausing. To deal with this issue, IDDL has developed a modified version of this extension that is more robust. Contact Robert Fentress for details. To learn more about accessibility and Macromedia products, visit Macromedia's Accessibility Resource Center.
For accessibility, it is generally preferable to have multimedia files play using their own plug-in or player rather than having them embedded within the page. The hooks used by screen readers to access these documents may not be accessible when content is embedded within the page.
Rule (c)
Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.
This rule is designed to ensure that Web content is accessible to individuals with visual disabilities such as blindness or color blindness. Do not use phrases such as "Please complete the assignments marked in red before next class period." People who cannot see or distinguish between colors will have difficulty successfully following these directions. If the use of color cues cannot be avoided, provide an alternative means of distinguishing between the colors. For instance, use the title attribute to signify color to those with visual disabilities. Here is an example:
. . .
<p><b>Assignments marked in <span title="red"><font color="#FF0000">red</font></span> are due tomorrow!
</b>All others are due next week </p>
<ul>
<li><span title="red"><font color="#FF0000">Read Chapter 2: </font></span>History and you</li>
<li><span title="red"><font color="#FF0000">Assignment 1: </font></span> Write a summary of the chapter.</li>
<li>Reflection 1: Write a report on how one's view of history affects the present.</li>
</ul>
. . . This will have the effect of making this information available to those with visual disabilities, as their screen readers will read the color information to them. It also will cause the word red to appear if the user pauses his or her mouse over the tagged phrase in Internet Explorer.
The title attribute can be used with many HTML tags. If in doubt about whether it can be used with a particular tag check the HTML specification at W3C or just use it as an attribute of the <span> which can encompass any element.
Developers should also ensure that colors used provide sufficient contrast for easy readability. Viewing the page in grayscale can help in determining if contrast is appropriate.
Note: An issue related to the use of color is the use of all captital letters to signify emphasis. Screen readers generally interpret words written in all capital letters as being acronyms and spell them out. Therefore, instead of all caps, developers should use the <em> tag when attempting to denote words to be given special emphasis. This might be implemented as follows:
<p>Making accessible web pages is <em>very</em> important</p> Rule (d)
Documents shall be organized so they are readable without requiring an associated style sheet.
Style sheets are recommended for presentation markup and should be used for color, styling, sizing and positioning of elements on the page, rather than HTML markup such as <font/> or <table/>. However, developers must design web documents so that they transform gracefully in the abscence of CSS support. Developers should ensure that, when viewed without CSS, the page is still readable. The page need not be attractive when viewed without CSS, but the information it contains must still be understandable.
In the absence of CSS, browsers will generally display content in the order in which it appears in the HTML code. However, it is possible to use CSS to position elements such that content that appears later in the code appears before earlier content when rendered visually in a browser. This may make the text nonsensical when rendered without CSS or when read by a screen reader, since screen readers also present content in the order in which it appears in the code rather than the order a sighted person might read it when rendered in a browser. Below, is an example of text that would not be presented in the proper order when accessed without CSS or with a screen reader.
. . .
.appearslast { position:absolute; top:2em; }
.appearsfirst { position:absolute; top:0em; }
. . .
<div class="appearslast">world!</div>
<div class="appearsfirst">Hello</div>
. . . Additionally, some browsers do a very poor job at rendering styled content. For instance, 4.x versions of Netscape do not handle positioning or borders in the proper way and Internet Explorer 4 makes text sized with the em unit unreadably small. This may make styled content unreadable. Therefore, developers should place their styles in external stylesheets and reference them using the @import syntax, as follows:
. . .
<style type="text/css">
@import "style.css";
</style>
. . .Neither of these non-conforming browsers will load stylesheets referenced using this syntax, though it is a valid way of loading stylsheets according to the CSS specification. This means they will, instead, display content in the order it appears in the code. If you've ordered things properly in the code, then the content will be readable, though not particularly attractive. Most other browsers understand the @import syntax and, thus, will load the external stylsheet and fomat the page in the way you intended.
See the markup for this page and the sample pages in the Layouts section of this site for examples of CSS-based page layouts that degrade gracefully in broswers that don't support CSS.
Rule (e)
Redundant text links shall be provided for each active region of a server-side image map.
Before the advent of client-side image maps, information about the the URLs associated with image map regions was stored on the server. This is mostly a legacy issue, since developers seldom use server-side image maps any more. However, if they are used, seperate text links must also be included.
Rule (f)
Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.
This is a curious specification, since it is not immediately apparent what geometric shapes cannot be defined using client-side image maps that are available using server-side image maps. Suffice it to say that unless a developer is designing for a legacy browser such as Mosaic, server-side image maps should be avoided.
Also keeping in mind rule a) above, all image map regions as well as the base image should include the alt attribute to provide a text alternative for all active regions in the image as well as the image itself. Here is an example of how that would work:
. . .
<img src="../images/imap.gif" width="407" height="100" usemap="#Map" border="0" alt="Image map for full catalog, product reviews, and contact">
<map name="Map">
<area shape="rect" coords="47, 33, 155, 102" href="catalog.htm" alt="Full Catalog" title="Full Catalog">
<area shape="poly" coords="154, -1, 192, 76, 213, 75, 249, 52, 274, 9, 273, -1" href="reviews.htm" alt="Product Reviews" title="Product Reviews">
<area shape="poly" coords="291, 1, 291, 65, 319, 65, 319, 86, 397, 86, 397, 66, 410, 65, 406, 0" href="contact.htm" alt="Contact Us" title="Contact Us">
</map>
. . . Rule (g)
Row and column headers shall be identified for data tables.
Row and column headers are a seldom used part of the HTML specification, that, nevertheless, are invaluable to those with visual disabilities. Sighted individuals can see the relationship between pieces of information in a data table at a glance. By contrast, it is quite easy for those who rely on screen readers to lose track of where they are in a data table. Use the <th> tag to identify cells in the table that are to serve as headers. If the header is for a column (vertical axis), assign the scope attribute of the <th> tag the value "col". If the header is for a row (horizontal axis), assign the scope attribute of the <th> tag the value "row". This enables assistive devices to read the contents of the header cells before their associated data cells, greatly assisting those with visual disabilities in orienting themselves within the table.
. . .
<table border="1">
<tr>
<th scope="col">First Name</th>
<th scope="col">Last Name</th>
<th scope="col">Social Security Number</th>
</tr>
<tr>
<td>John</td>
<td>Smith</td>
<td>123-45-6789</td>
</tr>
<tr>
<td>Mary</td>
<td>Jones</td>
<td>987-65-4321</td>
</tr>
</table>
. . . Here is how a visual browser might format such code. Note that data between the opening and closing <th> tags is, by default, centered and bolded in Netscape and IE. This may require additional formatting to achieve the desired visual presentation style.
| First Name | Last Name | Social Security Number |
|---|---|---|
| John | Smith | 123-45-6789 |
| Mary | Jones | 987-65-4321 |
By contrast, a screen reader, might, if configured properly, read this table as follows:
First Name, Last Name, Social Security Number
First Name: John, Last Name: Smith, Social Security Number: 123-45-6789
First Name: Mary, Last Name: Jones, Social Security Number: 987-65-4321
While this is preferable to not using <th> tags at all, an even better implementation would use the abbr attribute of the <th> tag to streamline the process of navigating the table.
. . .
<table border="1">
<tr>
<th scope="col" abbr="First">First Name</th>
<th scope="col" abbr="Last">Last Name</th>
<th scope="col" abbr="Social">Social Security Number</th>
</tr>
. . . Using the abbr attribute might cause a screen reader to use the abbreviation supplied,if configured properly, rather than the full contents of the header when reading the table. Thus the revised version might be read as follows:
First Name, Last Name, Social Security Number
First: John, Last: Smith, Social: 123-45-6789
First: Mary, Last: Jones, Social: 987-65-4321
For a lengthy table, such abbreviations would be quite a time saver! In addition, the abbr attribute can be used to save valuable screen real estate for usres accessing the page from wirless devices.
Other worthwhile, but little used, HTML specifications for tables are the summary attribute of the <table> tag, and the <caption> tag. Text describing the nature of the table is assigned to the summary attribute, and the title for the table goes between the opening and closing <caption> tags. These are then read to the those using a screen reader giving them information that could help them decide whether they really need to spend the time listening to the whole table. Here is how that code would look:
. . .
<table summary="This table lists the names and social security numbers of all of the students in CS1001" border="1">
<caption>Students in CS1001</caption>
<tr>
<th scope="col" abbr="First">First Name</th>
. . .
<td>987-65-4321</td>
</tr>
</table>
. . . A visual browser might render this table in this manner:
| First Name | Last Name | Social Security Number |
|---|---|---|
| John | Smith | 123-45-6789 |
| Mary | Jones | 987-65-4321 |
Note that, by default, Netscape and IE render text between the opening and closing <caption> tags by centering it at the top of the table. Again, this may require additional formatting to achieve the desired visual presentation style.
Rule (h)
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.
Sometimes tables are more complicated than the examples used above. For example, IDDL uses a tables to lay out links to course documents for several of its sites. These tables list support materials and assignments for each lesson, are divided by unit, and have both column and row headers. In order for those using screen readers to more easily associate cell data with its respective headers, the id and headers attributes are used. Every <th> tag should contain an id attribute that associates a name with each table header. Then, each <td> tag should contain a headers attribute that references the assigned id of any headers it is associated with. An slightly simplified example is shown below.
. . .
<table border="2" cellspacing="2" cellpadding="2">
<tr valign="top">
<th id="U1" abbr="Unit 1" colspan=3>Unit I -- Learning Strategies</th>
</tr>
<tr valign="top">
<th id="Lessons">Lessons</th>
<th id="Materials" abbr="Materials">Support Materials (optional)</th>
<th id="Assignments">Assignments</th>
</tr>
<tr valign="top">
<th id="U1L1" headers="U1 Lessons" abbr="Lesson 1">
<p>Lesson 1</p>
<p>Individual differences</p>
</th>
<td headers="U1 U1L1 Materials">
<ul>
<li>
<a href="trans/c3u1l1.htm">Transcript 1 </a>
</li>
<li>
<a href="trans/c3u1l1.ppt">Slides 1 </a>
</li>
</ul>
</td>
<td headers="U1 U1L1 Assignments">
<ul>
<li><a href="docs/c3u1l1-r.html">Readings 1 </a>
<li><a href="docs/c3u1l1-h.html">Handouts 1 </a>
</ul>
</td>
</tr>
. . . Such a table might be displayed as follows in a visual browser:
| Unit I -- Learning Strategies | ||
|---|---|---|
Lessons |
Support Materials (optional) |
Assignments |
| Lesson 1 Individual Differences |
||
Lesson 2 Learning Styles |
||
| Unit II -- Instructional Planning | ||
| Lessons |
Support Materials (optional) |
Assignments |
| Lesson 1 Instructional Strategies |
||
| Lesson 2 Development of Skills |
||
A screen reader, on the other hand, might use the id and header tags to read the header information before reading the contents of a cell. For instance, the first data cell in our table references the ids of three different headers, U1, U1L1, and Materials. Therefore, a screen reader might read this cell as follows:
Unit 1, Lesson 1, Materials: Transcript, Slides
Notice that it reads the abbreviation of the header rather than the full contents of the header cell, because we used the abbr attribute. Associating headers with cells also makes it possible for future user agents to perform queries against the table as one might a database with SQL. For instance, someone using one these future browsers might be able to ask that only the Assignments for Lesson 2 of Unit 2 be displayed.
Rule (i)
Frames shall be titled with text that facilitates frame identification and navigation.
The use of frames can be a bad idea for many reasons, not the least of which is the challenge they present to those using screen readers. The blind find it difficult to orient themselves in sites that use frames unless those frames are titled. Titling frames using the name and title attributes enables screen readers to read the name of the frame whenever the user shifts focus between frames, letting sightless users know where they are in a framed document. The following is an example of how one might implement frame titling:
. . .
<frameset cols="150,*">
<frame src="toc.html" name="Table of Contents" title="Table of Contents">
<frame src="main.html" name="Main Frame" title="Main Frame">
</frameset>
. . . Rule (j)
Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.
The use of flickering elements is an example of poor design, and may prove especially distracting to those with attention deficit disorders. It may also prompt seizures in individuals with seizure disorders. Avoid the use of the <blink> tag (which is not supported by any HTML specification anyway) and do not use CSS to cause items to blink.
Rule (k)
A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.
As a general rule, developers should attempt to practice principles of universal design--that is they should try to make one page that is accessible to the widest possible range of users. However, for some pages it may prove impossible to implement the 508 rules and still provide needed functionality to users without disabilities. In those instances, a text-only page should be provided that contains the same information as the primary page (and that is updated as often). A link to the text-only page should be placed at the top of the primary page before any other links. A link back to the primary page should also be provided.
Rule (l)
When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.
This is a somewhat confusing standard, but has generally been interpreted to mean that content or functionality provided by JavaScript must be accessible when a page is accessed by someone using an assisstive technology such as a screen reader or non-standard input device. This means that mouse-based events such as onmouseup or onmousedown should be avoided in favor of more device independent events such as onclick. Ideally, methods should be triggered by both onclick and redundant onkeyup events, where possible, to ensure that keyboard access to events is available. Also, interactive behaviors that cause the contents of the screen to change dynamically should be tested out using assistive technologies to ensure that they behave as expected. For instance, depending on the technique used, screen readers may begin rereading the page from the top in response to some user action that causes the screen to change and this may not be the user experience intended by the developer.
Additionally, any time a developer uses JavaScript or another scripting language to present information, it is preferable that that information be made available if scripting is disabled. This is not an issue when Javascript is used for simple rollover buttons, since, in that instance, no significant information is being presented. However, when rollovers are used, for instance, to cause text to appear in a layer on the page, the <noscript> tag should be used to enable users without Javascript to access the same information.
Another instance when the <noscript> tag should be used is when Javascript is used to open a new browser window. This technique is often used in order to be able to specify the size and characteristics of the window being opened. Here is an example of how you could use <noscript> in that instance.
. . .
<script language="JavaScript">
<!--
function MM_openBrWindow(theURL, winName, features) { //v2.0
window.open(theURL,winName,features);
}
//-->
</script>
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>
<script>
<!--
document.writeln("<a href=\"#\" onClick=\"MM_openBrWindow('newWindow.html', 'newWindow', 'width=300,height=400')\">link</a>");
//-->
</script>
<noscript> <a href="newWindow.html" target="_blank">link</a> </noscript>
. . . In this instance, if Javascript was not supported on the user's browser, the less flexible but nevertheless acceptable HTML attribute target would be used to open the new window instead. Without the <noscript> tag, users with browsers that don't have Javascript turned on would be unable to access the page.
This example was used to demonstrate the use of the <noscript> tag and is not, actually, the best way to make accessible pop-up windows. A better method of achieving this same affect can be found at A List Apart's article on making Accessible Pop-up Links.
Rule (m)
When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l).
For pages which require the use of a plug-in, the developer must provide a link to a page where the user can download the plug-in. Section §1194.21 of Section 508 of the ammendment to the Rehabilitation Act specifies rules for how software must be designed in order for it to be accessible to people with disabilities. Any plug-in technology used must meet these specifications.
Rule (n)
When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
Often forms use tables to lay out fields and their associated labels. While this creates forms that are well-organized from a sighted viewer's perspective, those using screen readers often find it difficult in such implementations to make the association between fields and their labels. Therefore, the ideal and simplest implementation of forms for accessibility is to use a seperate line or table row for each label/field pair. There is also markup that can be used to logically group fields with their labels. This can make the structure of a form clearer to visually impaired users. An example of such an implementation would be as follows:
<form name="userinfo" method="post" action="processform.php">
<label for="fname">First Name</label>
<input id="fname" type="text" name="textfield33" size="12"><br>
<label for="mi">Middle Initial</label>
<input id="mi" type="text" name="textfield35" size="1"><br>
<label for="lname">Last Name</label>
<input id="lname" type="text" name="textfield34" size="12"><br><br>
. . . Just as markup can be used to associate header cells with table data, the <label> tag and the for and id attributes demonstrated above can be used to associate labels with their respective fields.
Similarly, the <fieldset> and <legend> tags can be used to associate related field items with one another and describe this grouping. This might be implemented as follows:
<fieldset>
<legend>Your mailing address</legend>
<label for="address1">Street Address: <input type="text" name="address1" size="40"><br></label>
<label for="address2">Address Line 2: <input type="text" name="address2" size="40"><br></label>
<label for="city">City: <input type="text" name="city" size="20"><br></label>
<label for="state">State: <input type="text" name="state" size="10"><br></label>
<label for="zip">Zip Code: <input type="text" name="zip" size="10"><br></label>
</fieldset> In some more recent browsers this would cause the fields in the fieldset to be bounded with a border. It would also allow future browsers to place a label on this border with the text contained between the legend tags.
The <optgroup> tag and label attribute can also be used to group logically related items within select boxes. This provides additional structure to your form, making it more accessible. <optgroup> might be implemented as follows:
<label for="education">High Level of Education Completed</label>
<select id="education" name="education">
<optgroup label="High School">
<option value="g9">9th grade</option>
<option value="g10">10th grade</option>
<option value="g11">11th grade</option>
<option value="g12">12th grade</option>
</optgroup>
<optgroup label="College">
<option value="some">Some College</option>
<option value="bachelor"> Bachelor's Degree</option>
<option value="master">Master's Degree</option>
<option value="doctor">Doctorate</option>
</optgroup>
</select>
</form> Special consideration must be given to using forms created with Adobe Acrobat. PDF forms must be saved as version 5 or later in order to afford full access to those using screen readers. Version 5 adds structural markup to any PDF documents that enables them to be read by screen readers. PDF documents can be converted to this tagged PDF format by using the Make Accessible plug-in for Acrobat 5. Adobe has a series of videos that explain the process for making Acrobat documents accessible to those using screen readers. These videos also give suggestions for ensuring that other document types such as Microsoft Word files are structured in a way that makes them accessible.
Rule (o)
A method shall be provided that permits users to skip repetitive navigation links.
Those using screen readers should not be forced to listen repeatedly to the navigation menus that appear at the top of many web pages in a site. Therefore, developers should provide a way for those using such devices to skip these menus and progress to the main part of the document. One way to do this is to create a link at the beginning of such a menuing system that takes the user to a place in the page after the navigation menu. Such a "skip link" would also be valuable to those accessing your page on a device with a small screen such as a PDA or cell phone. However, there is no need for sighted users who are not using handheld devices to see these skip links. To hide them, use CSS absolute positioning to place the link offscreen and out of the visual document flow. Though off the creen, such links will still be read by screen readers, and handheld devices usually override absolute positioning, so these links would appear to these users. See the example below:
. . .
<body bgcolor="#FFFFFF" text="#000000">
<div style="position:absolute;left:-1000em;width:20em;"><a href="#main">Skip to main content</a></div>
<p>
| <a href="home.html">Home</a> | <a href="objectives.html">Objectives</a>
| <a href="lessons.html">Lessons</a> | <a href="resources.html">Resources</a>
| <a href="schedule.html">Schedule</a> |
</p>
<p id="main">This is the course web site for Math 101.</p>
. . .Rule (p)
When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.
This specification should primarily be an issue with Blackboard 5's timed tests. While Blackboard's own assessment of their 508 compliance indicates that they meet this specification, this is not entirely accurate. While students are warned when a time limit is approaching, they are not able to indicate that they require more time.
Disability Services should provide professors at the start of the semester with information regarding any accomodations students in their class may require. If any student has a disability that requires more time than normal to complete a timed test, the professor should make an alternate test with an expanded time limit or one with no time limit at all as the case may be.
When designing multimedia applications or web pages with a timed component, web content developers should keep this specification in mind. Such applications should provide both a warning of when the time is about to run out, and afford students the opportunity to extend the time allowed.
WCAG Priority 1 Checkpoints
Two Priority 1 Checkpoints from the W3C's Web Content Accessibility Guidelines are not included in the Section 508 specifications. There appears to be no sensible reason for this, as they are easy enough to implement. Therefore, while not absolutely required, IDDL developers should strive to implement the following two checkpoints when at all possible.
Checkpoint 4.1
Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions).
Usually, all this entails is adding the lang attribute to the <html> tag and assigning the string "en" to it. This just tells a screen reader to pronounce everything on the page as if it were written in English. An implementation of this would look like this:
<html lang="en">Similarly, and perhaps more importantly, whenever the language strays from English, this too should be noted using the lang attribute--this time as a part of the <span> tag. Here is an example of how this would work:
<p>People from Paris greet American tourists with smile and a friendly "<span lang="fr">Bonjour!</span>"</p> A screen reader would, thus, adjust its pronunciation accordingly when reading the previous line.
IS0 639 specifies the codes to be used for the representation of the names of languages.
Checkpoint 14.1
Use the clearest and simplest language appropriate for a site's content.
This specification is self-explanatory and, for the most part, followed by IDDL developers.
Other Accessibility Issues
. . . and that's not all! The Web Content Accessibility Guidelines also list Priority 2 and 3 Checkpoints. While the W3C says web content developers must satisfy Priority 1 Checkpoints, they only say developers should satisfy Priority 2 Checkpoints and may address Priority 3 Checkpoints. Therefore, while not legally required, these other checkpoints are recommended. To see the entire list of checkpoints view the Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0. Many of these further guidelines are just common-sense good web design which IDDL staff regularly implement already. While it is beyond the scope of this document to address all of the issues raised by these checkpoints, based on an examination of current IDDL web sites, it may be worthwhile to deal with a few of the Priority 2 and 3 checkpoints in more detail.
Structural Markup
Several W3C Web Content Accessibility Guidelines deal with the difference between presentation versus structural markup (3.3, 3.5, 3.6, 3.7, 5.3, 5.4). What this means is that much of HTML is designed not so much to deal with how the page should look as much as how to convey the logical structure of the document. The next several checkpoints addressed will deal with the proper use of this structural markup.
Checkpoint 3.5
Use header elements to convey document structure and use them according to specification. (Priority 2)
The Heading tags (<h1>, <h2>, etc.) are meant to convey just that--headings. However, rather than using these tags to denote the titles for sections and subsections, developers sometimes use them to present the information as bolded or of a certain size. This is a bad idea. The HTML specification does not specify how browsers are to get across the idea of headings. The size and degree of bolding thus differs between browsers and platforms. It is even conceivable that browsers could try to get across the idea of a heading by surrounding it with quotes, underlining it, or by using color. Therefore, the H tags should only be used to signify logical headings for sections on a page, and Cascading Style Sheets (CSS) should be used to determine the presentation attributes of the text (size, boldness, color, etc.). This use of structural markup gives more useful information to those using screen readers and makes it easier for them to orient themselves and navigate through the page.
Of course, just as one should not use the H tags to set the size or boldness of text, so, too, should one avoid using presentation markup to get across the idea of headings. In other words, don't use CSS or the <bold> tag to simulate the appearance of a heading--just use an H tag!
This checkpoint also implies that one should not use an <h3> tag to denote the main heading of a page just because the <h1> tag would be too big. Rather, one should use CSS to change the way the <h1> tag is presented, making it appear smaller. Then, if necessary, use CSS to adjust the presentation of the other H tags, making them even smaller or otherwise denoting their subordinate status.
Checkpoint 3.6
Mark up lists and list items properly. (Priority 2)
The list markup <ul>, <ol>, <li>, etc., is designed to present lists of information and should be used for that purpose. For instance, list markup should not be used to set off a single item. Conversely, one should not use number text, em-dashes or double hyphens to set off a list of items. Instead, any time one has a list on a page, it should be denoted using the appropriate list markup. This allows user agents to present the information more meaningfully. For instance, it may allow an individual using a screen reader to choose to jump to the tenth item in a list.
Checkpoint 3.7
Mark up quotations. Do not use quotation markup for formatting effects such as indentation. (Priority 2)
Sometimes, to set off text from the edges of a page or from other elements on the page, developers will use the <blockquote> tag to indent the text. Again, as with the H tags, this is not the <blockquote> tag's proper function, and it cannot be relied upon to produce any particular visual presentation effect. Rather it has the logical function of denoting blocks of quoted text, and this is what it should be used for. In order to indent text, one should use CSS. A style that could be used to indent text might look like the following:
<style type="text/css">
<!--
.indent { text-indent: 2em}
-->
</style> Checkpoint 3.3
Use style sheets to control layout and presentation. (Priority 2)
As mentioned in the previous checkpoints, style sheets (CSS) should be used to control the visual presentation of information on the page. While it is beyond the scope of this document to teach style sheets, a quick CSS tutorial is available at htmlhelp.com that might help in getting started.
See the markup for this page and the sample pages in the Layouts section of this site for examples of CSS-based page layouts that can serve as starting points for your development.
Checkpoint 3.4
Use relative rather than absolute units in markup language attribute values and style sheet property values. (Priority 2)
For those familiar with CSS, it is important to note that in instances of sizing and positioning the em unit or percent values should be used rather than pixel or point values. em is a relative unit of measure that facilitates the appropriate scaling of information on a page.
The markup for this page and that of the sample pages in the Layouts section of this site use relative units.
Checkpoint 10.1
Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. (Priority 2)
While it is sometimes valuable to launch a new window (for instance when visiting a page off-site) users should be warned when clicking on a link will cause a new browser window to be spawned. This can be done most unobtrusively by using the title attribute of the anchor tag as follows:
<a href="new_window.html" target="_blank" title="This will open a new window.">Visit an off-site link</a> Users viewing the page with Internet Explorer will have the title message displayed under their mouse when they mouse over a link. Those using screen readers may have this message read to them.
Note: A similar technique should be used to warn users when clicking on a link will launch an application such as Microsoft Word or RealPlayer.
Last Updated: October 20, 2006 2:33 PM
|
|
