Web Accessibility: Beyond WAI

1
Web AccessibilityBeyond WAI
About The Speaker Brian Kelly is a Web adviser
to UK HE/FE and MLA communities. He has attended
several W3C WAI meeting, has published a survey
of the accessibility of UK University entry
points and organised a panel session with Judy
Brewer, head of WAI at WWW 2003 conference.

• Brian Kelly
• UKOLN
• University of Bath
• Bath

Email B.Kelly_at_ukoln.ac.uk
UKOLN is supported by
2
Web Accessibility

• Areas of agreement
• Accessibility of digital resources greatly
  benefits many users and potential users
• Organisations (especially publically-funded
  bodies) should seek to maximise the accessibility
  of their services
• W3C WAI has been tremendously successful in
• Raising awareness of accessibility issues for
  digital resources
• Developing various guidelines for helping Web
  developers, software developers, etc.

But we face some challenges
3
Challenges
Challenges

• We are now finding
• Awareness of limitations of testing tools
• Awareness of difficulties (and costs) in
  implementing accessibility across large Web sites
• Awareness of problems with browsers
• Slow take-up of new W3C formats (SMIL, SVG, ...)
• Better support for accessibility in proprietary
  formats (e.g. PDF, Flash) and operating systems
  (e.g. Windows XP)
• Concerns over WAI WCAG guidelines
• Concerns over e-learning accessibility
• Uncertainty of the scope of legislation (what are
  "reasonable measures"?)

4
Challenges Testing Tools
Challenges

• Accessibility testing tools
• Bobby is widely-known but has severe limitations
• Organisations can be over-reliant on Bobby
• Dangers of "Bobby-approved" (and other) logos
• Bobby error messages can be confusing
• We need
• Advice on systematic testing processes
• Incorporation of manual testing processes
• Raise awareness of limitations of Bobby, etc.

This is not an insurmountable problem. Advice is
available e.g. advisory bodies such as TechDis,
documents such as lthttp//www.ukoln.ac.uk/qa-focus
/documents/briefings/briefing-12/gt (and
briefing-02, briefing-57, ) etc.
5
Challenges Scope
Challenges

• When
• Developing policies
• Using testing tools and processes
• we are facing with issues of
• Definition of our Web site
• Public Web site(s)
• Static Web site(s)
• Personalised pages
• Pages with content from remote services
• Extent of our Web site
• Organisational area
• Everything (e.g. entries on bulletin boards,
  personal pages, )
• Integration with backend services (e.g. Library
  catalogue)

6
Challenges Browsers
Challenges

• Issues
• When does the "until user agents " clause apply?
• What is our policy on old / broken browsers?
• Is it reasonable to expect users to make
  adjustments?
• Is our policy driven by usage or by compliance
  with standards?
• Are we allowed to exploit new technologies?
• What do we do for browsers on special devices
  (PDAs, digital TVs, )?

The (well-designed, accessible)
www.accessifyforum.com has usability problems on
my Netgem digital TV box. Is this (a)
Accessifyforums problem (b) Netgems problem or
(c) an inevitable teething problem of new
technology?
7
Challenges New Formats
Challenges

• W3C are developing richer and more accessible
  formats such as SMIL and SVG.
• But
• What about support for browsers which don't
  support such formats?
• Will we have to support both old and new formats?
• When will we be in a position to exploit such
  formats?
• Will concerns over accessibility legislation
  hinder the deployment of more accessible formats!

8
Challenges WAI Guidelines
Challenges

• Are the W3C WCAG 1.0 guidelines
• Too theoretical?
• Possibly conflicting with usability?
• Difficult to understand?
• Ambiguous?
• WAI WCAG 2.0 is being developed
• How does this affect current guidelines?
• How will this affect legal issues?

9
Challenges Proprietary Formats
Challenges

• WAI WCAG AAA guidelines requires files in
  proprietary formats to be also available in an
  open W3C format
• This seems to affect use of
• Interactive formats such as Flash
• Popular document formats such as PDF
• Use of Web as a document transfer tool for, say,
  MS Office files
• Has W3C WAI extended its remit from supporting
  accessibility to mandating use of its formats and
  its philosophy?
• Is this desirable? Should it be embedded in
  legislation?

WAI AAA bans use of MS Word. Is this true?
The fact that MS Word files can be accessible is
irrelevant.
10
The Context
Challenges

• One University Web manager, following publication
  of survey of UK University home pages 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

11
Too Theoretical?
Challenges

• 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.

• Is this really about accessibility? What
  practical benefit will it bring?
• How many use RDF today?
• Isn't RDF an unproven technology which is
  currently of research interest?
• Isn't this using WAI as a mechanismto promote a
  favoured W3C format?
• If I can't / won't do this, will other Priority
  2 requirements be ignored?

It is acknow-ledged that RDF is an example
12
Too Theoretical?
Challenges

• 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?

Should Web accessibility guidelines be based on
empirical findings or an architectural vision?
13
Cost Of Web Accessibility
p font-size 12px ///a body p font-size
x-small voice-family "\"\"" voice-family
inherit font-size small htmlgtbody p
font-size small / /

• Diveintoaccessibility.org provides valuable
  advice on making Web sites accessible. But look
  at what it describes

1. First, we're defining an absolute size (12px)
   for every ltpgt. 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.

My boss spends too much time tinkering with CSS
to get it to work in all browsers. Is it a
sensible use of tax-payers money to address
mistakes made by software vendors?
14
Proposed Solutions

• In light of problems do we forget Web
  accessibility and WAI? No!
• Experiences Of NOF-digitise Programme
• The NOF-digitise programme
• Based on open standards accepted best practices
• Recognised difficulties in some areas e.g.
  interactive multimedia
• Developed reporting process for deviations
  projects must document (a) awareness of
  appropriate standards/ best practices (b)
  reasons why open standards / best practices not
  followed (c) scope of use of proposed solution
  (d) migration strategy to best practices in the
  future and (e) indication of costs funding
  mechanisms
• See lthttp//www.ukoln.ac.uk/nof/support/help/faqs/
  website.htmmigrationgt

Possible Solutions
15
A Quality Assurance Model

• JISC-funded QA Focus project is building on
  NOF-digi support work
• Developed a quality assurance framework
• Projects should document their policies and
  systematic procedures for checking compliance
  with their policies
• Initially focussed on technical areas such as
  HTML standards, link checking etc.
• Model being extended to areas such as
  accessibility

Possible Solutions
16
We Need Policies

• There is a clear need for accessibility policies
• Our Web site complies with A/AA. But
• We seek to provide Web accessibility through use
  of CSS, HTML-compliant templates. We check this
  by systematic use of automated tools and formal
  usability accessible testing
• We seek to provide an accessible museum. This
  covers both physical online accessibility.
• We seek to provide an accessible learning
  experience. If e-learning is not accessible we
  will provide real-world accessible alternatives.

Possible Solutions
17
Conclusions

• Web accessibility is important!
• WAI have done a great job
• But there are concerns over WAI WCAG guidelines
  (and most v1.0 of specifications have flaws, so
  this isnt a criticism)
• Accessibility of digital resources is being
  addressed outside of WAI (I still think you
  should use open standards, but use them because
  of their benefits, not because of legal threats)
• There is a need for broader thinking on issues
  such as learning accessibility, usability, etc.

Or is such thinking heretical? Will raising such
concerns lead to people using this as an excuse
to ignore accessibility?