Evaluating Markup

This page contains material related to a presentation at the Web Accessibility Best Practices Evaluation Training in Sankt Augustin, Germany on 25 October, 2005, as part of the WAI-TIES Project (WAI - Training, Implementation, Education, Support). It is not intended to stand-alone; rather, it is primarily provided as reference material for participants in the training.

Scope of Training and Materials: This one-day training focused on select topics that were particularly suited to the circumstances of this specific training session. It did not to cover all aspects of evaluating Web accessibility, and did not cover all Web Content Accessibility Guidelines (WCAG) 1.0 checkpoints.
No Endorsement or Recommendation of Evaluation Tools: W3C/WAI does not endorse Web accessibility evaluation tools and does not recommend one tool over another. Some tools were listed, demonstrated, and used in activities in this training. Mention of a specific tool does not imply endorsement nor recommendation. WAI does provide a comprehensive list of Evaluation, Repair, and Transformation Tools for Web Content Accessibility.

Evaluating Markup

Good markup

Valid code means more certainty
- Better for browsers
- Better for Adaptive technologies
- Easier to transform and repurpose
Correctly coded pages enhances structure and semantics
Correctly coded elements like forms and tables are important for correct interpretation
Separating content from presentation gives more flexibility

Valid code

Popular visual browsers can be very forgiving of sloppy code
But we cannot assume or rely on this sloppyness
- we can't know what "browser" someone may need to use
- we can't keep track of the browser specific bugs
- we can't tell what the future holds
Only way to ensure we are doing our part is to code to standards
- Plus the chicken and egg argument – if we code to standards then browser vendors are more likely to support it

Semantic markup

Gives structure:
- Heading levels
- Links coded as link
Plus identifies important information
- Identifying language changes
- Coding quotations
  - Not misusing for indents
- Identifying abbreviations and acronyms
- Also coding other elements semantically
  - <strong><em><address><acronym> etc…

Language

<html lang="en">
  ....
  <p>How do you say hello in French?</p>
  <p>You say
  <span lang="fr">Bonjour</span></p>
  <p>And in German?</p>
  <p lang="de">Guten tag</p>

Other semantic coding

<acronym title="World Wide Web">WWW</acronym>

In this sentence <strong>this is important</strong>

<blockquote> to be or not to be </blockquote>

Table coding

Identifying headings (simple)
- <th>
Associating headings to data
- Simple - scope
- More complex – headers, id, axis etc.
Giving helpful information
- Summary (and caption)
- Abbreviations in the headings

Table coding

<table summary="Important childrens birthdays to remember. First column: childs name, second: childs age, third: date of birthday" >
  <caption>Important Birthdays</caption>
  <tr>
    <th scope="col" abbr="Name" >Name</th>
    <th scope="col" abbr="Age" >Age</th>
    <th scope="col" abbr="Date" >Date of Birthday</th>
  </tr>
  <tr>
    <th scope="row">Emily</th>
    <td>8 years</td>
    <td>3 September</td>
  </tr>
  <tr>
    <th scope="row">Jack</th>
    <td>12 years</td>
    <td>28 April</td>
  </tr>
</table>

Important Birthdays
Name	Age	Date of Birthday
Emily	8 years	3 September
Jack	12 years	28 April

Issues for people with (and without) disabilities

Heading levels - structure

Screen reader users often navigate using heading levels
- Andrew has already demonstrated this
- Others could too (non mouse users using opera)
Viewing without style
- Assists potentially for anyone
  - Visually impaired (use own stylesheets)
  - Mobile devices
  - Text only browsers

Lists

Interpretation of number of items in a list
Identifying menus semantically

Language

For screen readers
Translation programs!

Tables

Accurate interpretation of data cell value
- Headers identified
Orientation within a data table
- Summary and caption

Valid code

Invalid code
- Browser issues – all browsers, adaptive technologies etc.
Deprecated elements, and poor stylesheets
- People using own stylesheets, - elements appear unexpected
- People using IE accessibility settings – elements can disappear

Other semantic coding

<blockquote> <strong> etc.
- No great detriment at present
- But ability to assist in the future with more advanced standards compliant technologies

Relevant checkpoints

Using valid markup

3.2 – priority 2
- Create documents that validate to published formal grammars.
  - And do not misuse code like <pre> manual check
11.2 – priority 2
- Avoid deprecated features of W3C technologies.
  - applet, basefont, center, dir, font, menu, s, strike, u
  - although not deprecated avoid b, i (use CSS instead)

Using headings to give structure

3.5 – priority 2
- Use header elements to convey document structure and use them according to specification.

Using lists to give structure

3.6 – priority 2
- Mark up lists and list items properly

Using CSS

3.3 – priority 2
- Use style sheets to control layout and presentation.
5.3 – priority 2
- Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version).

Table coding

5.1 – priority 1
- For data tables, identify row and column headers.
5.2 – priority 1
- For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.
5.5 – priority 3
- Provide summaries for tables.
5.6 - priority 3
- Provide abbreviations for header labels.

Using semantic coding

5.4 – priority 2
- If a table is used for layout, do not use any structural markup for the purpose of visual formatting
3.7 – priority 2
- Mark up quotations. Do not use quotation markup for formatting effects such as indentation.
4.2 – priority 3
- Specify the expansion of each abbreviation or acronym in a document where it first occurs.

Specifying language

4.1 – priority 1
- Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions).
4.3 – priority 3
- Identify the primary natural language of a document.

Evaluation methods

Validation
- online
  - Validator.w3.org - code
  - http://jigsaw.w3.org/css-validator/Single page - css
Built into or associated with editors
- HTMLtidy

Evaluation methods

Heading levels
- Page visualisation
  - e.g. AToolbar – structure>headings
- Page analysis
  - e.g. AToolbar – structure>headings structure