UK Web Focus

Innovation and best practices for the Web

Introducing #BS8878 on Global Accessibility Awareness Day (#GAAD)

Posted by Brian Kelly (UK Web Focus) on 9 May 2012

 

Global Accessibility Awareness Day

Today is the first Global Accessibility Awareness Day (GAAD). As described on the Global Accessibility Awareness Day Web site:

Global Accessibility Awareness Day is a community-driven effort whose goal is to dedicate one day to raising the profile of and introducing the topic of digital (web, software, mobile app/device etc.) accessibility and people with different disabilities to the broadest audience possible.

Today’s event therefore provides a valuable opportunity to highlight important work in the area of Web accessibility which has been developed in the UK and is relevant to a worldwide audience.

Revisiting WAI and WCAG

There will be little need to raise the profile of the work of WAI, the Web Accessibility Initiative and the guidelines they have developed to help enhance the accessibility of Web resources: the Web Content Accessibility Guidelines (WCAG) which describe how web content, including native W3C formats such as HTML as well as formats such as Flash and PDF which may be included on Web sites, should be defined in order to enhance access by people with disabilities who may be using standard Web browsers or assistive technologies which should support the User Agent Accessibility Guidelines (UAAG) Creators of Web content should be using authoring tools which are based on ATAG, the Authoring Tools Accessibility Guidelines, which will help to ensure that the content is WCAG-conformant.

Unfortunately experience has shown that this simple model is insufficient for developing Web products which reflect the diverse ways in which the Web is used today. As summarised in a paper on “Reflections on the Development of a Holistic Approach to Web Accessibility” the reasons for this include limitations in the guidelines themselves, limitations of the three-part model, the inappropriateness of an approaches based on universal accessibility for services which may be targetted at specific groups of users or even an individual user and the lack of guidance in the WAI approach on ways of providing ‘good enough’ accessibility as opposed to WAI’s ‘just-in-case’ approach. To give an example of the need to be able to develop ‘good enough’ solutions, if an institution’s institutional repository contains many thousands of research papers in PDF format and the PDFs, which may be deposited by the author, do not conform with accessibility guidelines, should the repository service be discontinued?

It should also be noted that the limitations of WCAG aren’t restricted to limitations of WCAG 1.0. As described in a paper on “Guidelines are only half of the story: accessibility problems encountered by blind users on the web” recently published in the Proceedings of the 2012 ACM annual conference on Human Factors in Computing Systems:

This paper describes an empirical study of the problems encountered by 32 blind users on the Web. Task-based user evaluations were undertaken on 16 websites, yielding 1383 instances of user problems. The results showed that only 50.4% of the problems encountered by users were covered by Success Criteria in the Web Content Accessibility Guidelines 2.0 (WCAG 2.0). For user problems that were covered by WCAG 2.0, 16.7% of websites implemented techniques recommended in WCAG 2.0 but the techniques did not solve the problems. These results show that few developers are implementing the current version of WCAG, and even when the guidelines are implemented on websites there is little indication that people with disabilities will encounter fewer problems. The paper closes by discussing the implications of this study for future research and practice. In particular, it discusses the need to move away from a problem-based approach towards a design principle approach for web accessibility.

But if WCAG has failed to live up to its expectations, is it no longer relevant? We disagree with this view – rather there is a need for a higher level standard which provides a context for use of WCAG and other accessibility standards.

BS 8878: Web Accessibility Code of Practice

As described in a post entitled BS 8878: “Accessibility has been stuck in a rut of technical guidelines” the BS 8878 Web Accessibility Code of Practice has been developed in order to address limitations of WAI’s approaches. As described in a paper on “A Challenge to Web Accessibility Metrics and Guidelines: Putting People and Processes First” BS 8878 “makes recommendations for accessibility being addressed across a 16 Step Model of the web product development and maintenance process“. The paper goes on to describe BS 8878 in more detail:

These steps span: initial conception and requirements analysis (steps 1 to 6); strategic choices based on that research (steps 7 to 11); the decision to procure or develop the web product either in-house or contracted out (step 11); production of the web product (steps 12 and 13); evaluation of the product (step14); the launch (step 15); and post-launch maintenance (step 16).

Step 1: define the purpose of the web product
Step 2: define the target audiences for the web product
Step 3: analyse the needs of the target audiences for the web product
Step 4: note any platform or technology preferences and restrictions of the web product’s target audiences
Step 5: define the relationship the product will have with its target audiences
Step 6: define the user goals and tasks the web product needs to provide
Step 7: consider the degree of user-experience the web product will aim to provide
Step 8: consider inclusive design and user-personalized approaches to accessibility
Step 9: choose the delivery platforms to support
Step 10: choose the target browsers, operating systems and assistive technologies to support
Step 11: choose whether to create or procure the web product in-house or contract out externally
Step 12: define the web technologies to be used in the web product
Step 13: use web guidelines to direct accessible web production
Step 14: assure the web product’s accessibility through production
Step 15: communicate the web product’s accessibility decisions at launch
Step 16: plan to assure accessibility in all post-launch updates to the product
Figure 1: 16 Step Model of BS 8878

This model has been drawn up based on real-world experience in companies and organisations that have effectively addressed accessibility. BS 8878 addresses accessibility both at the organisational level and the individual product level. It needs to be adapted to any situation it is applied.

The official slides on BS 8878 from its launch, together with other free information including, case studies of organisations using BS 8878, detailed blogs on its use by SMEs, tools and training for applying the Standard, and news on its progress towards an International Standard, can be found at http://www.hassellinclusion.com/bs8878/

BS 8878 was published by the British Standards Institute and has not been adopted by standards body outside the UK. However on Global Accessibility Awareness Day it would appear particularly appropriate to highlight the valuable work which has taken place in the UK. Perhaps Web accessibility practitioners, developers and policy-makers outside the UK should be asking “How can we learn from the approaches which have been taken in the UK?“; “Shouldn’t we be looking to implement a similar code of practice within our national standards body?” and even “Shouldn’t BS 8878 form the basis of an international standard?


About the Author and his Previous Work

Brian Kelly attended the launch meeting for WAI in April 1997 and has been active in promoting best practices for Web accessibility ever since. Initially the focus of his work was in promoting take-up of WCAG guidelines across the UK’s higher and further education sectors. However following feedback from those involved in developing of web-based elearning services, it became apparent that use of WCAG guidelines was not always appropriate in the context of e-learning development work. A paper on “Developing A Holistic Approach For E-Learning Accessibility” published in the Canadian Journal of Learning and Technology in 2004 introduced the idea of ‘holistic approaches’ to web accessibility.

The limitations of WAI’s approaches were described in a paper on “Forcing Standardization or Accommodating Diversity? A Framework for Applying the WCAG in the Real World” which described how “the context of the Web resource in question and other factors surrounding its use are used to shape an approach to accessible design” was published in 2005.

A paper on “Implementing A Holistic Approach To E-Learning Accessibility” was awarded a prize for Best Research Paper at the ALT-C 2005 conference.

The importance of context was described in a paper on “Contextual Web Accessibility – Maximizing the Benefit of Accessibility Guidelines” which was presented at the W4A 2006 conference.

The importance of development of policies and accompanying processes to support user-focussed approaches to Web accessibility were described in a paper on “Accessibility 2.0: People, Policies and Processes” presented at the W4A 2007 conference.

A review of work to date was given in a paper on “Reflections on the Development of a Holistic Approach to Web Accessibility” presented at the ADDW08 conference.

The need to adopt alternative approaches to Web accessibility was described in papers on “Accessibility 2.0: Next Steps For Web Accessibility” published in the Journal of Access Services and “From Web Accessibility to Web Adaptability” published in the Disability and Rehability: Assistive Technology journal, both published in 2009.

Insights from disability studies were included in a paper on “Developing Countries; Developing Experiences: Approaches to Accessibility for the Real World” presented at the W4A 2010 conference.

The limitation of accessibility metrics were addressed in a paper “Web Accessibility Metrics For A Post Digital World” presented at a W3C WAI online symposium in 2011.

These ideas were further developed in a post on “A Challenge to Web Accessibility Metrics and Guidelines: Putting People and Processes First” presented at the W4A 2012 conference.

These, and other peer-reviewed papers on Web accessibility can be accessed from the UKOLN Web site.


Twitter conversation from Topsy: [View]

About these ads

2 Responses to “Introducing #BS8878 on Global Accessibility Awareness Day (#GAAD)”

  1. As lead-author of BS 8878, many thanks for your highlighting of our UK Standard, Brian.

    You’re right that BS 8878 could usefully become a global Standard, or the basis for a global Standard. It sets a framework around WCAG 2.0 (which has now been recognised as an ISO/IEC Standard itself) to enable organisations to understand the need for accessibility, and to embed accessibility within their working practices.

    The case for this is growing…

    I presented Case Studies of Implementation of BS 8878 at CSUN this year, highlighting the benefits that organisations that have implemented BS 8878 in the UK have enjoyed, and asking questions of an international audience on whether BS 8878 could be useful globally. Feedback was uniformly positive, so I’m working with American Jeff Kline (whose Strategic IT Accessibility book chimes strongly with BS 8878) and others on ways of taking BS 8878 forwards to become an International Standard.

    Watch this space, and keep up with progress on my BS 8878 page.

    Jonathan

  2. Brian, you make an excellent case for what every web developer should be doing, but usually isn’t. I guess because we’re all people, we assume that we’re the experts on what people want, so we don’t even think to ask. When I work with developers in my job, I usually illustrate the problem with a simple sketch. This sketch, I tell them, is a metaphor for how virtually everyone (so I say “we”) made their first venture into the Web.

    Owners of websites and their developers, I continue, first understood the Web to be an electronic billboard. So in my childishly crude sketch, the website is a billboard (represented by a rectangle), the developer is a stick figure painting the name of their enterprise (in my case, a part of a governmental agency) across the rectangle, and the owners are stick figures sitting behind a desk, feet up, smiling broadly at the result.

    “The problem is that we didn’t realize that we weren’t painting on a billboard,” I point out as I sketch another stick figure on the other side of the rectangle from the owners and developer.

    “It was a plate glass window.” Then I add to the new stick figure a frown on its face and an arm reaching up to scratch the top of its head. “So what does our audience see?”

    And that’s exactly what’s wrong with WCAG 2.0. If your goal is to spend a semester studying accessibility, working from basic principles to application, it’s great. It works perfectly for people whose goal is to ensure that they have systematically covered the issues of accessibility.

    But the people who need accessibility don’t have time to take that course of study. They’re in the middle of a process that at best is a close approximation of your 16 steps. They’re trying to write code that creates forms and widgets that people can use. And they need to quickly find the best ways to create that form or to set up the interaction behind that widget.

    It would be nice, I’ve said before, if an index existed that would take people from their problem—for example, “How do I make this fieldset in this form accessible?”—to the information the W3C has already gathered about solving that problem. But in developing an argument for that index here, I discovered something I hadn’t noticed before: There are no anchors that allow me to point to the documented techniques that demonstrate success (sufficient techniques, as the W3C calls them), success under given conditions (advisory techniques), or failure (failures) to achieve an accessible result in a specific situation.

    So I would have to re-create all that content to make the index work. (At the same time, I would edit it for readability as well as usability.)

    Even though this has turned out to be more work than I had thought, that’s not the barrier I’ve run up against. Instead, my progress has been impeded by the attitude, “Developers just want a checklist, and accessibility isn’t a checklist.”

    With the unstated conclusion being that accessibility is a thorough understanding of the guidelines as organized on the website of the W3C.

    As you rightly point out, accessibility is neither. Accessibility is an application, a fieldset in a form, a PowerPoint presentation, or even just an html page that is usable to everyone and as usable to people with disabilities as it is to everyone else.

    And so I must conclude that WCAG 2.0 and all its supporting materials are inaccessible. They’re navigable, but they cannot be used by the audience who must put them into effect—that is, the people who produce and present information by means of electronic media.

    And as I tell my co-workers, if it isn’t usable, it can’t be accessible.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: