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.
Jon Dodd, Bunnyfoot
Last updated: 1 November 2005
- 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
- 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
- Gives structure:
- Heading levels
- Links coded as link
- Plus identifies important information
- Identifying language changes
- Coding quotations
- Identifying abbreviations and acronyms
- Also coding other elements semantically
- <strong><em><address><acronym> etc
<p>How do you say hello in French?</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>
- Identifying headings (simple)
- Associating headings to data
- Simple - scope
- More complex headers, id, axis etc.
- Giving helpful information
- Summary (and caption)
- Abbreviations in the headings
<table summary="Important childrens birthdays to remember. First column: childs name, second: childs age, third: date of birthday" >
<th scope="col" abbr="Name" >Name</th>
<th scope="col" abbr="Age" >Age</th>
<th scope="col" abbr="Date" >Date of Birthday</th>
||Date of Birthday
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
- Interpretation of number of items in a list
- Identifying menus semantically
- For screen readers
- Translation programs!
- Accurate interpretation of data cell value
- Orientation within a data table
- 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
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
- 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).
- 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.
- 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.
- Validator.w3.org - code
- http://jigsaw.w3.org/css-validator/Single page - css
- Built into or associated with editors
- Heading levels
- Page visualisation
- e.g. AToolbar structure>headings
- Page analysis
- e.g. AToolbar structure>headings structure
- Look at top of code
- Use page filter to look for lang
- Look at text of page!
- What makes a data table?
- What makes a multilayer data table?