Note on Non-HTML formats

(A quick inbetweener before the user-agent’s post)

In my previous article on responsibilities in accessibility you might have noticed that I’d fallen into the traditional accessibility trap of only really referring to (X)HTML/CSS sites and guidelines. I’m quite aware of other technologies, however, barring one caveat, the same things apply.

That caveat is that you should know what you are doing.

In HTML, when you start off with a basic document, it is accessible. As you apply styling, behaviour or cruft, that is when barriers are added. In HTML, accessibility is staying barrier free.

For other formats, you have to layer accessibility on top, it’s extra.

The two non-HTML web formats I deal with regularly are Flash and PDF.

Flash started as a vector animation format, so making that work with linear devices such as screen readers is quite a job. Making Flash sites accessible is definitely possible (we audit them), but it’s something of a black art. We aren’t the only people producing accessible flash, but there aren’t many others.

PDF started off as Portable Document Format – designed to transfer print versions of documents in an interoperable fashion. It’s somewhat easier to make accessible as it can follow the HTML model more easily. However, depending on the source, it is subject to similar issues as inaccessible HTML.

In any case, a site owner or developer’s responsibility would be to ensure that whatever format you use is made in an accessible fashion. If you don’t choose HTML, be very sure of what you are getting into.

The end user’s responsibility is to check that the format is not accessible before complaining, and know how to use accessible versions of that format.

Just because it’s different to HTML doesn’t make it wrong.