Transcript WWW2003: Accessibility Panel Session - All slides

Web Accessibility:
Will WCAG 2.0 Better Meet
Today’s Challenges?
Brian Kelly
UK Web Focus
UKOLN
University of Bath
UK
[email protected]
Jenny Craven
CERLIM
Manchester Metropolitan
University
UK
[email protected]
1
About Us
Brian Kelly:
• Adviser on Web issues to UK Universities
• Active in Web since January 1993
• Attended opening WAI meeting
Jenny Craven:
• Researcher in CERLIM, Manchester Met. University
• Project work includes:
• NoVa (Non-Visual Access to the digital library) project to
investigate usability of \Web-based resources by people
witn visual impairments
• REVIEL (REsources for Visually Impaired users of the
Electronic Library) project which explored the accessibility
of library OPACs & other electronic library services
• Supporting study for DISinHE which investigated
awareness and use of accessibility design standards in
UK higher education
2
Our Aims
We are:
• Supporters of WAI and its activities
• Acknowledge the work WAI has done in raising
the importance of Web accessibility worldwide
• Informed by our user communities of challenges
and issues faced in implementing WAI guidelines
In this panel session we will:
• Report on experiences of our user communities
• Highlight concerns which have been expressed
Our aim is to:
• Share these concerns
• See if WCAG 2.0 addresses our concerns
• Facilitate open discussion
Note – we may mention common misconceptions about WAI
3
Contents
Brian Kelly:
• Introduction
• What's Happening?
• Survey of UK University Home Pages
• Reports From Other Sectors
• Typical Problems
Jenny Craven:
• Accessibility / Usability conflicts
• Design issues
• User issues
• What makes a Web site accessible and usable?
• Conclusions: thinking about accessibility and
usability
4
What's Happening?
UK University Home Pages
In Sept 2003 survey of accessibility of 160+ UK
University entry points carried out
• Used Bobby (to report on problems which an
automated tool could spot)
• How many WAI AA pages were found?
The survey found:
• Only four entry points complied with AA
• One was a JavaScripted page so isn't accessible
The UK HE community is generally aware of and
supportive of WAI issues, uses email lists to discuss
issues and share solutions (esp. in light of legislation
introduced in Sept 2002). So why this low figure?
See <http://www.ariadne.ac.uk/issue33/web-watch/>
5
What's Happening?
Scottish Political Parties
Survey of the accessibility of 8 parties standing in May
2003 Scottish Parliamentary elections carried out (by
David & Martin Sloan)
Four parties' home page failed Cynthia Says test and
manual testing found that all have accessibility
problems across the Web sites:
• missing ALT tags, contrasts, graphical navigation,
poorly implemented frames, non-compliant HTML,
PDF files, …
A number of political parties pledged support for
accessibility, the Web sites had been developed for the
election and had a high profile. So why the poor
findings?
See <http://www.dmag.org.uk/election/>
6
What's Happening?
RNIB Web Site
Bobby was used on 7 May 2003 to test the RNIB
home page at <http://www.rnib.org.uk/>
Two priority 2 errors were found
Is the RNIB home page really inaccessible?
Similar findings have been reported for other
high-profile accessibility organisations
7
Concerns
The Context
One University Web manager, following survey
publication, said:
"I too have been struggling with just how rigorously the
WAI guidelines should be implemented … I certainly
aspire to comply as full as I can with the WAI
guidelines but …"
• Some guidelines are too theoretical
• I will have a pragmatic approach:
• Will use tables for positioning
• Will not associate form controls for search
boxes
• Will not necessarily nest headers correctly
• …
These are seen as WAI
requirements. Are they?
8
Concerns
Specific Problems
Typical problems reported by Bobby's
automated testing:
• Missing ALT text
• Missing DOCTYPEs
• Use of absolute positioning
• Repeated link phrases
The justifications for these requirements is well-known
They could be fixed easily for an entry point
But:
• What about workflow issues
• What about tools used today
• Are there usability issues?
9
Typical Problems
MS Office Case Study
A typical organisation (including universities):
• Has significant investment in Microsoft Office
products
• Has conservative users who typically won't
appreciate new tools being forced on them
In MS Word / PowerPoint:
• How many users will know how to add ALT text to
images?
• How many would use this option if they knew
about it?
If PowerPoint presentations are held on the Web primarily for file delivery
with little expectation of use by others should (a) effort be spend on ALT
tags, (b) do as at present or (c) remove files from Web site?
10
Typical Problems
Using A Text Editor
Many experienced Web authors / software developers
may use a text editor in preference to a HTML
authoring tool (I use HTML-kit)
This should be more usable these days (just create
simple HTML elements, and leave formatting to a CSS
file)
But:
• Isn't it too difficult to maintain ids for cell elements
in complex tables
• Isn't it worse to get ids wrong than not have
them?
Should the WAI guidelines be explicit on this point?
How will users of text editors react?
11
Typical Problems
Large Web Sites
A typical university Web site:
• Has devolved authorship
• Uses a wide range of technologies, applications,
etc.)
• Has hundreds of thousands of Web resources
Differing perceptions:
• Web teams would like to install centralised
Content Management Systems to help apply
consistent best practices
• Users typically don't like central service
departments and want to manage their own
resources, use their own favourite applications,
etc.
12
Typical Problems
WAI Compliance Levels
Is it unreasonable to regard:
•
•
•
But:
•
•
WAI A = Good effort
WAI AA = Even better
WAI AAA = Top of the class
Is this really the case?
Aren't some of the AA and AAA requirements
based on assumptions of how the Web will be in
the future?
13
Typical Problems
Too Theoretical?
Are some WAI guidelines too theoretical?
13.2 Provide metadata to add semantic information to
pages and sites. [Priority 2]
For example, use RDF ([RDF]) to indicate the
document's author, the type of content, etc.
Some questions
• How many use RDF today?
• Isn't RDF an unproven technology which is
currently of research interest?
• Isn't this using WAI as a mechanism to promote a
favoured W3C format?
• If I can't / won't do this, will other
Priority 2 requirements be ignored?
14
Typical Problems
Too Theoretical?
Have some WAI techniques not being used sufficiently
to expect widespread use?
1.1 Provide a text equivalent for every non-text
element (e.g., via "alt", "longdesc", or …
But
• longdescr not supported in widely used browsers
• There is little implementation experience:
•
•
•
•
•
Should the file be text, HTML, … (it's not defined)
How will the information be rendered?
Should I provide navigation to the original document?
What about the management of the content?
If it's not widely used, can we implement a better
solution (e.g. based on XLink)
15
Typical Problems
Best Practices Or Today's
Practices?
Does/should WAI:
XML
CSS
SMIL
SVG
RDF
• Act as an evangelist for emerging W3C
technologies?
• Assume that the W3C philosophy is true ("by
following these guidelines content developers can
create pages that degrade gracefully …")
• Address real world concerns in an environment of
broken browsers, commercially driven interests,
proprietary formats, …
G6 Ensure that pages are accessible even when
newer technologies .. not supported
If I use SMIL, how do I dumb things down to HTML?
16
Typical Problems
Cost Of Web Accessibility
MYTH #2: Accessible Web authoring is expensive and
time-consuming
MYTH #3: Web accessibility is too difficult for the
average Web designer
http://aware.hwg.org/why/myths.html#m2
But doesn't:
• #2 ignores the workflow issues
• #2 ignores the documented costs of providing and
maintaining metadata (an ALT tag is metadata)
• #3 ignores the real world difficulties of, say,
deploying CSS
It is acknowledged that
this is not from WAI
Wouldn't it be better to be open about the costs in order
to gain acceptance? We don't pretend that safety in
cars, providing fire safety in building, etc. is cheap.
17
Cost Of Web Accessibility
Diveintoaccessibility.org provides
valuable advice on making Web sites
accessible.
But look at what it describes:
p {font-size: 12px;}
/*/*/a{}
body p {font-size: x-small;
voice-family: "\"}\"";
voice-family: inherit;
font-size: small;}
html>body p {font-size: small;}
/* */
…
1. First, we're defining an absolute size
(12px) for every <p>. All browsers apply this style …
2. Then we include the odd-looking comment "/*/*/". Due to
bugs in Netscape 4, everything between this comment and
the following one will be ignored. That's right, all the
following styles will only be applied in non-Netscape-4
browsers.
3. Immediately after the odd-looking comment, we include an
empty rule "a {}". Opera 5 for Mac is buggy and ignores this
rule (and only this rule). It applies everything else.
18
Conclusions
To conclude:
• Public sector bodies who want to provide
accessible Web sites seem to find it difficult to do
so, even on individual high-profile pages
• The WCAG 1.0 guidelines appear to promote littledeployed and emerging W3C technologies in
additon to mature & well-supported features
• It appears to be difficult / expensive to produce
richly functional & accessible e-learning resources
Or is this taking the WAI WCAG guidelines too literally?
Don't the guidelines do a good enough job in the
majority of cases, and to highlight exceptional cases or
esoteric aspects is to undermine the valuable work that
WAI is doing (and provide a loophole for avoidance)?
19
Web Accessibility:
Will WCAG 2.0 Better Meet
Today’s Challenges?
Accessibility and Usability
Jenny Craven,
Research Associate,
CERLIM
With acknowledgements
to David Sloan, DMAG
and Neil Witts, TechDis
for their input
Contents
•
•
•
•
•
Introduction
Accessibility / Usability conflicts
Design issues
User issues
What makes a Web site
accessible and usable?
• Conclusions: thinking about
accessibility and usability
20
Quotes about Web usability:
“you sighted people just go click click click and
there’s the answer – while I’m still looking for the
first …. link!”
“It tells me that there is a text-only version, I tend to
steer clear of them because they are often not as up
to date as the graphical version”
“I could tell it was a link, but I wasn’t sure where I
was going”
“I often just click on text because I think it will be a
link”
21
Accessibility/usability conflicts
Design Issues:
• Inappropriate or unhelpful alternative text for
graphics, images etc – is ‘photo’ enough? Is a
literal description of every image always helpful?
• Inappropriate or unhelpful text for hypertext links –
to ‘click here’ or not to ‘click here’
• Language – accessibility and understanding: are
they really the same thing?
• Interactive elements e.g. e-learning packages,
quizzes – people behave in different ways.
22
To ‘Click here’ or not to ‘Click
here’
23
E-Learning Concerns
Visualisation
"I use a Flash animation of the HIV virus in my course.
I've been told that it must be usable in a speaking /
text browser. I've also been told that I must use open
W3C technologies. What should I do?"
Quizzes
"I have online quizzes in which users must describe
features in common in two photos. I've been told I
must provide meaningful information in ALT tags. But
this would give the answer away! What should I do?"
I could use a real world alternative which provides an equivalent
learning experience. This seems acceptable under UK SENDA
legislation – but is it OK for the Web site to be inaccessible (to 3rd
parties) but to have an accessible course? If not, should I password
protect the Web site (so it's equally inaccessible to everyone!)?
24
E-Learning Concerns
How do we make
this interactive
exercise
interactive?
Can we design a
single system
which is accessible
and as usable as
this one?
Won't it be difficult
and expensive to
do this?
25
Accessibility / usability conflicts
User Issues:
• Parallel design vs Linear navigation…
 200 links on one page.
 Does not follow a logical order
• Intelligibility of information in audio, e.g….
‘eResources’ – ‘error sources’,
‘British Journal’ – ‘British Hournal’
• Different levels of user expertise.
• Different assistive technologies.
• Is it possible to design a web interface
that suits the needs of everybody?
26
So, what makes a Web site
‘accessible’ and ‘usable’?
• Meeting basic accessibility requirements,
e.g. ALT Text? Appropriate language for
links?
• Offer Text-Only sites e.g. Tesco Access?
• Bobby (or similar) approved?
• Meeting legal requirements? e.g. DDA,
SENDA, 508?
• WAI compliance?
27
Text-Only issues
• Automatically generated Text-Only sites are
only as accessible as the original.
• The same applies to hand coded Text-Only
sites, but also have to be updated alongside
the original – worries that they may not be
kept up-to-date.
• Text-Only may conflict with the ethos of
universal design.
28
Accessibility checker issues
• Automated Web accessibility checkers such
as Bobby DO NOT guarantee accessibility.
• Belief that because an automated checker
says it’s ok, then it’s accessible.
• Accessibility does not equal usability.
29
Logo issues
30
Logo issues
• Automated testing does not provide a
comprehensive solution to accessibility.
• Changes to the website and/or to person
responsible for the site my impact on
accessibility – but the logo may remain.
• How do logos relate to legal issues? Is it safe
to assume a site is DDA/SENDA (or
equivalent) compliant because it displays a
logo?
31
Legal Issues
• Who takes responsibility for implementing Web
accessibility?
• From a legal perspective, how does WCAG 1.0 fit
in with WCAG 2.0?
• If Governments adopt WCAG will they have to
adjust their policies to fit in with changes?
• Will the legal systems of different countries come
into conflict with WCAG?
 e.g. privacy laws differ, what about disability
and web accessibility?
32
WAI issues
• WAI compliance does not guarantee accessibility for
an individual.
• WAI are ‘guidelines’ and therefore may be open to
interpretation.
• Focussing on guidelines and checklists alone is not
enough.
• If Plug-Ins etc need installing, will this conflict with
WAI guidelines?
• Attempting to comply with AAA WAI
recommendations may be too ambitious.
• How do the WAI guidelines help people understand
further about accessibility and usabililty? i.e how
and why
33
Thinking about Accessibility
and Usability
• A Web site can comply with open standards.
• A Web site can pass all the automated accessibility
checks.
• A Web site can appear to be accessible
BUT
• An accessible Web site is not necessarily usable.
• The best way to test for usability is by involving the
users themselves.
• Accessibility and usability is an evolving process, not a
static one.
• This should be reflected in policies.
So, how will WCAG meet today’s challenges?
34
Unresolved Issues (1)
Issues for general discussion:
• Policy issues – ‘My institution’s accessibility policy
does not comply fully with the WAI guidelines’, ‘WCAG
reflects US culture which is not appropriate for my
organisation’.
• User issues – ‘I know it is possible to change the
browser settings, but I don’t know how to’, ‘my screen
reader is an old version – but I can’t afford to upgrade’
• Awareness issues – not just how, but also why.
• Implementation issues - who is responsible for
implementing the WAI guidelines?
• From a legal perspective, how does WCAG 1.0 fit in
with WCAG 2.0?
• How will cultural and legal differences be resolved?
• Political issues – uncertainty, changing alliances etc.
35
Unresolved Issues (2)
Issues for general discussion:
• Cost of implementing Web accessibility
• Tackling "low-hanging fruit" versus
everything
• Accessibility of proprietary formats
• Too theoretical?
• Usability issues
• Value of logos
• …
36