Web Accessibility 3.0

29
Web Accessibility 3.0 Rick Ells [email protected] University of Washington Seattle, Washington

description

Web Accessibility 3.0. Rick Ells [email protected] University of Washington Seattle, Washington. Goal. We are in the business of helping people climb mountains, figuratively speaking. Our work should not put obstacles in their way. What Are We Doing?. Serving our clients - PowerPoint PPT Presentation

Transcript of Web Accessibility 3.0

Page 1: Web Accessibility 3.0

Web Accessibility 3.0

Rick [email protected] of Washington

Seattle, Washington

Page 2: Web Accessibility 3.0

Goal

We are in the business of helping people climb mountains, figuratively speaking. Our work should not put obstacles in their way.

Page 3: Web Accessibility 3.0

What Are We Doing?

• Serving our clients– All of the population of potential clients

• Supporting institutional goals and purposes– Serving all students well, including the

handicapped

• Delivering essential services through the Web– Continually improving service through

effective use of available technologies

Page 4: Web Accessibility 3.0

Web Services

• Modern higher education relies on the Web to do its business

• We have a diverse audience, including people with handicaps

• Our audience is using a growing variety of means to access our services (PDAs, mobiles, laptops)

Page 5: Web Accessibility 3.0

Device Independence"A philosophical rule [that guided the

development of HTML] was that HTML should convey the structure of a hypertext document, but not details of presentation. This was the only way to get it to display reasonably on any of a very wide variety of different screens and sizes of paper."

Weaving the Web - The original design and ultimate destiny of the World Wide Web by its inventor, Tim Berners-Lee

Page 6: Web Accessibility 3.0

Accessibility

• Web technologies are designed to support device independence

• Accessible design is a special case of the the general goal of maintaining device independence

• Device independent approaches are essential to supporting the growing range of devices connecting to Web information and services

Page 7: Web Accessibility 3.0

Making Progress

Down through the Web ages, we have made progress in sustaining and expanding device independence

• Slop Code Age• Tables Age• X-C/P AgeWill we be able to sustain progress as

we begin building Web applications?

Page 8: Web Accessibility 3.0

Slop Code Age

• No DOCTYPE statement

• End tags optional

• No validation

• Non-standard elements

• Heavy use of attributes for color, font, alignment, etc.

• Heavy use of tables (and tables within tables) for layout

Page 9: Web Accessibility 3.0

Tables Age

• May have DOCTYPE statement

• End tags required, except for empty elements

• Heavy use of attributes for color, font, alignment, etc.

• Heavy use of tables (and tables within tables) for layout

• Some validation against standards

Page 10: Web Accessibility 3.0

Typical Tables Layout

Page 11: Web Accessibility 3.0

Problems With Table Age

• Major code bloat

• Tables imposed sequence on content

• Changing presentation required extensive code modification

• Different presentations for different devices impossible

Page 12: Web Accessibility 3.0

X-C/P Age

• DOCTYPE statement always present, preferably XHTML Strict

• Content is in XHTML– Logical markup using element types

according to their semantic role– Headings, paragraphs, lists and list items,

etc.

• Presentation, including layout, controlled with CSS

• All code validated against standards

Page 13: Web Accessibility 3.0

X-C/P

• XML foundation• Separation of content and presentation• Utilization of semantic logical elements

enables efficient presentation control with CSS

• Alternative attributes supporting non-visual adaptive technologies– Alternative texts for non-text elements– Labels bind title to form controls

Page 14: Web Accessibility 3.0

X-C/P Accessibility

• Can be keyboard accessible

• Alternative stylesheets possible for different devices

• Logical structure of elements to help in semantic interpretation and navigation

• Coherent sequence of content

• Page-by-page display

Page 15: Web Accessibility 3.0

Web 2.0

• Strong interest in improving functionality and usability of Web interfaces

• Standardization of XHTML, scripting, and XML makes possible reliable dynamic modification of page content between page loads with most graphical browsers– AJAX, ATLAS, Dojo, Bindows – FLEX, Flash - add rich media content

Page 16: Web Accessibility 3.0

AJAX

From: Ajax: A New Approach to Web Applications

Page 17: Web Accessibility 3.0

AJAX Enhancements

Page 18: Web Accessibility 3.0

Accessible Web 2.0?• Most current adaptive technology for the

Web is page oriented• Web AT often “scrapes” a copy of the

page on load and is not aware of subsequent changes made in page content– Does not directly monitor the DOM

• How can a voice browser signal changes on a page and direct user to what has changed?

• Houston, we have a problem!

Page 19: Web Accessibility 3.0

Accessible UIs Exist• User Interfaces that work with AT

– Gnome Accessibility Toolkit, Microsoft Activite Accessibility, Java Accessibility API

• Features– Standardized roles for interface divisions– Standardized properties for elements– Focus management– Interaction model– Device navigation mappings– Semantics interpretation– Change notification

Page 20: Web Accessibility 3.0

Progressive Enhancement

• Build a foundation of standards based, semantic, validated, accessible content and function

• Enhance with rich media– Do it in a way that users can fall back

to the accessible foundation if the rich media does not work for the AT

Page 21: Web Accessibility 3.0

What is a Web App?

• If important content is being manipulated between page loads, you have a Web application– Graphics– Content

• Evaluate by 1194.21 and WCAG2

Page 22: Web Accessibility 3.0

AT Problems

• Adaptive Technology is not ready– Still page-by-page oriented– Often not standards based

• AT is often developed by small companies for small markets– Do not have deep pockets or large developer

communities to share the load

• AT is often expensive– Once acquired, users are often slow to

upgrade it

Page 23: Web Accessibility 3.0

Implications for Higher Ed• Move carefully on rich media

– Explore progressive enhancement– Learn about Web applications

• Are Web applications really needed, relative to our goals and values?

• Can progressive enhancement methods meet our needs?

• How can we move forward in improving usability and functionality of our apps in a field still being defined?

Page 24: Web Accessibility 3.0

Accessible Web Apps

Needed: A working contract between the Web page and AT– Notifying AT of changes and their

location– Managing focus in a way that can be

followed by AT– Standard roles for document parts

Work is underway in the W3C Dynamic HTML Working Group on these needs

Page 25: Web Accessibility 3.0

Things Can Fly Apart

As Web apps are created, accessibility could be diminished for other reasons

• Losing semantics

• Narrow technical perspective (silo thinking)

• Toolkit bias

• Vague direction from management

Page 26: Web Accessibility 3.0

Losing Semantics<div class="question">

<div class="question_content"><label for="element_3">

<strong>How do you expect to apply the knowledge and insights gained from this training?</strong></label></div><div class="p_question_input"><textarea id="element_3" name="element_3" cols="80" rows="5"></textarea></div>

</div>Some developers simply create divs with presentation

properties, avoiding semantic elements. With only class or id names, how can AT know the semantic role of a div?

Page 27: Web Accessibility 3.0

Accessible Web 3.0

• Full utilization of XHTML/CSS for Web page design

• Semantic ontologies

• Standard role naming

• Disciplined use of scripting methods

• Mature interoperative contracts between Web applications and clients

Page 28: Web Accessibility 3.0

Other Thoughts

• We need a Gecko-like project to create a standard Open Source adaptive technology engine

• We need a better understanding of non-graphical ways of interacting with processes in an application– Is page model appropriate? What

about a process semantic ontology?

Page 29: Web Accessibility 3.0