A Challenge to Web Accessibility Metrics and Guidelines: Putting People and Processes First

I’m pleased to report that a paper on “A Challenge to Web Accessibility Metrics and Guidelines: Putting People and Processes First” has been accepted for the W4A 2012 conference, the 9th International Cross-Disciplinary Conference on Web Accessibility.

The paper is the latest in a series of peer-reviewed papers on Web accessibility based on work led by myself and David Sloan, an accessibility researcher based at the University of Dundee.

This paper is co-authored with Martyn Cooper (the lead author, who is based at the Open University), Sarah Lewthwaite (based at King’s College London who was a co-author of our award-winning paper on Developing Countries; Developing Experiences: Approaches to Accessibility for the Real World presented at the W4A 2010 conference) together with David Sloan.

The paper will be made publicly available next month. The abstract for the paper describes how:

This paper argues that web accessibility is not an intrinsic characteristic of a digital resource but is determined by complex political, social and other contextual factors, as well as technical aspects which are the focus of WAI standardisation activities. It can therefore be inappropriate to develop legislation or focus on metrics only associated with properties of the resource.

The authors describe the value of standards such as BS 8878 which focus on best practices for the process of developing web products and include a user focus.

The paper concludes with a case study that illustrates how learning analytics could provide data to support the improvement of the inclusivity of learning resources, providing a broader perspective beyond the digital resource.

A post which will discuss these ideas, and the challenges which are presented to legislators, policy makers and practitioners who develop practices based on a view that web accessibility is an intrinsic property of a resource which is independent of its context of use, will be published at a later date. For now, however, I’d like to reflect on the working practices and tools we used in writing the paper.

Collaborative Tools Used In Writing The Paper

Display of paper from Skydrive App on iPod Touch

As I suspect is increasingly the norm for collaborative writing, once we had had the initial exchange of emails and agreed to submit a paper, we created a Google Doc. The document was used initially for sharing ideas for the paper and writing the initial draft based on the initial proposed structure.

As the submission deadline approached we became aware that the paper would need significant editing in order to be within the page limit impose by the conference organisers. We therefore copied the content to an MS Word file so that we could had a better idea of the overall shape of the paper which helped to identify the sections we needed to remove.

In order to carry out the final editing we agree that the MS Word file would be the new master copy, and we abandoned the Google Doc which was used in the initial brainstorming of ideas and the production of the earl drafts.

We investigated use of Google Docs as an environment for managing the MS Word file, but that didn’t work.  We therefore decided to evaluate the Microsoft’s Skydrive service which, as described in Wikipedia is “a free-of-charge file hosting service that allows users to upload files to a cloud storage and then access them from a Web browser“. The Wikipedia article goes on to add:

Microsoft added Office Web Apps support to SkyDrive in its “Wave 4” update allowing users to upload, create, edit, and share Microsoft Office documents directly within a Web browser. Users can create, view and edit Word, Excel, PowerPoint and OneNote documents within the Web browser. … Users of recent versions of Microsoft Office (for Windows or Macintosh) can use the desktop applications to edit the same section of documents stored on SkyDrive simultaneously. Changes are synchronized when users save the document, and where conflicts occur, a user is given the selection to choose which version to keep.

We found that we could store an MS Word file on Skydrive and edit the file within the browser whilst maintaining the MS Word formatting, although as the checking-in and -out capabilities are dependent on the version of MS Word used locally we did not fully exploit this capability. Skydrive also provides access control, so I could specify who could read or update the paper. In addition the Skydrive App for my iPod Touch enabled me to view the file on a mobile device – and this morning while rereading the paper I noticed a couple of minor changes which improved the readability of the paper. The accompanying screenshot shows the view of the paper which I read on the app.

I’m pleased that writing this paper provided an opportunity to evaluate a new service which appears valuable for collaborative writing when a formatted MS Word file is the intended final output. This is a tool I intend using again in the future. However I’m sure there are many people who have used other collaborative authoring tools which may provide additional advantages. I’m also willing, as part of my open practices for my professional activities, to share my development practices as well as provide open access to my outputs. I’d invite others to share the practices they use in their collaborative writing.