NB: this wiki was originally used for a presentation by Roberto Ellero and Claude Almansi in an ITForum discussion about accessibility in educational context.

Accessibility hi

An obligation and many advantages te ,mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm i love chocolate who dosent love chocolat TROOOOOLOLLLLLLLL

I don't love chocolate. I am allergic.
Aafugsoafgapgfyugsuycguydgcgauviygsagvyfiuesdgfvuygyùufgscsyu ghefysutfgywfidyugcftdyifcvxyuzdsvgcuyvsuyvcvecvdsivdscydvcyiyuattributes) will simplify reading for blind people who use a screen reader with which they can jump from header to header, but also for students who have reading problems.
  • captioning a video tutorial will make its spoken content available to deaf students, but if you also offer the text transcript used for the captions, all students will find it easier to take notes (see also the Multimedia Accessibility section below)

Accessibility in Mind

One of the great resources about Web accessibility requirements is WebAIM.org, which stands for Web Accessibility In Mind. This is an important point. Teachers do not have to master all the requirements before they start making learning objects: most educational institutions in countries where accessibility is a requirement have accessibility consultants for the more complex issues.
However, putting oneself in the shoes of people with sensorial, motor and/or cognitive disabilities when preparing such learning objects is a good start: it also helps understand accessibility rules as resources rather than constrictions.

Why a wiki?

ITForum discussion papers are usually presented as PDFs. We are using a wiki for two reasons:
  1. Roberto Ellero lives in Italy, and Claude Almansi in Switzerland, so a wiki is handier for writing together
  2. Accessibility resources are evolving fast: since we started this wiki 2 days ago, for instance, Google announced that it was making its speech-to-text technology available for automatic captioning of YouTube education videos (see Multimedia accessibility below).
Besides, we can back up this wiki as HTML pages, which can in turn be reasonably easily transformed into an accessible PDF.


"A black text on a black background would pass automated accessibility tests", as the joke goes, because a screen reader used by a blind person could still voice it. And without going that far, some people end up making text-only pages lest they violate some accessibility rule. This may be OK for blind or deaf users, but it is often not for people with reading or cognitive disabilities. Full accessibility for everybody may not be reachable, but it is possible to strive at it by offering several ways to get at the content, as in the examples that follow.

Alt attribute for pictures

Pictures can be used in accessible documents, provided they are given an alternative description. If this description can be kept short, it should be inserted in the "alt" attribute (see http://en.wikipedia.org/wiki/Alt_attribute) of the picture.

Alt v. title attributes

Most text and web editors - whether desktop or online - will prompt you to add a description when you insert a picture. Some - like this wikispaces one - are not entirely saftisfying, because the result is having the same text for the "alt" attribute and the "title" attribute (which should only give the title of the picture). And that's a bad idea because then a screen reader would voice the same text twice, which is boring and time-consuming (see http://ncsuwebdev.ning.com/profiles/blogs/alt-attribute-v-title).
One way to work around this issue is to first upload the picture to a platform that gives an embed code containing both "title" and "alt" attributes.
Example: say we want to insert the picture in http://www.flickr.com/photos/73527420@N00/374742159/sizes/s/ here. The default embed code says:
<a href="http://www.flickr.com/photos/73527420@N00/374742159/"
title="Bild043 ETH Zurich paid by Microsoft by calmansi, on Flickr">
<img src="http://farm1.static.flickr.com/157/374742159_bdceffa63f_m.jpg"
width="240" height="180"
alt="Bild043 ETH Zurich paid by Microsoft" /></a>
Here too, "title" and "alt" attributes are the same. But we can change them before embedding the code [1] :
<a href="http://www.flickr.com/photos/73527420@N00/374742159/"
title="ETH Zurich paid by Microsoft">
<img src="http://farm1.static.flickr.com/157/374742159_bdceffa63f_m.jpg"
width="240" height="180"
alt="Projection of the Microsoft logo on the façade
of the ETH (Federal polytechnic school) in Zurich" /></a>
and we can now use this modified code to insert the picture - with proper "title" and "alt" attributes - here:
Projection of the Microsoft logo on the façade of the ETH (Federal polytechnic school) in Zurich

Long description

Some pictures need a description that would be too long for the "alt" attribute. Here are two examples of solutions for these cases:

The accessibility bicycle

See the linked page and the explanation below

This accessibility bicycle appears in the linked web page, i.e. Current and Evolving Accessibility Practices, of the Office of Learning Technology of the University of British Columbia.
As reproduced here, it might perhaps pass an automated accessibility test: it has an alt attributebut the alt and title attributes say the same thing, repeated then in the caption under the picture. And that's incorrect: the title attribute should give the title, the alt atrribute should give an alternative text description of non-text objects. It is silly and rude to make blind people hear three times the same information. But that's the only option for describing uploaded images on wikispaces.com.
There would be a fairly simple work around: upload the picture to a picture-hosting platform like flickr, grab its embed code there and modify it to get proper title and alt attributes, then use the "embed other html" widget of wikispaces.
But it would not solve the main problem, i.e. conveying all the text parts of the picture, which would be too long for the alt attribute. So let's look at the corresponding code part in Current and Evolving Accessibility Practices to see how they solved it:
<a href="http://olt.ubc.ca/Accessibility%20Bicycle.pdf">
<p align="center"><img alt="Accessibility%20Bicycle.jpg"
 width="576" height="371" /></p></a>
I.e. they linked the mute picture http://olt.ubc.ca/Accessibility%20Bicycle.jpg to http://olt.ubc.ca/Accessibility%20Bicycle.pdf, where the whole text can be read by a screen reader.
Making such a bicycle-shaped textual PDF is not easy, granted. But one could also link to a normal web page where the same concepts would be developped in text, as in:

The HTML5 Super Friends

In Accessibility: Take 2, Kyle Weems discusses technical ways to make images requiring long descriptions accessible to blind people. And he points to the solution he has used for his HTML5 Super Friends comic in http://www.cssquirrel.com/comic/?comic=35. A screen reader (or the source code of that page if you don't have a screen reader) links the comic's page to its transcript in http://www.cssquirrel.com/comicscripts/script35.htm .
The coding solution used by Weems is perhaps rather complicated for many teachers, but the principle of allowing blind users to read a textual description should they wish to can be enacted in other, more simple ways: by directly linking to it on the image itself, as in "The accessibility bicycle" above, or by adding a link on the word "Description" or on the letter "D" under the picture.
As to educational value: in language classes, asking students to describe pictures is a staple exercise, often perceived as extremely boring by the students. But if they knew that the description was to serve a practical and useful purpose, they would probably be more interested.


Videos can also be made accessible to deaf people by captioning them, and to blind people by adding an audio description of what goes on without words.
Adding an audio description is a bit complicated. Therefore, for teaching purposes, it is better to plan the video so that there will be no need for an audio description: e.g. in the case of a chemistry experiment, by having the experimenter describe verbally what s/he is doing.
Captioning is way easier: there are several online and desktop user-friendly tools for that [2] . But until very recently, transcribing the audio was time-consuming - and rather boring. However, on November 19, 2009, Google announced a:

New automatic captioning tool for YouTube videos

And automatic time-coding for transcripts.
Here is a video explanation about these features:

Further info in Automatic Captions in YouTube by

Not all flash players - whether for audio or for video - can be used with a screen reader by blind people. In doubt, add a straight link to the audio or video file. For instance, in the case of the YouTube video about automatic captioning above, we can add a link here to its audio capture:
This way a blind person could download it and play it.
There are only 2 instances where visually given info is missing from the audio comment:
  • at 1:34-1:47, in the explanation about automatic time-coding of a transcript without time-codes, the screencapture shows that this option is only available for English
  • at 2:09-2:12, in the words "You can check out the captions and timecodes by clicking on the caption track here", "here" refers to the link on the word "English" shown in the screen capture.
But for your own videos, as you can download the text file of the caption track, you could offer it too, and add the missing info between square brackets. Or even splice it into the audio capture.


Slidecasting, i.e. synchronizing a slideshow ("PowerPoint" in MS jargon) with audio [3] is often a better way to offer an online record of a conference than a video that only shows someone speaking, and a sometimes blurred and/or slanted view of his/her slides. It can be done, for instance, at http://www.myplick.com or at http://www.slideshare.net, and the resulting slidecasts can be embedded in another site, blog or wiki.
You can add a transcript of the audio in the notes of the slideshow: they won't show in the slidecast, but deaf people can dowload the slideshow with the notes.
However, these slidecasts are also presented in a flash player that cannot be used with a screen reader (see above). In theory, people can download the slides and the audio separately - but they have to sign in for that, and signing up can be a drag, especially if you are blind. So if you use a slidecast in your site (etc), add direct download links for the slides and for the audio too [4] .


Text is also part of multimedia and, as shown above, essential for making audio and visual content accessible. It is also easier to re-use (note taking, quoting by copy-pasting etc). Some accessibility aspects of text:

Don't impose sizes in pixels

While most browsers can ignore such indications, they may lead to problems when people zoom the text, if the author only thought of one precise character size.

Beware of tables and forms

Making tables and interactive forms that can be used by a blind person with a screen reader can be tricky. Either consult an accessibility specialist, or find another way to do the same thing.

Use styles

Changing font size and shape is only visual, using styles conveys a meaning that will be perceived by screen readers used by blind people. Examples:
  • If you move the left margin one inch to the right for a quotation, the screenreader will just say the margin has changed. If you use the quotation style, the screen reader will say it is a quotation.
  • If you change the font size and use bold for titles, the screen reader will just say the font has been modified. If you use header styles hierarchically for your titles and subtitles, a blind person can use the screen reader to skip between sections. You'll also be able to provide a table of content with links to the various sections.


The accessibility and usability of PDFs have - potentially - improved greatly since Vincent Flanders wrote Chairs are for Sitting. PDF is for Printing. But making a really accessible PDF remains complicated, and requires specific software - though you can make a reasonably accessible one without such software by:
  • using a text editor that foresees exportation as PDF, with the possibility to fine-tune the exportation settings [5]
  • refraining from tables and forms unless you know how to make them accessible (see above)
  • using styles (see above: header styles can automatically produce an alternative navigation menu by titles instead of just the list of thumbnails on the right of the PDF)
  • refraining from making PDFs by using the "Print as PDF" feature of your printing menu, which will produce a textual PDF, but without navigation features, and links are likely not to work [6]
  • never using "scan as PDF" when scanning a printed document: it only produces text images that can't be searched - or read with a screen reader
  • never imposing copying and/or printing restrictions to users:
    • even if it is possible to forbid copying and printing and to allow reading with a screen reader, people with reading disabilities or who are not fluent in the language used must be able to copy the text exactly to look it up online, or to ask someone about its meaning.
    • these restrictions are silly anyway, because they can be by-passed with a screen capture and possibly by doing the Optical Character Recognition of the capture
Above all, think twice before offering text content in a PDF:
  • Is it really necessary?
  • What for?
  • Won't the same content in a web page or in a normal formatted text file (.doc, .odt ...) also print decently?

Web 2.0

Web 2.0 "read/write" online applications are great, but some have accessibility barriers: see the section about flash players above; visual CAPTCHAs for creating an account - or worse, for adding a comment - also block blind people.
However, the Web 2.0 platforms are improving, and so is accessive technology. Moreover, people with some types of disabilities (cognitive, reading, but also severe motor disabilities) can be very keen on using them - think of social networking - and yet particularly need guidance in this. So schools cannot just simply ignore them: compromises must be found.
If your school has an accessibility consultant, ask him/her. Otherwise, there is a LinkedIn Web 2.0 Accessibility Forum (you'll have to sign up, but it is free).


"The foundation of accessibility for people with disabilities is the concept of redundancy. A foundation of redundancy allows the configuration of products, so an individual can access information and the computer in a method that is most beneficial and meaningful to that individual.
Accessibility to products is a compromise. All accessibility features do not need to be built into a product. However, the "hooks" or links to information for access for people with disabilities MUST be in place to provide access through existing accessibility tools. "
From: Access to Multimedia Textbooks and Instructional Materials (Texas School for the Blind and Visually Impaired).


The Cory Doctorow on the Three Strikes Death Penalty page shows how this redundancy can be offered easily, with simple, for-free tools. Given the existing original video in http://blip.tv/file/2857773, the tools used were:
  • IMovie, desktop proprietary video editing software present by default on Mac computers; but there are other alternatives: see http://en.wikipedia.org/wiki/List_of_video_editing_software
  • Audacity, desktop free, multiplatform and for-free audio editing software, with keyboard shortcuts
  • DotSUB, for-free web application for captioning and subtitling, which also produces text transcripts; the video player for the transcription interface has keyboard shortcuts; unfortunately some online authoring platform do not accept embedding the DotSUB viewing player - hence:
  • YouTube, for-free video hosting web platform where you can add captions and comments to/on the video
  • Wikispaces, for-free [7]



http://www.diigo.com/user/calmansi/accessibility contains resources tagged "accessibility" over three years ca. So some links might be dead

For education

http://www.diigo.com/user/calmansi/accessibility_of_elearning contains resources mentioned by participants during the 2006 online Accessibility of eLearning seminar, and other resources gathered afterwards. Again, some links might be dead.

About us

Roberto Ellero, a videomaker, webdesigner and accessibility specialist, founded the Webmultimediale project in 2006. For more inf, see http://robertoellero.it/videomaker-webdesigner/ (in Italian, but will translate passably with Google language tools)
Claude Almansi, translator, language teacher and accessibility advocate, participates in Webmultimediale. For more info, see http://etcjournal.wordpress.com/2008/10/01/claude-almansi/ .


As the Webmultimediale site is in Italian, here is a video (with English and Italian subtitles, and Italian sign language translation). It is an announcement of a coming seminar lead by Roberto Ellero together with Silvia Mattia, Roberta Gherardi and Simone Cericola at Cultura Senza Barriere 2010, and it summarizes in a nutshell what Webmultimediale is about:


English text

When you work on video accessibility, you find out that the prejudice of an absolute, normative language – e.g. textual language in the narrow sense – arises from a scanty familiarity with other kinds of languages. You also realize that conveying the same content in different manners reveals new aspects that remained previously in the shadows. The common prejudice tends to privilege the importance of text.
At Cultura Senza Barriere (culture without barriers), I shall describe how to communicate by using simultaneously all possible languages: text, video, audio, audio description, images, subtitles and sign language towards an ever increasing fullness.


The Discussion page will contain messages from the ITForum mailing-list discussion on Accessibility whose authors will have granted permission for re-use.

  1. ^ We could also remove the link to http://www.flickr.com/photos/73527420@N00/374742159, the main page for the picture, or link to another page; but let's leave it
  2. ^ See for instance the ones described in Three Video Captioning Tools.
  3. ^ see http://en.wikipedia.org/wiki/Slidecasting
  4. ^ As under "Liens directs" in http://almansi.wikispaces.com/CTE
  5. ^ OpenOffice Writer for instance. Illustrated tutorial on how to make accessible PDFs with OpenOffice Writer in http://www.appligent.com/adobeaccessibility/AdobeAccessChapter3a10.html; some of it might also work for MS Word, perhaps.
  6. ^ The Page List of this wiki offers the option to save pages "as PDF", produced by TCPDF, apparently in the same way as by using the "Print as PDF" feature, and with the same drawbacks.
  7. ^ In this public version. For the various non-paying and paying options, see http://www.wikispaces.com/site/pricing. See also http://www.wikispaces.com/site/for/teachers about non-paying private, ad-less wikis for K-12 educators.