Web Accessibility: Beyond WAI

1. Web Accessibility:Beyond 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@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 <http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-12/> (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) Accessifyforum’s problem (b) Netgem’s 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. These are seen as WAI requirements. Are they? 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;} html>body p {font-size: small;} /* */ • Diveintoaccessibility.org provides valuable advice on making Web sites accessible. But look at what it describes: • First, we're defining an absolute size (12px) for every <p>. All browsers apply this style … • 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. • 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 <http://www.ukoln.ac.uk/nof/support/help/faqs/website.htm#migration> 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 isn’t 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?