The following is a short list of a few of the most important accessibility requirements and web publishing best practices that you should keep in mind when creating new content on any CWRL site. For a more complete discussion please see the Web Accessibility Guidelines page or the CWRL's accessibility overview.

1. Image "alt" attributes

   Missing attributes on images are the single largest source of Section 508 violations in new content. According to both the Section 508 requirements and the W3C XHTML specifications, every <img> tag must have an "alt" attribute (the "alt" is short for "alternative"). The text of this attribute should indicate the content and relevance of the image for visitors who are using screen readers.

   The alt attribute for a simple image (such as a logo) doesn't need to be more than a word or two: <img alt="SPURS logo" href="/files/spursBanner.gif" width="468" height="100" />, for example. For content-rich images like charts and graphs, the alt attribute should contain a more detailed description of the information provided by the image. Images that are purely decorative (borders, drop shadows, spacing, etc.) should contain a blank alt attribute (<img alt="" href="/files/spacer.gif" width="1" height="1" />).

2. Image "height" and "width" attributes

   Images should also have "height" and "width" attributes (this isn't a Section 508 or W3C standards issue, but it is included in our Watchfire monitoring, and it is always best practice). These should be whole numbers, without any kind of unit ("px", "em", etc.). (Note that these HTML size attributes are different from CSS size properties, which should always include a unit, in this respect.) These attributes allow browsers to render pages more quickly, since images can be situated in the page layout before they are loaded.

   It's best to use the image's native size in these attributes. While you can use the attributes to shrink or expand the image, this often results in unappealing visual artifacts. If you have a large photograph that you want to add to a page, for example, it's better to scale the image in an editor such as Photoshop or GIMP first—this uses less bandwidth and generally looks better.

   You can find an image's height and width by right-clicking the image in your browser and choosing "Properties", or by opening the image in an editor of your choice.

3. Clean URLs and root-relative paths for internal links

   The URL of each page in our Drupal installations has two forms:

   
   http://www.cwrl.utexas.edu/?q=node/96
   http://www.cwrl.utexas.edu/node/96
   
   

   These URLs point to the same document (the Web Accessibility Guidelines page, in this case), but the first is closely tied to the architecture of this Drupal installation, while the second is the "clean" form of the URL. It's important for several reasons that we use the clean form consistently: it reduces redundancy in our monthly Watchfire accessibility results, improves our search engine visibility, and makes the link more likely to survive any future changes in site architecture.

   HTML links come in three basic flavors: absolute links, relative links, and root-relative links. Absolute links include the "fully qualified" URL—this is the protocol ("http"), the domain name ("www.cwrl.utexas.edu"), and the location of the file on the server ("/node/96"). Absolute links are necessary when linking to pages in other domains—for example, when linking to a New York Times article from your course website, or even when linking to Viz from your course website (because viz.cwrl.utexas.edu and instructors.cwrl.utexas.edu are two separate domain names).

   It's best not to use absolute links when linking to content in the same domain (for example, when linking from one page on this site to this site's homepage). Avoiding internal absolute links minimizes the problems that will occur if the domain name is changed, for example, or if the same content is hosted at two different domain names simultaneously.

   Relative links include only the path from the current page to a page in the same domain. You can read more about them here, but they can cause problems in Drupal and should be avoided. For example, a link to "node/96" will work from the homepage, but not from other node pages. Clicking a link to "node/96" from a node page will produce circular URLs of the form "node/node/96", "node/node/node/96", etc., which Drupal tends to handle in unexpected ways.

   It's important for this reason to use root-relative paths in internal links. Root-relative paths begin at the site "root" (the first "/" after the domain name). They don't include the protocol or the domain name, but do give the full path on the server from the root. This full path should include everything after the domain name—for example, if you are adding an internal link in a post to your instructor page, the root-relative URL will include your name: "/tbrown/policy".

   When adding internal links to your pages, then, avoid the following forms:

   
   <a href="http://www.cwrl.utexas.edu/?q=node/96">
   <a href="/?q=node/96">
   <a href="node/96">
   <a href="http://www.cwrl.utexas.edu/node/96">
   
   

   All of these work, in the sense that they take the visitor to the correct document, but they should be avoided for the reasons above. The first is an absolute link that isn't of the "clean" form; the second is root-relative, but also isn't clean; the third is relative to whatever page it occurs on; and the fourth is absolute.

   Instead use URLS that are both clean and root-relative:

   
   <a href="/node/96">
   
   

   Finally, these guidelines apply for links that you are adding in the body of a post (a blog entry, book page, etc.). When adding links to Drupal menus through the administration menu interface, you should follow the directions given there, which are slightly different (links should be relative to the installation root, without the initial slash). And yes, this is confusing and inconsistent, but it's the way Drupal works.

   See Tim Berners-Lee's classic essay "Cool URIs don't change" for more information about linking and good URL design.

4. Semantic HTML elements

   Tags such as <i> (for italics) and <b> (for bold) provide visual formatting information only: they tell the browser which font face to use, but not why to use it. This means they aren't very useful for browsers that render the page in a non-visual way.

   Instead of using <i> for italics, you can use <cite> for titles and <em> for emphasis. Both of these will be rendered in italics in visual browsers, just as if you had used <i>, but they also provide semantic information that non-visual browsers or other web agents can use.

   Semantic HTML elements are one part of a larger movement toward a world wide web populated by semantically rich content, not just human-readable, nicely formatted text documents. Using semantic elements instead of the corresponding formatting elements is especially important in the CWRL given our commitment to making our web content accessible to people with disabilities.

   There are many online guides that discuss semantic HTML elements in more detail: see 456 Berea St. for one starting point.

5. Using HTML header elements for page sub-headers

   If you wish to divide a page into subsections with sub-headers, you should use the HTML <h*> elements, not <strong> or HTML formatting elements. <strong> is a semantic element that indicates that a range of text should be emphasized. Traditional visual browsers render this emphasis by using bold type, which superficially resembles a page sub-header. A screen reader, on the other hand, may render <strong> by increasing the volume at which the text is read, which does not accurately capture the page structure if the <strong> element is being used as a sub-header.

   The solution is to use HTML header elements (<h1>, <h2>, <h3>, etc.). In general you should use either <h2> or <h3> for your first hierarchical level of sub-headers, and increase the number by one for each additional level (sub-sub-headers, sub-sub-sub-headers, etc.).