Guidelines-for-Developing

Download Report

Transcript Guidelines-for-Developing

Guidelines for Developing an AAC-Enabled
World Wide Web
David Poulson and Colette Nicolle
Ergonomics and Safety Research Institute (ESRI)
Loughborough University, UK
[email protected]
[email protected]
1
EU WWAAC (World Wide Augmentative and
Alternative Communication) project
www.wwaac.org/
Aim:
to make the electronic highway (in particular the
World Wide Web and e-mail) more accessible for
people with communication difficulties, in
particular those who use graphic symbol-based
augmentative and alternative communication
(AAC) systems
But:
non-symbol users could also benefit from easier
access to Internet services.
2
Simulated web browser
• Limited user trials thus far
• Users with
– personal experience in Web browsing
– A receptive ability such that they understand
the concepts of the Internet and the World
Wide Web (WWW)
3
4
From Users’ Requirements to AAC-enabled
Web Design
• Study described in Clarke et al, 2002
• Identified some of the requirements for
developing AAC enabled WWW pages
• Insights into the likely needs for guidance
on Web design in this sector
5
Some critical findings from user requirements
• Development of good screen reading software and support for
speech output, e.g., embedded control elements for speech
synthesis software, as well as support for different national
languages
• Simplified WWW browsers (entering URLs in particular)
• Development of strategies for navigation—reminding users
where they are and have been
• Guidance in the use of symbols versus text
• Information on the design implications of different communication
problems
6
Existing WWW Design Guidelines
Significant number of guidelines for general
accessibility exist: especially with regard to visual
impairment and motor impairment—for example
• to help ensure that tables and complicated text can
be accessed by a screen reader, and
• that text descriptions of images are always provided
7
Some specific guidance exists, e.g.
8
Some specific guidance exists, e.g.
9
World Wide Web Consortium–
Web Accessibility Initiative (W3C–WAI)
• W3C created in October 1994 with around 500
member organisations from around the world and
has earned international recognition for its
contributions to the growth of the Web
• WAI, in coordination with organisations around
the world, pursues accessibility of the Web
through five primary areas:
technology, guidelines, tools, education and
outreach, and research and development.
• http://www.w3.org/
• http://www.w3.org/WAI/
10
World Wide Web Consortium–
Web Accessibility Initiative (W3C–WAI)
• Web Content Accessibility Guidelines
(WCAG) 1.0
www.w3.org/TR/WCAG20
and WCAG 2.0 (working draft)
www.w3.org/WAI/GL/WCAG20/
• Authoring Tool Accessibility Guidelines
www.w3.org/TR/ATAG10
• User Agent Accessibility Guidelines
www.w3.org/TR/UAAG10
• XML Accessibility Guidelines (working draft)
www.w3.org/TR/xmlgl
11
Web Content Accessibility Guidelines 2.0
(WCAG 2.0) (working draft as of 12 July 2002)
• Perceivable. Ensure that all intended function
and information can be presented in form(s) that
can be perceived by any user, except those
aspects of the content that cannot be expressed
in words.
• Operable. Ensure that the interface elements in
the content are operable by any user.
• Navigable. Facilitate content orientation and
navigation.
• Understandable. Make it as easy as possible to
understand the content and controls.
• Robust. Use Web technologies that maximize
the ability of the content to work with current and
future accessibility technologies and user agents.
12
Guideline 4: Understandable.
Make it as easy as possible to understand the content
and controls.
• Checkpoint 4.1:
Write as clearly and simply as is
appropriate/possible for the purpose of the
content.
• Checkpoint 4.2:
Supplement text with non-text content.
• Checkpoint 4.3:
Annotate complex, abbreviated or unfamiliar
information with summaries and definitions.
13
Gaps needing to be filled
• Guidelines for the development of generalpurpose WWW sites (refining existing guidelines
where appropriate) so that they will be more
usable by AAC users
• Guidelines for the development of specific sites
intended for AAC users
• Guidelines for the development of adapted Web
browsers for these user groups
14
Plan of Action
• Discussions with the W3C–WAI in order to
develop more specific guidelines that can
easily be integrated with the Web Content
Accessibility Guidelines in accord with
their five design principles
• Evaluation with users of the WWAAC
project’s prototype Web browser which will
be an exemplar of good practice
15
Guideline 4: Understandable
• Checkpoint 4.1: Write as clearly and simply
as is [appropriate / possible] for the
purpose of the content.
• Sample research questions:
As WCAG 2.0 states, 'Specific objective
criteria that could be applied across all
types of content [and users—WWAAC
project comment] are . . . not possible.‘ But
how can Web developers best measure
text complexity for AAC users?
16
Guideline 4: Understandable
• Checkpoint 4.2: Supplement text with nontext content.
• Sample research questions:
Under what circumstances should
auditory or symbol/picture presentations
be used? How can the use of publicly
available ‘concept coding’ enable key
word translation from text into
symbols/images/sounds?
17
Guideline 4: Understandable
• Checkpoint 4.3: Annotate complex, abbreviated
or unfamiliar information with summaries and
definitions.
• Sample research questions:
What guidance is available on developing a text
précis for AAC users? What metadata should
Web authors include so that the page can easily
be summarised and/or translated into symbols?
The W3C currently experimenting with
Annotations, using a browser/authoring tool
called Amaya.
AAC users could choose to see only the
annotations (content in an alternative or
summarised way)
18
Issues
• No comprehensive source of information about the
design of WWW pages for people with learning or
communication difficulties, and even less information
on designing sites to facilitate access by symbol users
• Not efficient use of resources for Web developers
creating general purpose sites to invest a considerable
amount of effort in translating Web content into
symbols.
• Diverse needs of different disability groups make it
difficult to produce general recommendations for WWW
site design, as the needs of one disability group can
conflict with another.
19
20
Summary
• Developers should follow simple guidelines to make
Web sites more accessible to a wide range of
disability groups, including those using AAC systems
– to facilitate access by AAC and symbol users to Web pages
designed to be used by the general public, and
– to develop Web pages specifically for AAC and symbol
users
• Propose that checkpoints within WCAG 2.0 provide
more specific guidance to make all Web sites more
accessible to AAC users, along with success criteria
which should be satisfied to meet the needs of these
users.
21
Summary
• Also a need to develop add-ons to existing
web authoring tools that, e.g., can provide
salient information contained within WWW
pages, including keywords, key information,
headings, and summaries in symbol or other
suitable form.
• Guidelines for specific target groups could
also be included as subsections to, or links
from, the main body of the Web Content
Accessibility Guidelines
22
Thanks to
• EC Information Society Technologies (IST)
Programme
• WWAAC Consortium
– Handicom (The Netherlands)
– DART Regional Children’s Habilitation, Sahlgrenska
University Hospital (Sweden)
– Department of Speech, Music and Hearing, Kungl
Tekniska Hogskölan (Sweden)
– The ACE Centre Advisory Trust (United Kingdom)
– Modemo (Finland)
– MITC (Denmark), and
– Femtio Procent Data (Sweden).
• Wendy Chisholm from the W3C,
co-editor of WCAG 2.0
23