Wipa Seminar WCAG 2.0

Session 1: Moving to WCAG 2.0 Presenter: Roger Hudson Web Usability Web Accessibility 2.0 Seminar November 2008

What is web accessibility? Site accessibility is a measure of how effectively all people, including those with disabilities, are able to access and use web pages. “ The power of the web is in its universality. Access by everyone regardless of disability is an essential aspect .” Tim Berners-Lee Founder of the World Wide Web Director of W3C

Can be used by people with physical and cognitive impairments

Can be used by people in situations where they are unable to use their hands

Can be used by people who are technically and educationally disadvantaged

Are more effective for people who live in remote and regional areas

Are easy for the elderly and novice users to use

Work with the widest range of browsers and other current internet technologies

Will migrate to future technologies

Accessible sites benefit everyone Accessible Sites:

“ The provision of information and online services through the Worldwide Web is a service covered by the DDA (Disability Discrimination Act). Equal access for people with a disability in this area is required by the DDA where it can reasonably be provided.” HREOC Advisory Note Version 3.2, 2002. Accessibility requirements in Australia Section 24 of the Disability Discrimination Act (1992) says that when providing goods or services, it is unlawful to discriminate against a person because of their disability. The Act is interpreted by the Australian Human Rights Commission (formally HREOC) in advisory notes.

“ From 1 December 2000, all websites were to follow the W3C guidelines to a sufficient extent that they pass recognised tests of accessibility.” Level of Compliance: “ The Human Rights and Equal Opportunity Commission's view is that compliance with the W3C WCAG 1.0 guidelines to the Single-A level (Priority 1) is a minimum rather than a desirable outcome. Websites that demonstrate such compliance may still be difficult or impossible to access for many users with a disability.” Australian Government Information Management Office: Guide to Minimum Website Standards – Accessibility, April 2003 www.agimo.gov.au/practice/mws/accessibility Also an AGIMO requirement

Moving to WCAG 2.0 Reference document version: Proposed Recommendation 3 November 2008.

WCAG process When will WCAG 2.0 become a W3C Recommendation?

WCAG 1.0 released May 1999

Started Work on WCAG 2.0 in 2000

Nine working drafts of WCAG 2.0

‘ Last Call’ draft released April 2006

Many concerns raised in the responses to the Last Call draft

A new “second Last Call working draft” released on 17 May 2007

Revised ‘Last Call’ draft released 11 December 2007

W3C Candidate Draft released 30 April 2008 (final draft stage)

Test WCAG 2.0 implementation process

November 3 – W3C Proposed Recommendation released

Time to move forward

Development of WCAG 2 has been a long and at times contentious process

Extensive consultation with the web industry and accessibility advocates

Battles won, battles lost and compromises made

This presentation will not be a look back to the past. My aim is to provide an overview of the changes between WCAG 1.0 and WCAG 2.0

WCAG 2 Overview Checking out the features …

WCAG 1 – Recap

14 Guidelines, containing

65 Checkpoints

WCAG 1.0 has: Priority 1 : Designers must satisfy this checkpoint for all people to access the content. (16 checkpoints) Priority 2 : Designers should satisfy this checkpoint to remove significant barriers. (30 checkpoints) Priority 3 : Designers may address this checkpoint to further improve accessibility. (19 checkpoints) Each checkpoint has a Priority Level.

POUR - four principles of accessibility

Content must be P erceivable

Interface components in the content must be O perable

Content and controls must be U nderstandable

Content should be R obust enough to work with current and future user agents (including assistive technologies)

WCAG 2 Structure – POUR Principles Web Content Accessibility Guidelines 2.0 W3C Proposed Recommendation (3 November 2008) http://www.w3.org/TR/2008/PR-WCAG20-20081103/

WCAG 2 Structure – Guidelines WCAG 2 Guidelines Within the 4 Principles, 12 Guidelines provide the requirements for making content more accessible to people with different disabilities. Principle 1: Perceivable – Information and user interface components must be presentable to users in ways they can perceive. Guideline 1.1 Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language Guideline 1.2 Time-based Media: Provide alternatives for time-based media Guideline 1.3 Adaptable: Create content that can be presented in different ways (for example simpler layout ) without losing information or structure. Guideline 1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from background

WCAG 2 Structure – Success Criteria Success Criteria The 12 Guidelines contain a total of 61 Success Criteria. Success Criteria can be used for specifying website requirements and conformance testing.

WCAG 2 Success Criteria for 1.3 Principle 1: Perceivable – Information and user interface components must be presentable to users in ways they can perceive. Guideline 1.3 Adaptable: Create content that can be presented in different ways (for example simpler layout ) without losing information or structure. Success Criteria 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. How to meet 1.3.1 1.3.2 Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. How to meet 1.3.2 1.3.3 Sensory Characteristics: Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. How to meet 1.3.3

WCAG 2 Structure – Success Criteria Techniques Techniques Sufficient Techniques: Ways of meeting the Success Criteria. Advisory Techniques: Goes beyond what is required to help authors better address the Guideline.

Success Criteria

1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. How to meet 1.3.1

16 Sufficient Techniques for very different HTML issues, for example:

Using caption elements to associate data table captions with data tables

Using label elements to associate text labels with form controls

Using ol, ul and dl for lists

Using h1-h6 to identify headings

Guideline 1.3

“ Normative” and “Informative” Normative Document is the “WCAG 2.0 W3C Recommendation”. It contains the Principles, Guidelines and Success Criteria that specify what is required to comply with the guidelines. Informative Documents “Understanding WCAG 2.0” and “Techniques for WCAG 2.0” provide advice on how to meet these requirements. Testable and Flexible Success Criteria are stable statements that can be applied to different technologies and are testable by machines and/or humans. Informative techniques are provided for different technologies and will evolve over time as new technologies emerge.

WCAG 1 - Technology specific WCAG 1.0 was specific to W3C formats like HTML and CSS Guideline 11. Use W3C technologies and guidelines. Checkpoint 11.4 “ If you cannot create an accessible page, provide a link to an alternative page that is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible page. [Priority 1]”

WCAG 2 - Technology Neutral WCAG 1.0 was specific to W3C technologies like HTML and CSS WCAG 2.0 applies to all W3C and non-W3C technologies so long as their use is accessible. Guideline 11. Use W3C technologies and guidelines. Checkpoint 11.4 “ If you cannot create an accessible page, provide a link to an alternative page that is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible page. [Priority 1]”

Web content technology must meet two requirements to qualify as an accessibility-supported Web content technology :

The way that the Web content technology is used must be supported by users' assistive technology.

AND …

Accessibility Supported # 1 Source: http://www.w3.org/TR/2008/PR-WCAG20-20081103/#accessibility-supporteddef

The technology is supported natively in widely-distributed user agents that are also accessibility supported;

OR

The technology is supported in a widely-distributed plug-in that is also accessibility supported;

OR

The content is available in a closed environment where the required technology is also accessibility supported;

OR

The user agent that supports the technology is accessibility supported and equally available to a person with a disability as it is for someone without a disability.

AND

The Web content technology must have accessibility-supported user agents available to users. This means that at least one of the following statements is true:

Accessibility Supported # 2

What technologies are Accessibility Supported?

W3C does not specify how much support by assistive technologies (e.g. Screen Readers) is necessary for the particular use of a Web technology (e.g. FLASH) to be considered “accessibility supported”.

The term "accessibility supported" does not imply all uses of the web content technology are accessible.

Only “ accessibility supported ways of using technologies ” can be relied upon to satisfy the WCAG Success Criteria.

The W3C expects that lists will emerge of technologies which are recognised to be accessibility supported.

PDF support

Levels of Conformance WCAG 2.0 has no direct equivalent to the WCAG 1.0 Priority Levels. WCAG 2.0 Success Criteria are organised into three levels of conformance. “ Level A: For Level A conformance (the minimum level of conformance), the Web page satisfies all the Level A Success Criteria, or a conforming alternate version is provided. Level AA: For Level AA conformance, the Web page satisfies all the Level A and Level AA Success Criteria, or a Level AA conforming alternate version is provided. Level AAA: For Level AAA conformance, the Web page satisfies all the Level A, Level AA and Level AAA Success Criteria, or a Level AAA conforming alternate version is provided.” Source: http://www.w3.org/TR/2008/PR-WCAG20-20081103/#conformance-reqs

Conformance requirements

Conformance level – one of the Success Criteria conformance levels is fully met.

Full pages – conformance is for full web pages only and can’t exclude parts of the page.

Complete processes – when a web page is part of a continuous process, all pages in the process must conform at the specified level.

Accessibility supported ways of using of technologies – only accessibility supported uses are relied on to meet the Success Criteria.

Non-interference - technologies that are not accessibility supported, or used in a non-conforming way, do not block the ability of users to access the rest of the page.

Five requirements must be met for content to be classified as 'conforming' to WCAG 2.0.

Let’s look under the bonnet

“ Guideline 10 Use interim solutions: Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly .” WCAG 1 “Until user agents …” WCAG 1.0 Guideline 10 contains five WCAG 1.0 Checkpoints, each starting with the phrase, “Until user agents”

WCAG 2 Success Criteria compliance assumes user agent support . No explicit Success Criteria for the following WCAG 1 Checkpoints No more “Until user agents …” 10.2 Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned. 10.3 Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative for all tables that lay out text in parallel, word-wrapped columns. 10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas. 10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters between adjacent links.

Support for scripting WCAG 1.0 Checkpoint 6.3 “ Ensure that pages are usable when scripts, applets etc are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. [Priority 1]” WCAG 1 assumed accessibility problems with JavaScript Some JavaScript is now well supported by browsers and assistive technologies. Some JavaScript can improve the accessibility of sites for some users. WCAG 2 does not automatically preclude the use of JavaScript. There is no WCAG 2 equivalent for Checkpoint 6.3 .

“ SCR14: Using scripts to make nonessential alerts optional”

" SCR19: Using an onchange event on a select element without causing a change of context”

" SCR21 : Using functions of the Document Object Model (DOM) to add content to a page”

JavaScript can be accessible Not all JavaScript is accessible, it depends what you do with it. The specific use JavaScript must be deemed “accessibility supported” Only Accessibility supported uses of technologies can be relied on to meet WCAG 2 Success Criteria. ( Conformance Requirement 4 ) WCAG 2 techniques include these Sufficient Techniques (scripting) that have been tested with screen readers: Source: http://www.w3.org/TR/WCAG20-TECHS/client-side-script.html

Identifying form errors and providing help to correct them. ( Guideline 3.3 Input Assistance: Help users avoid and correct mistakes) Using an onchange event in a Select menu to change the content of another Select menu. ( Guideline 3.2 Predictable: Make Web pages appear and operate in predictable ways) Showing or hiding sections of the page (not AJAX) ( Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard) ( Guideline 2.4 Navigable: Provide ways to help users navigate, find content and determine where they are) More information: “Accessible Forms Using WCAG 2.0” http://www.usability.com.au/resources/wcag2/ (Thanks to Chris Bentley, Andrew Downie and Russ Weakley) Three helpful JavaScript techniques

WAI-ARIA “ WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies .” WAI-ARIA Overview http://www.w3.org/WAI/intro/aria.php Additional accessibility features allow assistive technologies to interact with more advanced and complex user interface controls. ARIA Examples: Toggle button: http://www.paciellogroup.com/blog/misc/ARIA/togglebutton.html Tri-state checkbox: http://www.paciellogroup.com/blog/misc/ARIA/tristatecheck.html Slider control: http://www.paciellogroup.com/blog/misc/ARIA/slider/ Source: http://www.paciellogroup.com/blog/misc/ARIA/atmedia2008/

Form labels and controls WCAG 1.0 Checkpoint 10.2 “ Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned. [Priority 2]” WCAG 1.0 Checkpoint 12.4 “ Associate labels explicitly with their controls. [Priority 2] ” No WCAG 2 equivalent for Checkpoint 10.2. These two Checkpoints require all form inputs to have a label that is correctly positioned and explicitly associated with the control (input).

“ 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)” Techniques: H44: Using label elements to associate text labels with form controls H65: Using the title attribute to identify form controls when the label element cannot be used In WCAG 2: Identifying form controls in WCAG 2 More information: “Accessible Forms Using WCAG 2.0” http://www.usability.com.au/resources/wcag2/ NB: Use of the form control “title” attribute is deemed a Sufficient Technique, " when the visual design cannot accommodate the label or where it might be confusing to display a label ".

Two useful uses of the “title” attribute for forms <input type="text" title="site search" name="query" id="q" value=""> Offing “Off-left” with “Title”

Two useful uses of the “title” attribute for forms <input type="text" title="site search" name="query" id="q" value=""> Offing “Off-left” with “Title” <th>Personal savings</th> <td align="center">$1,200.00</td> <td align="center"><input type="text" title="deposit amount for personal savings" value=""></td>

New form requirements Error Detection and Messages WCAG 2 directly addresses the prevention, detection and correction of errors in forms. "Guideline 3.3 Input Assistance: Help users avoid and correct mistakes" Guideline contains six Success Criteria (two at Level A). Timed responses Setting of time limits for forms is likely to exclude some users with certain disabilities from completing the form in the required time. “ Guideline 2.2 Enough time: Provide users with disabilities enough time to read and use content” Guideline contains five Success Criteria (two at Level A).

“ 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)” Techniques: H51: Using table markup to present tabular information H63: Using the scope attribute to associate header cells and data cells in data tables H43: Using id and headers attributes to associate data cells with header cells Data tables: Associating header and data cells WCAG 1.0 Checkpoint 5.1 “ For data tables, identify row and column headers. [Priority 1]” WCAG 1.0 Checkpoint 5.2 “ For data tables with two or more logical levels of row or column headers, use markup to associate data cells and header cells. [Priority 1]” In WCAG 2 replaced with:

Data tables: Re-cap ‘id’ and ‘headers’ <th colspan="2" id="domestic"> Domestic </th> <th id="apples-dom"> Apples </th> <th id="sydney" colspan="5"> Sydney </th> <th headers="sydney" id="wholesale-sydney"> Wholesale </th> <td headers="domestic apples-dom sydney wholesale-sydney"> $1.00 </td> Heading cells, each with a unique “id” value. Data cell, with “headers” value that matches the “id” values of the related heading cells. Code excerpts (sections only) Source: http://www.usability.com.au/resources/tables.cfm

“ 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)” Techniques: H73: Using the summary attribute of the table element to give an overview of data tables H39: Using Using caption elements to associate data table captions with data tables Data tables: Summary attribute and Caption element WCAG 1.0 Checkpoint 5.5 “ Provide summaries for tables. [Priority 3] ” In WCAG 2, table ‘Summary’ and ‘Caption’ may now be required for Level A compliance

Orange and apple prices <table summary ="Wholesale and retail prices of imported and domestic oranges and apples in Sydney and Melbourne. Table has two levels of column and row headings"> < caption > Orange and apple prices < /caption > <thead> … rest of table Data tables: Summary and Caption example

WCAG 1.0 Checkpoint 13.1 “ Clearly identify the target of each link. [Priority 2]” “ 2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone, or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. (Level A)” “ 2.4.9 Link Purpose (Link Only): A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general. (Level AAA)” In WCAG 2 replaced with two Success Criteria at different compliance levels. Identifying the purpose (target) of links

WCAG 1.0 Checkpoint 12.3 Divide large blocks of information into more manageable groups where natural and appropriate. [Priority 2] Bypassing blocks and skip links WCAG 1.0 does not address bypassing repeated blocks of text. WCAG 2.0 promotes the use of “skip links” “ 2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)” Techniques: G1: Adding a link at the top of each page that goes directly to the main content area G123: Adding a link at the beginning of a block of repeated content to go to the end of the block G124: Adding links at the top of the page to each area of the content

WCAG 1.0 Checkpoint 2.2 “ Ensure that foreground and background colour combinations provide sufficient contrast for viewing by someone having colour deficits. [Priority 2 for images Priority 3 for text]”

1.4.3 Contrast (Minimum): Visual presentation of text and images of text has a contrast ratio of at least 5:1, except for the following: (Level AA)

Large print: Contrast ratio of at least 3:1

Incidental: Text or images of text that are decorative or an incidental part of a picture have no contrast requirement

Logotypes: Text in a logo or brand has no contrast requirement

1.4.6 Contrast (Enhanced): Visual presentation of text and images of text has a contrast ratio of at least 7:1, except for following: (Level AAA)

(as above)

In WCAG 2 replaced with: Colour contrast

Situation A: text is less than 18 point if not bold and less than 14 point if bold G18: Ensuring that a contrast ratio of at least 5:1 exists between text (and images of text) and background behind the text Situation B: text is as least 18 point if not bold and at least 14 point if bold G145: Ensuring that a contrast ratio of at least 3:1 exists between text (and images of text) and background behind the text Colour techniques WCAG 2 uses a luminosity formula for determining contrast ratio (rather than the colour and brightness algorithms used in WCAG 1) WCAG 2 also takes into account the size of the text Key Techniques (same for both Success Criteria):

Paciello Group: Colour Contrast Analyser (download) http://www.paciellogroup.com/resources/contrast-analyser.html Colors on the Web: Color Contrast Analyzer (online) http://www.colorsontheweb.com/colorcontrast.asp Juicy Studio: Luminosity Contrast Ratio Analyser (online) http://juicystudio.com/services/luminositycontrastratio.php Trace: Index of Color Contrast Samples http://trace.wisc.edu/contrast-ratio-examples/Sample_Text_ColorsOnWhite.htm Test palette Color deficit samples Colour – some useful tools

Audio material WCAG 1 contains very little advice about making video and audio material accessible WCAG 2 has Guidelines and Success Criteria that directly address the use of this material, including: “ 1.4.2 Audio Control: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A)” G60: Playing a sound that turns off automatically within three seconds G170: Providing a control near the beginning of the Web page that turns off sounds that play automatically G171: Playing sounds only on user request Techniques:

Primary documents: Web Content Accessibility Guidelines 2.0 (Proposed Recommendation) http://www.w3.org/TR/2008/PR-WCAG20-20081103/ Understanding WCAG 2.0 (3 November) http://www.w3.org/TR/UNDERSTANDING-WCAG20/ Techniques for WCAG 2.0 (3 November) http://www.w3.org/TR/WCAG20-TECHS/ WCAG 2.0 Quick Reference (3 November) http://www.w3.org/WAI/WCAG20/quickref/ Key WCAG 2 documents See Also: Migrating from WCAG 1.0 to WCAG 2.0 http://wipa.org.au/papers/wcag-migration.htm

Thank you Roger Hudson Web Usability www.usability.com.au [email_address]