Presentations ranged from an overview of the accessibility standards work being done across the globe by Alex Li (Microsoft) to the development of accessible widgets by Elaine Pearson and her team at Teesside University.

Several of the presenters talked about their ongoing work in accessibility specifications and have asked for feedback from the community. So if you would like be involved in helping to shape these developments, people working on the following specifications would really appreciate your feedback:

* Standardisation Mandate M/376 (Phase 2) – Dave Sawdon from TRE Limited described how this work will create European accessibility requirements for the public procurement of products and services in the ICT domain (similar to the American VPAT (Voluntary Product Accessibility Template), which was introduced by Ken Salaets of the Information Technology Industry Council). The development team are particularly looking for public procurement officials to help define this standard.
* Access For All v.3.0 – works on the premise that personalisation preferences need to be machine readable, so it uses metadata to describe these personal needs and preferences. Andy Heath and the specification development team at IMS would like people to download it, try it out, implement it, check it works, and provide feedback.
* BS 8878:2010 Web accessibility. Code of practice – Jonathan Hassell, BBC, talked us through the background and purpose the recent web accessibility Code of Practice and Brian Kelly, UKOLN presented BS 8878 in the context of an holistic approach to accessibility. However, whilst it is now available for public use, user testing of the Code of Practice can only really be done in the field, so please join the community of practice and provide feedback on your experiences of implementing BS 8878.
* Mobile Applications Accessibility Standard – This standard, proposed by Yacoob Woozer of the DWP (Department of Work and Pensions), is still very much at the drawing board stage, with the focus on mobile applications rather than on creating websites that can viewed on different devices. However, suggesstions on what to include in the standard would be welcome.

Several of the presentations focussed on the work of specific standards bodies – David Fatscher from BSI gave us an overview of BSI; the various ISO standards which feature accessibility elements were introduced by Jim Carter from the University of Saskatchewan; and Shadi Abou-Zahra of W3C talked about the WAI (Web Accessibility Initiative) guidelines.

And finally, I am very much appreciative of the work that the BSI staff and Andy Heath put into making this event such a success. It was it was a great opportunity for the standards and education sectors to get together and I hope that some lasting collaborations have been forged.

Here is an overview of the draft standard written for us by Andy Heath at Axelrod Access for All and includes information on how to provide feedback. Andy writes:

“On 30th April BSI published a Draft for Public Comment for a new standard in development – A Code of Practice for Web Accessibility.

Why is this draft standard important?

The work began as a planned update of the Publicly Available Specification PAS 78:2006 Guide to good practice in commissioning accessible websites (Available by search for “PAS 78:2006” at http://shop.bsigroup.com/). This was a very useful standard taken up by many organisations. But 8878 goes considerably further in its support for approaches to accessibility.

8878 gives broad support and advice to organisations in making Web Products (more than static html pages) accessible. It provides normative advice where that is clear and possible and informative advice where practice is less certain now but becoming clearer over time and it clearly distinguishes between them.

Included in the topics it addresses are:

* Recommendations to organisations on how to structure accessibility strategy and policy;
* How to effectively use web accessibility guidelines such as WAI Web Content Accessibility Guidelines (WCAG) 2.0 etc. in the context of web products (Relevant sets of guidlines include Web Content Accessibility Guidelines (WCAG) 2.0, User Agent Accessibility Guidelines (UAAG), Authoring Tool Accessibility Guidelines (ATAG), Accessible Rich Internet Applications (WAI-ARIA) 1.0, Section 508 of the (US) Rehabilitation Act of 1973);
* Precisely where and how to use an inclusive design or audience-based approach, where to use an approach that treats each person as an individual and how to support each of these in technology and in the organisation;
* How to ensure accessibility through a product’s lifecycle;
* Principles for providing accessibility across heterogeneous platforms and technologies – the standard exposes the critical factors to consider in deciding what it is reasonable for an organisation to provide in a particular context and how that should be done;
* Effective approaches to testing;
* Advice on the Equality Act 2010.

Guidance is given on many other relevant areas.

The audience for the standard includes a wide range of stakeholders from implementers through many categories of manager to policy designers, individuals, disability experts and others. Organisations to whom it has relevance include individual web developers, content and system vendors and any organisation that provides content or system to a public or captive audience including corporations and government agencies.

Publication of the standard is scheduled to be around October 2010. Meanwhile, a draft for comment is available at: http://drafts.bsigroup.com/Home/Details/489.

It is open to any individual or organisational representative to comment.

A draft in Rich Text Format and a Comment Template can be downloaded at the URL given. The draft is also available for reading and commenting directly on the site (Press the View button) and should be accessible to all. Where that is not the case or for other reasons someone has difficulty making comment it would be helpful for that to be raised on the site, with BSI or with myself (Andy Heath) or any other community members who have worked on the standard (not named here). I will, where appropriate, present to BSI or the committee developing the standard any comments that are made to me.

The period for comment ends on June 30th 2010.

Comments received up to the deadline will be addressed (where appropriate) in producing the final version of the standard.

I believe this standard addresses issues that the community has highlighted as needing advice on for some years. I think it can be an important support to the community and it’s important that we get it right. I commend it to you and urge you to read it and make comment on how to make it better than it is. When doing so please bear in mind that at this point it naturally has some imperfections you would expect of a draft in edit but not of a final standard and we should be focussing for now mainly on whether it has the right content and whether the approaches recommended are the best ones.”

So after all that encouragement from Andy, please go and add your feedback to BS8878!

Its aim is to give “recommendations for building and maintaining web experiences that are accessible to, usable by and enjoyable for disabled people”. It includes sections on:

* use of W3C WAI (World Wide Web Consortium Web Accessibility Initiative) accessibility specifications and guidelines;
* accessibility policies and statements;
* involving people with disabilities in the design, planning and testing of websites;
* allocation of responsibilities within an organisation for accessibility;
* suggestions on how to measure user success.

“BS 8878:2009 Web Accessibility. Building Accessible Experiences for Disabled People. Code of Practice” will be available for public comment until 31st January 2009. You can access the (free) draft in HTML. However, you will need to set up a user account in order to access it. Once you’ve logged in, you can then make comments online. If you find the HTML version somewhat inaccessible, it can be downloaded either in PDF or Word format (at time of writing, a log in is not required).

There were some interesting comments and if you don’t get chance to listen to the whole thing, here’s a brief run-down of some of the ideas and issues, which I thought were particularly salient.

* Social networking sites can take the place of face-to-face networking, particularly where the user has motor or visual disabilities. However, many sites often require the user to respond initially to a captcha request, which can be impossible for people with visual or cognitive disabilities.  Some sites do allow people with voice-enabled mobiles to get around the captcha issue, but not everyone has such technology. Once the user has got past such validation, they then have to navigate the content which, being user generated, is unlikely to be accessible.

* One of the panellists felt that people with disabilities did not complain enough about inaccessible websites and that a greater level of user input would help web based content be more accessible.

* Jonathan Chetwynd, who has spoken to the CETIS Accessibility SIG in the past (see Putting the User at the Heart of the W3C Process) stated that users were not involved in the specification and standards process, because it was led by large corporate companies.  He also felt that users with low levels of literacy or technical ability were being overlooked in this process.

* There was some interesting discussion about W3C (World Wide Web Consortium) and the way in which their accessibility guidelines are developed.  Anyone can be involved in the W3C process but as a fee is charged for membership, it is mostly companies, universities, and some not-for-profit organisations who take part.  As some companies don’t want their software to appear as inaccessible, it may be that their motive in joining the W3C is less altruistic.  It was stated that it was actually easier to “fight battles” within the W3C working groups than to take them outside and get a consensus of opinion. As a result, there is not enough engagement outside the W3C working groups which has resulted in a lot of dissatisfaction with the way in which it works. 

* We are now in a post-guideline era, so we need to move away from the guideline and specification approach to an approach which considers the process.  This means taking the audience and their needs into account, assistive technology, etc.  Accessibility is not just about ticking boxes.  The BSI PAS 78 Guide to Good Practice in Commissioning Websites, for example, gives guidance on how to arrive at the process and to ensure that people with disabilities are involved at every stage of the development.  However, developers often want guidelines and specifications to take to people who don’t understand the issues regarding accessibility.

* It is important that everyone is given equivalence of experience so there is a need to separate what is being said and how it needs to be said for the relevant audience.  The web is moving from a page-based to an application-based approach.  One panellist likened Web 2.0 applications to new toys with which developers were playing and experimenting and he felt that this initial sandpit approach would settle down and that accessibility would start to be considered.

* Assistive technology is trying hard to keep up with the changing nature of the web but is not succeeding.  Although many Web 2.0 applications are not made to current developer standards (not the paper kind!), many of the issues are not really developer issues.  For example, multimodal content may have captions embedded as part of the the file or as standalone text, which both browsers and assistive technologies need to know how to access.

* People with disabilities are often expected to be experts in web technology and in their assistive technology but this is often not the case.

After the discussion, the panel members were asked what they felt would advance the cause of web accessibility.  My favourite reply was the one where we all need to consider ourselves as TAB (Temporarily Able Bodied) and then design accordingly.  The rationale behind this was that we will all need some sort of accessibility features at some stage.  So the sooner we start to build them in and become familiar with them, the better it should be for everyone else!