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.

Yesterday’s press release from W3C states that trial implementations of the new standard have shown that most web sites which already “conformed to WCAG 1.0 did not need significant changes to meet WCAG 2.0″, so many developers may be breathing a sigh of relief. But it is also likely that there will be pressure for developers to ensure that their web content conforms to the new standard. Does this mean that what was “accessible” yesterday is not “accessible” today?

WCAG 2.0 is different in many aspects to WCAG 1.0, so for a while there may be a two-tier level of conformance (although the A, AA, and AAA conformance levels are still in place). Some of new aspects covered include:

* captchas;
* semantic markup using ARIA (Accessible Rich Internet Application) – once this specification has reached “recommendation” status;
* recommendation that an alternative is provided for any text that requires a reading ability more advanced than the lower secondary education level (how will online academic papers be dealt with?);
* etc.

However, WCAG 2.0 comes with several other resources to help with its implementation:

* WCAG 2.0 at a Glance;
* WCAG 2.0 Documents;
* How to Meet WCAG 2.0: A Customizable Quick Reference;
* Understanding WCAG 2.0;
* Techniques for WCAG 2.0;
* How to Update Your Web Site to WCAG 2.0.

The WAI (Web Accessibility Initiative) have tried hard to give developers as much information as possible to help with the implementation of WCAG 2.0.  They have gone beyond simply defining what one can and can’t do, and include additional information around conformance, failure testing, conformance policies, etc. Perhaps this level of assistance with implementation should be considered by other standards bodies.

In any case, WCAG 2.0 is finally here.  Whether developers and users will see it as a welcome Christmas present or something they’d rather take back to the shops in January remains to be seen.  Let’s hope it helps rather than hinders.

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).

* ATAG (Authoring Tool Accessibility Guidelines) 2.0 – These guidelines are currently at Working Draft level. ATAG 1.0 is still the stable version which should be used.

* EARL (Evaluation and Report Language) 1.0 – The public comment period for the “Representing Content in RDF” and “HTTP Vocabulary in RDF” companion documents has recently finished (29th September 2008). Once the comments have been addressed, these documents will be published as Notes rather than Recommendations. (EARL 1.0 is currently has the status of Working Draft.)

* Shared Web Experiences: Mobile and Accessibility Barriers – This draft document gives examples of how people with disabilities using computers and people without disabilities using mobile devices experience similar barriers when using the Web. Comments on this document closed on 20th August.

* UAAG (User Agent Accessibility Guidelines) 2.0 – This version is currently at Public Working Draft status and is at this stage for information only.

* WAI-AGE Addressing Accessibility Needs Due to Ageing – This project is currently at the literature review stage and aims to find out whether any new work is required to improve web accessibility for older people.

* WAI-ARIA (Web Accessibility Initiative Accessible Rich Internet Applications) – The Working Draft has recently been updated and comments on this update closed (3rd September).

* WCAG (Web Content Accessibility Guidelines) 2.0 – After a lot of to-ing and fro-ing, WCAG 2.0 finally looks as though it’s going to finalised for public use by the end of the year. Data from the implementation of trial WCAG 2.0 websites has been gathered and whilst the status is still “Candidate Recommendation”, this status is likely to be updated in November.

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!

As well as mentioning the usual “dos and don’ts” for web accessibility, he talked about how accessibility should be part of an organisation’s culture, in the same way that recycling is often seen as part of an organisation’s ethical commitment.  Most organisations in the UK (United Kingdom) have recycling strategies and policies (although there may be some legal encouragement here) and encourage staff to actively play their part.  In the same way, accessibility should be actively encouraged – from purchasing accessible equipment and software right through to ensuring that disabled people are actively encouraged to apply for jobs within the organisation.

Bohman stated that the web and e-learning now provides an historic opportunity for disabled people to access information independently for the first time ever.  Yet, if web resources are designed to be unfriendly or inaccessible, then this opportunity is wasted.

Web accessibility is not just about making sure that web developers and content creators follow the W3C WAI (World Wide Web Consortium Web Accessibility Initiative) specifications and guidelines. It also needs to involve people and services outside of an organisation’s actual main web site.  Of course, there may be additional costs but much of these costs can reduced by ensuring that accessibility is considered from the very beginning.  Particular parts of an organisation’s system mentioned by Bohman include:

* Web Services – Ensuring that any web services accessed as part of the web site or e-learning system are accessible.

* Intranet – An organisation’s public web site may be accessible but its private intranet also needs to be accessible to both employees and students alike.  For example, if the intranet portal links through to a person’s payroll or financial details, these need to be accessible. It is easier and cheaper to include accessibility right from the start.

* Libraries - Although a library may not have any influence over which journals are available electronically, details should be kept up-to-date on the library’s (accessible!) database.

* Learning Management Systems – Although VLE (Virtual Learning Environment) developers, such as BlackBoard, have made significant efforts to make the student side accessible, work is still required to ensure that the tutor side is also as accessible.  Most tutors are expected to create electronic resources for their students but generally they are not specialists in accessibility.  Prompts should be available which encourage accessible authoring of resources.

* Future Proofing – Are students on computer or teaching courses actually taught how to make systems and content accessible?

* Purchasing – In the US (United States), Section 508 requires that the most accessible product of its type is purchased by federal organisations.  Most purchasing departments therefore are well aware of the VPAT (Voluntary Product Accessibility Template), which explains where a product is and is not accessible.  If the question of accessibility is not raised when purchasing a product, then the likelihood of it actually being accessible will be fairly slim.  Therefore, someone using assistive technologies, such as a screen reader, will only be able to work or learn in that organisation for as long as the actual systems and products used by that organisation are accessible.

* Recruitment – Although it is fairly easy and cheap to include a requirement for accessibility knowledge in a job advertisement or job description, actually testing a potential candidate’s knowledge can be take time.

* Training – It is not acceptable for an organisation to state that they have an interest in accessibility, it needs to be supported by relevant training at a relevant level across departments.  For example, the accessibility training received by a web developer will be different to that received by a purchaser.  Although there may be substantial upfront costs, it should be on-going and take whatever form is necessary.

In order for every part of the system to be effectively involved in accessibility, it is imperative that an organisation’s leadership is committed to it and that adequate budgets are provided. 

Bohman ended the webinar by stating that implementing accessibility benefits everyone because everyone has the potential to require accessible systems at some point.

It was interesting to hear accessibility likened to the recyling strategies and policies that many organisations have adopted.  These seem to be quite successful so perhaps a similar approach could be taken for ensuring that accessibility is seen as part of an organisation’s ethos.

One comment made by one of the moderators during the presentation, which I found quite interesting, was that the use of wireless devices may actually do more for accessibility than accessibility advocates have managed to achieve.  Perhaps it doesn’t matter how or why accessibility is achieved, as long as it is achieved!

The great thing about the actual presentation is that it has tried to be both engaging and accessible. There are short paragraphs of text in the presentation, which are also spoken out loud, whilst information itself is presented very clearly and is supported by an engaging animation and colour scheme.

The NIIMLE portal also seems to have some form of personalisation and the NIIMLE development team have also attempted to incorporate the WAI (Web Accessibility Initiative) guidelines.

So full marks to the NIIMLE Team for an accessible and engaging presentation.