Subscribe to Newsletter
Tell a Friend
Print this Page
Web Accessibility: Putting People and Processes First
In seeking to ensure good experiences for disabled people in interacting with web resources, it is essential to consider their needs throughout the development cycle, and the value of systems that collect and respond to user-provided feedback on accessibility, in their own terms, says Brian Kelly.
For many web authors, developers and policy makers, the issue of accessibility to disabled people is addressed mainly by trying to ensure that their sites conform with the international Web Content Accessibility Guidelines (WCAG) maintained by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium.
For example, the UK Government’s ‘Delivering inclusive websites guidelines’ (http://bit.ly/3lCReg), published in 2009, said: “The minimum standard of accessibility for all public sector websites is Level Double-A of the W3C Web Content Accessibility Guidelines. All new websites must conform to these guidelines from the point of publication.”
However, as recently described in a blog post I have written (entitled ‘Aversive Disablism, Web Accessibility and the Web Developer’: http://bit.ly/ISdAhh) which details the seventh annual Blogging Against Disablism Day, there is a need to ask: “Are web developers and web authors who have embraced WCAG guidelines unknowingly creating barriers for people with disabilities?” This question could also be asked of government policy makers. There is a need for an alternative approach which caters for the limitations of policy based solely on WCAG conformance.
The web’s inventor Tim Berners-Lee has said that “The power of the web is in its universality. Access by everyone regardless of disability is an essential aspect.” However, although this is a laudable goal, implementation of WCAG guidelines is not necessarily a way of achieving it. For example, WCAG 2.0 guidelines which state that “content must be understandable” would mean that the famous UK newspaper football headline from 2003 – “Super Cally Go Ballistic, Celtic Are Atrocious” – would not be allowed, since this wordplay will only be appreciated by those who are familiar with the song from the film ‘Mary Poppins’, and the football teams in question. In a more general context, while we can understand that people with Asperger’s syndrome may have difficulties interpreting common phrases such as “it’s raining cats and dogs”, it is unlikely that organisations will ban such usage in order to ensure that the content is “accessible by everyone regardless of disability”.
A more comprehensive critique of the limitations of the WCAG guidelines and the WAI model for addressing web accessibility issues is given in my papers on ‘Forcing standardization or accommodating diversity? A framework for applying the WCAG in the real world’ (http://bit.ly/9BHyiH) and ‘Accessibility 2.0: people, policies and processes’ (http://bit.ly/LohYBA).
We can agree that the WAI approach, developed in the late 1990s, has been valuable in raising awareness of ways in which web resources can enhance experiences for people with disabilities. But rather than regarding WCAG conformance as definitive solution, we should regard it as a useful set of guidelines, whose use and relevance needs to be considered in light of a variety of factors including the needs of the target audience and the resources available for the development of the service.
In addition, there will be the need to consider risks in failing to provide a service, even if it does not conform with WCAG guidelines. For example, should resources for an ‘amplified event’, in which the talks are made available by a live video stream and afterwards for downloading, be deleted if resources for captioning the videos are not available? Common sense would seem to suggest that deleting resources, particularly videos of talks which might be particularly valuable to some people, is not a great way of enhancing accessibility!
The BS 8878 Web Accessibility Code of Practise, which is summarised by Jonathan Hassell, the BS 8878 editor, on his Hassell Inclusion blog (http://bit.ly/ugpXgp) provides an agreed mechanism which allows guidelines such as WCAG to be used when they are fit for purpose. The value of this approach is that it understands the importance of the context of usage.
In the past, criticisms of WAI’s limitations were met by the response of “WAI may be flawed, but there is no alternative”. We are now in a position whereby there is an alternative approach, which has been developed not as a competitor to WCAG, but as an overarching framework which enables the balanced application of guidelines such as WCAG.
The development of web services and web applications is a process. Accessibility considerations therefore need to be built into the everyday practices across the full web development life-cycle, from conception and specification through development to delivery and maintenance. BS 8878 has been developed to document the key stages in the life-cycle.
Section 6 is the core of the standard. It makes recommendations for accessibility being addressed across a 16-step model of the web product development and maintenance process (described below). These steps span initial conception and requirements analysis such as defining the target audiences for the web product, and defining the user goals and tasks it needs to provide. (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 (step14); the launch, where it will be important to communicate the web product’s accessibility decisions (step 15); and post-launch maintenance (step 16).
Overall, users’ experiences are pre-eminent in assessing the accessibility of any web resource. This follows from the understanding of accessibility as a property of the relationship between the users and the resource, and that context is important. In seeking to ensure good experiences for disabled people in interacting with web resources, it is essential to consider their needs throughout the development cycle, and the value of systems that collect and respond to user-provided feedback on accessibility, in their own terms.
NOTE: Article edited from a paper by Brian Kelly (University of Bath), Martyn Cooper (Open University), David Sloan (Dundee University), and Sarah Lewthwaite (King’s College London) in a series exploring best practices for enhancing accessibility of online services (http://bit.ly/Laov). Kelly is also co-author of ‘A Challenge to Web Accessibility Metrics and Guidelines: Putting People and Processes First’ (http://bit.ly/KgyDZz), presented at accessibility workshop W4A 2012.
This article was republished from the blog: http://www.headstar.com/eablive/?p=719
Related Blog: Tim Unwin Blog: Ensuring Disability Agendas are Embedded in National ICT Strategies | Read further.
Related Publication: Understanding Web Accessibility: A Guide to Create Accessible Work Environments | Released by NASSCOM Foundation | Read more about this report.
Related Event: Workshop on IT for Disabilities (IT4D'2012) | Wroclaw, Poland on September 9-12, 2012 | View Details.back
• G3ICT PUBLISHES INTERNATIONAL SURVEY OF WEB ACCESSIBILITY POLICIES WHITE PAPER BY THE CENTRE FOR INTERNET AND SOCIETY, BANGALORE, INDIA
• Three Things to make your App stand out when Building for Accessibility
• Nominations Open for U.S. FCC Chairman’s Award for Advancement in Accessibility (AAA)
• 7th European e-Accessibility Forum: Developing e-Accessibility as a Professional Skill, Paris, France
No records were found.
Post new comment:
Only register users can add comments please Log-in