Evaluating Presentation

Checkpoints covered:

• Reliance on colour :
  • 2.1 (P1) - Ensure that all information conveyed with color is also available without color, for example from context or markup.
  • 2.2 (P2/3) - Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen.
• Design for flexibility
  • 3.4 (P2) - Use relative rather than absolute units in markup language attribute values and style sheet property values.
• Layout Tables
  • 5.3 (P2) - Do not use tables for layout unless the table makes sense when linearised.
  • 5.4 (P2) - If a table is used for layout, do not use any structural markup for the purpose of visual formatting.
• Data Tables
  • 5.1 (P1) - For data tables, identify row and column headers.
  • 5.2 (P1) - 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 (P3) - Provide summaries for tables.

Introduction

Presentation assists people to view and interact with your pages - get it wrong and many people, with and without disabilities, will have problems accessing your information and interacting with your web site. Aspects of presentation included in this session are the use of colour, flexibility of screen design and fonts and the use of tables (both for layout and the presentation of data).

Colour issues

Checkpoints:

• 2.1 (P1) - Ensure that all information conveyed with color is also available without color, for example from context or markup.
• 2.2 (P2/3) - Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen.

Overview:

Not everyone can see colour, or differentiate between different colours. A blind person cannot hear the colour; a colour blind person may not be able to differentiate between certain colour combinations; an older person will have difficulty with low contrast differences; in the outdoors, colour will 'wash out'. Ensure that all information is discernable and understandable when the colour is removed.

Tools:

• Visual browsing
  • look for the use of colour to indicate important information
  • look for situation with poor, or suspect, contrast
• AIS Accessibility Toolbar:
  • Colours / Greyscale filter
  • Colours / Colours used (or sample colours from the image with tools such as Color Cop)
  • Colours / Contrast analyser link (Juicy Studio)
  • Tools / Simulations / Reduce contrast
  • Tools / Simulations /Colour blind simulations link
• Check for colour blind issues with VisCheck
• AIS Accessibility Toolbar
  • Structure / simple data table - see if data-table headings are marked-up
  • Structure / headings - are all visual headings marked-up
• Examine the code

Demonstration:

A selection of pages were used to demonstrate these tools.

Activities:

Using several of tools demonstrated (starting with a visual assessment), view some pages of your choice and:

• Scan any forms or catalogues for colour vs other indicators of important information.
• Scan any data-tables for headings portrayed with colour (or font-weight) alone.
• Scan pages for section headings shown with colour (and size) alone.
• Scan pages for links the same of similar colour/intensity to the text, and no underline.
• View the screen with a greyscale filter - is the contrast ok?.
• Check the RGB value of any suspect combination and check the contrast with JucyStudio's contrast analyser.
• Check for background images
  • they may present contrast issues, especially when different colour schemes or text sizes are applied
  • when not supported (or the images are turned off), overlying text may become hard to read or invisible
  • when used for contrast with overlying text, a change in text size may move text to a place that makes it unreadable
• Check some pages with VisCheck colour blind filters

Flexible design

Checkpoint:

• 3.4 (P2) - Use relative rather than absolute units in markup language attribute values and style sheet property values.

Overview:

Many people need to adjust the size of text; few know about accessibility settings in IE and even fewer use Opera or FireFox. Not everyone does, or wants to, operate their screen at the same resolution as the web site designer. Designs should be "fluid" to accommodate different users' needs.

For example, in CSS, use 'em' or percentage lengths rather than 'pt' or 'cm', which are absolute units. If absolute units are used, validate that the rendered content is usable.

Tools:

• Manual & visual checks
• Code examination
  • View the HTML source code of the page, examining the text size or CSS classes applied
  • AIS Accessibility Toolbar - highlight the part of the page in question, then select "Tools / View partial source"
  • View the CSS for fixed unit text size settings
    • Load the CSS in to the browser
    • AIS Accessibility Toolbar - CSS / Show Style Sheet

Demonstration:

A selection of pages were used to demonstrate these tools.

Activities:

On pages your of your choice:

• In any browser change the screen resolution from 800x600 to 1024x768 to 640x480 and see if the tables and/or screen layout resizes and/or remains usable at different resolutions (preferably without requiring horizontal scrolling)
• In Internet Explorer check for screen readability when you set:
  1. "View / Text-size / largest" - did ALL the text increase in size?
  2. "View / Text-size / smallest" - did ALL the text reduce in size?
  3. Did any text overlap?
• Examine the page code and/or the CSS code for fixed unit sizes for tables and/or text.

Layout Tables

Checkpoints:

• 5.3 (P2) - Do not use tables for layout unless the table makes sense when linearised.
• 5.4 (P2) - If a table is used for layout, do not use any structural markup for the purpose of visual formatting.

Overview:

Many people who are not viewing the page visually or are not able to interact with the page with a mouse, require tables used for layout purposes to linearise appropriately in order to hear, or interact with, the page the page in a logical and sensible sequence. (NB. Once user agents adequately support style sheet positioning, tables should not be used for layout.)

Structural markup such as <th> or <caption> is not to be used for presentational purposes in layout tables.

Tools:

• Home Page Reader (HPR)
  • does the page make sense when you listen to it?
• Opera
  • User mode / disable tables
• AIS Accessibility Toolbar:
  • Structure / Table cell order
  • Structure / Simple data table
  • Structure / Table linearisation
• WAVE
  • examine reading order

Demonstration:

A selection of pages were used to demonstrate these tools.

Data Tables

Checkpoints:

• 5.1 (P1) - For data tables, identify row and column headers.
• 5.2 (P1) - 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 (P3) - Provide summaries for tables.

Overview:

Programming techniques exist to add semantic information to data tables that is particularly useful for screen-reader users and other assistive technology users. These techniques also help ensure that table presentation can be controlled via the style sheet, rather than editing each individual header cell.

1. In HTML, use <td> to identify data cells and <th> to identify row or column headers.
2. In complex tables (with two or more heading levels), use the "headers" and "id" attributes, etc, to describe more complex relationships among data.
3. In HTML, use the "summary" attribute of the "table" element (and the <caption> element).

Tools:

• Code examination
  • view the page source code and examine the table markup
  • Block the table section to be examined and view the partial source
    (AIS Accessibility Toolbar - tools / view partial source)
• AIS Accessibility Toolbar
  • Structure / simple data table
  • Structure / complex data table
• the WAVE
  • Examine table information for correct usage

Demonstration:

A selection of pages were used to demonstrate these tools.

Table activities

Layout Table Activity:

Use two or more tools to examine some pages that rely on tables for layout:

• Does a page relying on tables for layout of text or form elements, make sense when the table is 'linearised'?
• In tables used for layout, check that no structural elements such as <th> or <caption> have been used for presentational purposes.

Data Table Activity:

Use one or more tools to examine pages with data tables:

• Check that the <th> element has been used appropriately in simple data tables to indicate column headings AND row headings.
• Check that the "id" and "headers" attributes have been used appropriately on complex data tables, in addition to the <th> element.
• Check that an appropriate summary has been provided for all data tables explaining the layout and structure of the table.
• Check that the <caption> elements has been used (rather than paragraph or heading elements) to provide the caption for the data table.

Conclusion / Summary

You do not know who your users are, or what their requirements may be. All pages need to be designed flexibly to accommodate peoples different visual and browser or assistive technology requirements.