Testing

Alternative Text

1. The WAVE toolbar and other automated testing tools will indicate
   • when alternative text attributes are missing
   • when empty alt is present (alt="")
   • infer when a small image may be a spacer image and should use empty alt
   • when the alternative text is over 100 characters

What to look for

1. Alternative text needs to be short, generally less than 125 characters.
2. Is the image used for a link?
   • Is the image the only thing in the link?
   • The alternative text should indicate the destination of the link.
     • If the image has text the alternative text should be the text in the image.
   • Is there text in the link along with the image?
   • The alternative text should be empty (alt="").
   • Is there a text link to the same URL next to this link?
   • The alternative text should be empty.
3. Does the image contain text?
   • The alternative text should be the text in the image.
   • If there is more information than just text in the image, then additional alternative text would be appropriate.
4. Does the image provide information to the user (but without text in the image)?
   • The alternative text should be descriptive.
   • It should give the user equivalent information to what a sighted user could get out of the image.
   • The description should best be written by the content provider since they should know what they were trying to get across with the image.
5. Is the images a <form> image button?
   • The alternative text should be the text in the image.
6. Is the image 'eye candy'?
   • The alternative text should be empty (alt="").
7. Does the description of the image take more than 256 characters? Charts, Venn Diagrams, etc.
   • The alternative text should be a brief description
   • One of the following
   • A longer description on the page.
   • A longer description on a separate page with a link as part of the image caption.
   • A longdesc attribute pointing to a long description in a separate text file.
   • The first two methods allow sighted individuals who may have trouble interpreting these complex images the benefit of the description, while longdesc is only available to screen reader users.

Forms

1. The WAVE toolbar and other automated testing tools will indicate
   • Form elements without an explicitly associated label
   • Labels with the same for attribute used more than once on the page
   • Labels that do not have a form element with a corresponding id to its for attribute (orphaned labels)
   • Radio buttons and checkboxes that aren't enclosed within a fieldset with associated legend

What to look for

1. Form elements have labels associated with themTo explicitly associate the text (usually a question) with the group of check boxes or radio buttons (usually the answer to the question) a surrounding fieldset is used. The legend tag should contain the associated text.
   • All form elements except buttons should have a label tag associated with it using for and id attributes

     <label *for="fname"*>First Name</label>: <input type="text"name="fname"*id="fname"* /> </label>

   • Using the for and id attributes assures that the label will be associated with the form element even if they are not contiguous in the source code
   • When form elements and labels are associated clicking on the label text will select the form element which is useful for users that do not have fine motor control, but use a mouse for navigation

• As a JAWS user navigates through the form elements JAWS will speak the legend text before the label text for each form element.

Tables

1. The WAVE toolbar and other automated testing tools will indicate information about tables
   • If a table looks like a layout table or data table
   • If there are table header cells
     • Column headers
     • Row headers

Simple vs. complex tables

1. A simple table has one level of both row and column header cells
2. A complex table has more than one level of either row or column header cells (can be both row and column)

What to look for

1. Data tables
   • Table header cells are important
   • The header cell information can be read by screen readers when someone navigates to a data cell giving context to the cell data
   • Scope attributes should be used (scope="col", scope="row"
   • Caption tags are good
   • Summary attributes can be used to explain the table
      

     <table summary="class list by student name, unique number and class"> <caption>Fall 2012classlist</caption> <tr> <th scope="col">Student Name</th> <th scope="col">Unique Number</th> <th scope="col">Class</th> </tr> <tr> <th scope="row">John Doe</th> <td>123456</td> <td>Basket Weaving</td> </tr> </table>

2. Layout tables are not recommended, but if they are used they should not have
   • Captions tags
   • Summary attributes
   • Table header cells (<th>)
   • Scope attributes in any table header cell or data cell

Complex tables

What to look for

1. Table header cells for each level of header information is defined
   • Each header cell will include the id attribute
   • Each cell associated with a header cell will include the headers attribute
   • The value of the headers attribute is the id value for all header cells associated with that cell
   • Secondary header cells will have the headers attribute with the value of the primary header cell for that row or column

Keyboard navigation and functionality

1. Put away the mouse and navigate the site
2. Can you tell when an object is in focus (links, link images, form elements)?
   • If an object changes when you mouse over the object does the same behavior occur when you tab to the object?
   • Can you even tab to the object?