It’s an innovative and fun way to promote a standard and maybe it’s something we at JISC CETIS could try!

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.

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

However, whilst a website checker can check that alt text, for example, is used with an image and will tell you if it’s missing, it can’t actually tell you whether what that alt text actually makes sense.  For example, alt text of “an image” or “asdfg” is not going be very useful to someone who doesn’t download images or for someone who uses tooltips to find out the relevance of the image (particularly where a description or title hasn’t been provided).  So developers and content authors need a hefty dose of common sense to make sure that the aspects of a website that can’t automatically be checked by a computer are actually usable and accessible.

It’s often quoted (but I can’t remember by whom) that one could implement the whole of WCAG (Web Content Accessibility Guidelines) and still end up with an inaccessible site. Whilst an automated checker might find that the site is accessible based on a simple checklist, a human may find it unusable.  Human involvement in checking accessibility is still necessary and as well as common sense, an understanding of accessibility issues and context is also required.  For example, whilst a photo of Winston Churchill might have the alt text of “Photo of Winston Churchill”, if the photo is illustrating a particular point, it could be more relevant to say “Photo of Winston Churchill smoking a cigar” or “Photo of Winston Churchill in London in 1949″, depending on context.

So whilst automated web accessibility checkers have their uses, it’s important to remember that they generally don’t include an algorithm for common sense!

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…?

The W3C WCAG (World Wide Web Consortium Web Accessibility Guidelines) v 1.0 tried a technical approach to accessibility by setting out a number of accessibility guidelines, which could be automatically tested by online validators such as Bobby. Whilst this automatic validation can validate the HTML code, many of guidelines require human input and common sense.  For example, whilst an automated accessibility validator can check that an image has an alt text tag, it cannot check that the tag actually makes sense.  People who don’t use images, such as those using mobile technologies or visually impaired people still need to know whether an image is important to the content or not.  An image with an alt tag of “image01.jpg” gives no information to website users, whilst an alt tag of “Photograph of Winston Churchill” would not only aid navigation through a web page, but it would also provide information that the image does not provide additional information to the text, so the user knows they are not missing out on anything.  As well as this, users could hover a mouse over the image to see the alt text.  This could be useful where an image doesn’t have a text caption underneath.

Difficulties with adhering to such guidelines and standards can cause barriers for people because content developers may then try to produce content to the lowest common denominator, i.e. text only.  Although text can be easily accessed by people using screen readers, it can be difficult for people with dyslexia to read and is visually unappealing.  So in this case, whilst the content is accessible for people using screen readers, it is less accessible for people with dyslexia.

Despite the drawbacks, this standardisation (“one size fits all”) approach is important.  Without a set of guidelines, developers may not know where to begin with accessibility and may not approach the basics in the same way, thereby reducing interoperability with assistive and other technologies.

One way to complement the standards approach is to produce alternative but equivalent versions of content.  For example, transcripts can be provided for podcasts, text heavy content can be offered as with animations or images or in simple language for people with learning disabilities or language learners.  This holistic approach has been proposed by Kelly, Phipps, and Howell in Implementing a Holistic Approach to e-Learning Accessibility.  This approach also takes student learning styles and pedagogy into account as well as technical and usablity issues.

Standards and guidelines are important but they need to be used with common sense and in combination with other approaches. Standards and guidelines can help with the physical presentation of the content, whilst holistic and other approaches can help the user to interact and use that content in the format best suited to their needs.

Podcasting can consist of either audio or audio and voice (video).  Both Section 508 and the W3C (World Wide Web Consortium) WCAG (Web Content Accessibility Guidelines) recommend that alternatives are available for auditory and visual content – e.g. a transcript for an audio podcast; captions and/or transcript (and possibly a description of the video, depending on its format) for a video podcast (this could take the form of a presentation with voice-over or an actual video).

Podcasts can be of particular value to people with visual disabilities or physical disabilities, and people who want to learn on the run, such as travelling into work on the bus, exercising, waiting for a train, etc.  However, including a transcript of a podcast, particularly in the educational environment, will not just benefit people with hearing impairments but it can also benefit all students. 

One example given in the EASI podcast was of lecturers making their lectures available as a podcast for students to download.  The presenter suggested that students would probably only want to listen to a podcasted lecture once (or twice, if they had a high boredom threshold) and that, as in a normal lecture room situation, the student would make notes as they went along.  However, if a transcript was provided of the podcast, the student could print it off (as well as listen to the podcast) and make notes in the margin.  The transcript and annotations could easily be carried around and used as a useful revision resource at exam time.

Another problem is that it’s not always easy to find one’s way around a podcast – there are no headings or marker points (although maybe this will come in time) as in a large document – so the listener is forced listen to the podcast all the way through in order to find the relevant bits.  Providing a transcript alongside the podcast allows for easy navigation, it can printed by a Braille machine, and allows for annotation by the student.

Although there are obviously the cost benefits of writing a transcript, providing an electronic resource in two different formats could greatly increase the value of that resource and will benefit a greater number of students.

There’s been some discussion over on the DC-Accessibility JISCMail Discussion List (February 2007, “Not Accessible or Adaptable”) about a lot of issues, including whether alt text should always be added to an image. One contributor to the discussion gave a link to a slideshow of dance photographs, where:

“the author refused to label the images with text… his argument being that the photographers images capture and demonstrate an emotional experience, and that whilst text can perform the same expression, he’s not the person to annotate them.”

The photographs in question are various stills from dance rehearsals and performances.  There is no accompanying text of any kind, but most people would probably recognise that the people in the photos were involved in some sort of dance medium from the clothes being worn, the environment, and from the positions of the bodies.  However, unless one knows the language of dance or the context in which the dance is being performed, the photos may have no further meaning – and could therefore be inaccessible to some people.

This actually brings up several issues:

1. How can one describe an image that expresses emotion or abstract concepts?

2.  If such concepts can be described, who should be responsible (and have the capability) for doing so?

3.  Where does alt text fit into all this?

1. Describing Emotion and Abstract Concepts

So is it possible to extract emotional and abstract meanings and describe them for people who do not have a concept or understanding of such areas?  The Dayton Art Institute Access Art Website has attempted to do so.  For each artwork on the Access Art website, there is an image, a section on the artwork in context, comments by the Art Director (including an audio commentary) and a description of the artwork. Each section is no more than a couple of paragraphs. For example, the description of Frishmuth’s “Joy of the Waters” has attempted to put across abstract concepts such as the mood of the statue:

“The girl’s springing, energetic step, joyful expression, and animated hair create an exuberant mood and suggest that she may be a water sprite.” (Marianne Richter, Dayton Art Institute)

This helps make the artwork become more accessible for visually impaired people and for people who do not know the language of art. 

2. Responsibility for Describing Images

The people best qualified to describe a visual resource are probably the people who have decided it should be included in the first place.  For example, someone with archaeological experience is probably best placed to describe an image of a stone tool, whilst a geography tutor may be the most suitable person to describe a meteorological image from a satellite put onto the university’s VLE (Virtual Learning Environment).

The descriptions used will also differ depending on the image’s intended audience.  A museum generally has a wide public audience with many different levels of understanding and access requirements, whilst a Geography department may only have a small number of students at a fairly high level of understanding. 

So, unless the photographer in the quote above, is also versed in the language of dance, he is unlikely to be able to describe the dance photos he has taken.  Even if he were, he would also need to be aware of the level at which they needed to be pitched in terms of language, description, and audience. 

3. Use of alt Text

So where does alt text fit into all this?  The W3C (World Wide Web Consortium) WCAG (Web Content Accessibility Guidelines) recommends providing:

“…a text equivalent for every non-text element (e.g., via “alt”, “longdesc”,  or in element content)… For complex content (e.g., a chart) where the “alt” text does not provide a complete text equivalent, provide an additional description using, for example, “longdesc” with IMG or FRAME, a link inside an OBJECT element, or a description link.”

Therefore, alt text should be used for every image (even empty alt text should be used for spacers and decorative images), but it should only provide a brief text description of the image – the Guidelines on ALT Texts in IMG Elements recommends no more than 50 characters.  Longer descriptions of an image, such as those describing complex images, emotions, or abstract concepts, should not be included as alt text, but should either be attached as a separate link (perhaps using the longdesc or d-link elements) or added next to the image. 

Alt text can also be different for different audiences and purposes (see WebAIM’s Communicating the Purpose of the Graphic) and does not necessarily need to be completed by experts.  However, although the photos of the dancers should have had alt text, they may well have needed someone with a knowledge of dance to add it.  Basic alt text, such as “photo of dance students” could have been added by anyone but would there be any benefit to seeing roughly the same alt text added to over 80 images?  A choreographer would be capable of adding more informative alt text, such as stating the dance step or intention, e.g. “photo of a dancer in fifth position”, particularly where the intended audience was other dancers or dance students. 

Alt text is a requirement under the WCAG guidelines, but it shouldn’t be used to describe an image in a thousand words – these have to be written elsewhere.