After a short introduction to the legal context (Advocates for the Blind sued Arizona State University over their use of Kindle resulting in Amazon making changes to its software), Ken gave an overview of the current e-book formats on offer, which are mostly based on XML (eXtensible Meta-Language):

• PDF (Portable Document Format) – common, but mostly inaccessible unless tagged correctly.
• MOBI (Adobe).
• AZW (Amazon) – ePub-like format for the Kindle, but lacks its rich structure.
• XPS (XML Paper Specification) – designed to look like the original paper copy; only used by Blio.
• DAISY (Digital Accessible Information System) – accessible standard for digital talking books; not much control over formatting.
• ePub v3 – read by most readers (except Kindle); has a lot of DAISY’s accessibility features; rich formatting control, including video/audio embedding; full support for MathML (although no readers can read it just yet). It’s basically XHTML (eXtensible HyperText Markup Language) with super styling, i.e. CSS3 (Cascading StyleSheets) with SVG (Scalable Vector Graphics) and JavaScript.

He then followed this with an overview of e-book reader accessibility:

• Kindle – has a free accessibility plug-in for PC; uses its own text-to-speech engine, so won’t work with screenreaders; not possible to copy and paste text; the finest grain of movement through the book is sentence by sentence; allows synching of different platforms so notes made using Kindle on the iPad can also be viewed on a PC. (Apparently it’s very easy to bypass the digital rights management and convert both MOBI (Adobe) and AZW (Kindle) formats to ePub and read the book on another device!)
• iBooks 2 (Textbooks) on iPad – proprietary version of ePub v3, although authoring software, iBooks Author, is free; good for embedded graphics; can only be used on the iPad, not on the iPhone/iPod nor any other device; limited textbooks in the iBooks Store; possible to read ePub books using iBooks 2, but the fine-grained reading experience isn’t there; words highlighted as played; full typographic control (e.g. enlargeable text, high contrast, etc).
• Blio – has incremental zoom for focussing on a small section of text and back out again.
• ReadHear – a downloadable app for Mac or PC; uses DAISY; accessible maths equations; words highlighted as played; full typographic control (e.g. enlargeable text, high contrast, etc); rich screen reader access (for DAISY books only).
• NookStudy – cross-referencing; synchronised highlighting for comparison purposes, where several books (or different pages of the same book) can be open at the same time; cut and paste; look-up using Wolfram Alpha.

For further information, see Ken Petri’s e-Book Reader Accessibility and Comparison Matrix (under development).

Although the presentation focussed on the accessibility of readers rather than on the content, some mention was made of authoring tools. For example, Calibre is a free, open-source tool that will convert across formats using RTF (Rich Text Format), e.g. from Word to DAISY (although it doesn’t do MathML). There is also a plugin for creating DAISY books from Word itself.

To sum up the importance of e-textbooks, Ken’s presentation included a quote from Eve Hill, Senior Counsellor to the Assistant Attorney General at the Department of Justice:

“In education, the current transition from print materials to digital materials creates and incredible opportunity for people with print disabilities to finally use the same products as their peers and to gain the same benefits as their peers who do not have disabilities.”

Of course, there are negatives, such as affordability of devices, proprietary formats, limited storage capabilities on some readers, possible short shelf-life as device OS’ (Operating Systems) move on, etc; and authors and publishers still need to be made aware that they need to make the content accessible. However, I think e-textbooks have much to offer everyone, not least the opportunity to present information in an interactive and engaging way in a format that almost everyone can access.

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!

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.

This standard integrates the IMS ACCLIP (Accessibility for Learner Information Package) and IMS ACCMD (AccessForAll Meta-data Specifications) into a single multi-part standard.

The first three parts are now available (cost is around £65 each) and consist of:

* ISO/IEC 24751-1:2008 Individualized Adaptability and Accessibility in E-learning, Education and Training Part 1: Framework and Reference Model.
Part 1 of the multi-part standard. It lays out the scope and defines the reference model for Parts 1 and 2 below.

* ISO/IEC 24751-2:2008 Individualized Adaptability and Accessibility in E-learning, Education and Training Part 2: “Access For All” Personal Needs and Preferences for Digital Delivery.
Part 2 of the multi-part standard. It covers the IMS ACCLIP Specification and defines accessibility needs and preferences, which can then be matched to resources (as defined in Part 3 below).

* ISO/IEC 24751-3:2008, Individualized Adaptability and Accessibility in E-learning, Education and Training Part 3: “Access For All” Digital Resource Description.
Part 3 of the multi-part standard. It covers the IMS ACCMD Specification and defines the accessibility meta-data that expresses a resource’s ability to match the needs and preferences of a user (as defined in Part 2 above).

A further four parts have been given “New Project” status and will cover non-digital learning resources and physical spaces.  They have a target publication date of December 2010.

Part 8 of the multipart standard will describe how language and learning preferences will be referenced and is expected to be published by the end of 2009.

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!

Whilst the government’s intentions are no doubt admirable, WCAG (and I’m assuming they’re talking about WCAG 1.0 here) is useful but still needs a lot of common sense in its implementation.  I’m also assuming that government websites include national government, local government, public libraries, police, fire services, museums, art galleries, etc.  But what about universities, schools, educational bodies, etc?  Is this just the start of a British equivalent of America’s Section 508?  And what happens when WCAG 2.0 is finally ratified?

Whilst the standards approach is useful and can provide a lot of guidance, actual enforcement may mean that alternative approaches to accessibility are not pursued and common sense is not taken into account.  For example, an image with an alt tag will easily pass a Bobby check but what if that alt tag is completely meaningless – <alt=”gobbledygook”>? Innovative ways of tackling accessibility problems may not be thought about or explored – and in any case, it’s quite possible to be completely WCAG compliant and still be inaccessible.

So here are my somewhat Utopian ideas for an approach to accessibility:

1. Education, education, education – all design, web design and IT courses should automatically include a complusory accessibility and usability module.

2. Standards and guidelines – for “guiding” developers, not hitting them over the head with a big stick. However, they should remain as guidelines and recommendations and should not be forced on people, unless it has been proven without a doubt that a particular guideline is useful and can be successfully applied in all situations.  This is not always the case.  For example, anyone can add an alt tag to an image but does everyone know the best type of text to put in it?

3. Common sense and innovation – this is perhaps more wishful thinking on my part but we should all use our common sense and our understanding of the barriers in conjunction with guidelines and see if there are alternative, better ways of doing things, particularly as new technologies and approaches come to the fore.

4. User testing – by all types of users, from the “silver surfer” to the person with learning disabilities as well as the average person in the street.  We all know what we should do but often time and resource constraints mean that lip-service is often only paid.

Whilst standards are great for things that can be set in stone, such as nuts and bolts, sizes of credit cards etc, they are not so successful for “fuzzy” applications (like users), who have many different needs and preferences depending on different contexts, situations and how they’re feeling at the time.  Fuzzy applications (users) need fuzzy blended, complementary approaches so taking the big stick of standards enforcement to developers could be a bit of a backward step in the support and encouragement of accessibility.

“…use of an ICT [Information Communication Technology] with an accessibility barrier is not necessarily unlawful under the DDA [Disability Discrimination Act], so long as:
* Existence of the barrier is justifiable on academic, technical or financial grounds; and
* The educational organisation using the ICT provides equivalent alternatives to allow affected disabled people to reach the same learning objective as provided by the inaccessible ICT.

Where a barrier exists and can be justified on the grounds specified… above, information about the justification should be provided by the ICT producer and used by the educational organisation to inform provision of suitable alternatives.” (Becta (2007). Making Software Accessible: A Guide for Schools. Accessed 12/09/07.)

Perhaps it would be helpful if all resources were marked with metadata which described what a learning resource consisted of.  So for example, a Flash animation with captions could be identified as having audio, visuals, and captions.  This would help learning technologists and learning resource providers to provide alternatives to students.  The IMS AccessForAll Meta-data Specification provides a way of marking up e-learning resources with metadata which describes their modality – e.g. “hasText”, “hasAudio” etc.  A simpler format has also been developed by TechDis – the Accessibility Passport.  This idea allows content creators, tutors, and students to describe the accessibility of a resource in the form of a passport which travels with the resource (perhaps in the form of an online web page).  For example, a content creator describing a Flash animation could state that it is in English, with audio, visual and captions.  A student might then comment to say that there is a time lag between the animation and the captions or a tutor could leave a comment to say that it had been translated into German and its location.  Another content developer might comment that an alternative resource for the same learning objective had been developed for visually impaired people.  (Obviously, I’m not going into IPR (Intellectual Property Rights) here or the actual technical logistics, but hopefully you get the idea!)  It would also help to “inform provision of suitable alternatives” as mentioned above.

However, provision of alternative resources must still be accessible by students or further alternatives provided – as mentioned in my last post: one person’s strategy may be another’s barrier.

One of the issues with UK accessibilty legislation is that there is no technical definition of what constitutes an accessible e-learning resource or a “reasonable adjustment” as described in SENDA (Special Educational Needs and Disability Act, 2001).  Guidelines such as those developed by W3C WAI (World Wide Web Consortium Web Accessibility Initiative) have been accepted as de facto standards but they are not designed for e-learning and the UK government has not stipulated that they must be used.  Most developers do so voluntarily.  One of the main disadvantages is with the lack of technical definition is that developers can often feel as though they are “feeling their way” with accessibility.  On the other hand, there are distinct advantages.  By not defining a technical definition of what constitutes accessibility, developers are given free rein to produce solutions which, whilst perhaps not strictly conformant to the various guidelines, are actually accessible.  Also, innovation is allowed to flourish – such as in the form of the new Web 2.0 technologies – and give rise to new ways of working and approaching accessibility and learning.  Again it is the one size fits all versus holistic approach, but rather than seeing them as conflicting approaches, they should be considered as complementary.

So what approach needs to be taken to ensure that one is legally compliant?  The answer is easy: work alongside current guidelines and provide equivalent alternative resources, where necessary.  In other words, do as much of the generic accessibility as you can (such as making sure your HTML (HyperText Markup Language) validates) and provide alternatives as necessary, where this isn’t possible (e.g. provide a transcript of a podcasted lecture for students with auditory impairments or without access to speakers).  Straightforward in theory, but in practice…?