I.e. Accessible Rich Internet Applications with Flash, Flex & Air.

This presentation at Techshare by Andrew Kirkpatrick (Sr. Product Mgr, Accessibility, Adobe) took us through some of the technologies available, with a special eye on the accessibility possibilities and things you need to watch out for. With all the HTML5 buzz/arguments, it is worth remembering that many of the current issues there have already been dealt with in Flash and other technologies.

There were also a couple of announcements here of major improvements to accessibility for two Adobe products.

Andrew had a bit of trouble with PowerPoint and the conference system, I was a little surprised he didn’t PDF the presentation and use Acrobat at full screen? That’s a useful fall-back, but he took it in his stride, and it was of course the demos that people were most interested in anyway.

Quick side question: What’s the most suitable element for interjecting comments into an outline of someone else’s text in HTML 4 or 5? I’m not quoting directly, so it doesn’t fit the usual transcription methods.

Andrew’s Presentation

We define Rich Internet Applications as web based sites with desktop type functionality.
However, it’s a slippery slope definition, as you can have boring desktop apps [e.g. help] and very interactive web applications.

I was involved in the Section 508 at an earlier state, where previously desktop and web guidelines were considered separate, but they are really the same set of issues.

Flash platform History

• Flash player started support of MSAA with version 6 in 2001. These days, AT users should have an expectation of access to flash content.
• Flex provides as set of Flash based controls. [Flex is to Flash what jQuery UI is to JavaScript]. 28 accessible control types (compared to 7 in HTML). Flex developer previously needed to turn on accessibility, now in the [upcoming version 4 release] it will be on by default.
• There are still things that need attending to by the author/developer, e.g. alt text.

Air

Air delivers Flash based apps to the desktop. At the moment, you’ll see a lot of twitter apps, but soon you’ll see things like company HR applications. Allows you to develop in Flash and/or HTML, and deliver cross platform.

Up to now, Air applications have not been accessible. I can announce this week that the next version will have support for accessibility. Uses Webkit, and we can’t yet use that to convey accessibility information yet, so accessibility in HTML isn’t there, but Flash based content is. [Flash more accessible than the HTML, oh the irony!]

Adobe is working with Freedom Scientific and NVDA, plus vendor programme.

Examples

• Creaturediscomforts.org, a Flash app, interesting because they offer subtitles and sign language. But, it doesn’t have accessible controls.
• My story. In Jaws you can use Ins-F5, review the control. Can read through the text. When using the screen reader, it didn’t open player automatically. The developer detected AT, and doesn’t run it by default. Then the user can start it when they want to.
• See other examples at Adobe.com/accessibility/examples.
• Kingtut.org uses the default flash components, skinned, accessible interface with little additional effort.
• Easy-Youtube uses an HTML interface to control the flash.
• CNET TV [sometimes] provides captioning.

Improving the current situation

The User’s role:

• Let developers know if their application doesn’t work for you. (Expectation is that it should work.) If it’s a train wreck, let them know.
• Let developers know if their app works well.
• Don’t turn flash off by default (please!)
• Let Adobe know what works, and what doesn’t, we can campaign on your behalf.

Developers role:

• Following WCAG 2 is a great start.
• Flash authoring tool has panel, but the most powerful flexible way is via Actionscript.

Pertinent WCAG 2 checkpoints

Meaningful sequence

The default order in Flash is determined by the player, often not correctly (depending on the layout). For more complex layouts a human needs to set this order, either in control panel or in actionscript.

aDesigner is an eclipse based tool to help evaluate flash content, including the ordering.

Allow for resizing text

This is not done for you by the player, but you can use CSS to style the text, and then Firefox & Internet Explorer’s browser controls will resize text.

[I asked: what about varying layout?]

If you add a font resizing button, that could also change a ‘state’, which could then change the layout, or do any other change you like.

Contrast

This is really an authoring/design issue, neither helped nor hindered by the technology.

Name, role, value:

Flex and Flash support these automatically, you may not need to do anything. It’s not so easy when you use more complex components (like the accordion in Flex). aDesigner and Inspect 32 can be used to evaluate Flash content.

See the Adobe.com/accessibility site for more, and the blog for the latest things (that haven’t been delayed by the web team).

Bob Easton has a useful test case page, with which I tried in everything I had to hand:

• Firefox 3 with zoom, and regular text-size changes.
• Safari 3 with text-size changes.
• IE 6 & 7.
• Opera 9.5.
• JAWs with IE7.
• Windows Eyes with IE7.
• VoiceOver 2.0 with Safari.

The image replacement techniques were generally fine with a couple of small bugs, most of which don’t appear on Mezzoblue list. Having them as links seems to be problem, and increased font size does seem to be an issue for the Gilder/Levin method unless you start with a small text size.

Problem

When I got to the sIFR method (scalable Inman Flash Replacement), the Windows based screen readers read out the heading twice. I also checked on the official example page as well, just to be sure it wasn’t an old example.

Things may have changes since the sIFR method was introduced, but now most Windows based screen readers (i.e. not VoiceOver) are quite happy to read out the Flash. You get something like:

Flash movie start.
Heading level 3, scalable Inman Flash Replacement.
Flash movie end.
Heading level 3, scalable Inman Flash Replacement.

Solution?

There are two broad ways around it:

1. Hide the Flash content from screen readers.
2. Hide the ‘hidden’ content from screen readers.

I did try (and succeed) in creating an example that hides the actual text from the screen reader, but that’s probably the wrong way to go.

Given that there are still quite a few user-agents (e.g. VoiceOver) that don’t cope with Flash, it would be better to leave the text as available as it is, and make the Flash inaccessible. I assume setting wmode to transparent would do that, wouldn’t it?

• Removing restrictions on use of the SWF and FLV/F4V specifications
• Publishing the device porting layer APIs for Adobe Flash Player
• Publishing the Adobe Flash® Cast™ protocol and the AMF protocol for robust data services
• Removing licensing fees – making next major releases of Adobe Flash Player and Adobe AIR for devices free

Two potential advances come to mind:

1. We should be able to get at the spec, and (some people might be able to) create tools for testing and improving the accessibility of flash instances.
   However, this hasn’t happened for PDF, so I won’t hold my breath on this one.
2. It might clear the way for being included on the iPhone. Although performance issues are the probable cause of it’s exclusion so far, if Apple can create their own version of the player, they may be able to get around that.

The actual project is at adobe.com/openscreenproject/.

I have to thank Jeff Bell and Cheri Ekholm of the Microsoft Office team, they kindly answered my many pestering questions, and took time to look into the issues I was having.

The Source

I created a simple document using Word 2007, using it’s default font (Cambria), and the default styles. Into this document I added a title, some lists, a few paragraphs, an image (with alt), a quote, a two column section, and a table (with headings). I’ve put all the documents in a zip file (650k) if anyone else wants to test them as well.

Basic stuff, but everything was correct for making an accessible PDF, i.e. using the native style structures in Word.

The conversion settings

I used the defaults for each method, making sure that it was creating a tagged PDF. These are the settings in the office plug-in:

These are the options from Acrobat 8.1:

The results

Both Acrobat and Office produce a decent document that appears the same as the original, and is tagged. However, there are some differences.

File size

The Acrobat version was 148KB, the Office one is 424KB. For such a simple document (with default fonts) I was quite surprised, apparently it’s due to more information being embedded, which is obvious in small documents, less so in larger documents.

Tags

There were some immediate differences, although mostly it was subtle differences like Acrobat using <Heading 2> and Office using <H2>.

The best way to assess the tags is to view them in Acrobat Pro, here are a couple of snapshots, you’ll probably want to open them in new windows or tabs:

Created with Acrobat

Created with Office 2007 PDF plug-in

The main problem found was in Office, where the tag for the image was mysteriously placed immediately after the second paragraph, instead of on the second page. This is likely to be a bug.

The second issue was that the quote style in Word didn’t translate to a quote tag. Apparently, this is because Office uses the underlying styles, not the style name shown when editing. For example, this is the modify style dialogue for the Title style:

This method creates two issues in this document:

• The Title style came across as a paragraph.
• The Quote style came across as a paragraph.

If a style isn’t in the styles set, you can’t create a template that will automatically produce the right tag in the PDF. Comparing the styles list against the PDF tag list, there are quite a few missing (e.g. article, link, reference). However, I’m not actually sure how important that is, at least for now, as current screen readers don’t make use of ‘rare’ elements yet.

Acrobat uses the style names, rather than the style they are based on, so whatever you call each style will become the tag. That is why you get <Heading 2> rather than <H2>.

I sent the documents to a friend (Léonie Watson) for a ‘blind’ test (in both senses, she didn’t know what created each PDF), using current versions of JAWs and Acrobat. Most of the tags were fine in both, so both versions of the headings ‘work’, even though the Office method matches the PDF standard set better. The Acrobat version seems to put the bullet points on separate lines (in the tags, therefore for screen readers), which is strange when reading.

What it does mean is that the default styles will not create what you think they do when using the Office plug-in. This makes it extra effort to set up a template for creating accessible PDFs.

Other accessibility features

The read out loud function works equally well for both – no problem there. Changing the colour scheme also worked well for both.

Document re-flow

This was not the same. In a previous document (from the last article) reflow had removed the text (due to a font issue). For the Office created PDF test document, reflow doesn’t actually work at all, the option is grayed out:

I can’t tell why this is, I don’t know of another PDF reader that offers the function, and the spec is, well, long, and I haven’t read it yet. It might be that the Office plug-in doesn’t do something, or it might be the Acrobat reader isn’t accepting the input as it should.

OpenOffice

OpenOffice is the poor cousin in terms of creating accessible PDFs, you’d have to do quite a lot of Work (in Acrobat Pro) to overcome the issues for each document:

Open Office (at least from version 2.4) can export a tagged PDF, and when creating from within OpenOffice (rather than importing a Word file) the headings, lists and alt text all come through fine. Changing colours and reflow (with the exception of the image being dropped to the bottom) also work fine. (Thanks to David for the update).

Just be careful to tick the ‘tagged PDF’ option, as it is not on by default.
Also be careful when importing from Word documents, as the following problems were found with this method:

• The Alt text was not included.
• Headings were brought through as paragraphs (even though they were OpenOffice headings).
• Lists items were not nested in the list (i.e. the second item was not in the list).
• The Quote was not brought through as a quote.

Overall

Overall, the Word & Acrobat combination provides the most effective workflow for creating accessible PDFs. With a good template set up, or even using the default styles, it’s pretty much fire and forget (assuming the document includes everything it needs).

However, it’s worth remembering two things about the Office 2007 plug-in:

1. It’s a version 1 program.
2. It’s free.

The first means that it could be updated in future to iron out the bugs (notably the re-flow issue, as you can’t get around that).

The second means that it might be more effective for an organisation to use the Office plug-in, and have a couple of people with Acrobat Pro to sort out the few accessibility issues. We haven’t quite been relieved of the Adobe accessible PDF tax yet, but it’s a step in the right direction.

Appendix: Other Office programs

Cherie Ekholm from the MS team described a little about how tagging with the plug-in varies depending on the program. Word, PowerPoint and Publisher have extensive tagging. (NB: I don’t think Acrobat supports Publisher, at least not well in the testing I’ve done).

Visio, Access, OneNote and Excel have much more limited tagging, but all do give users the opportunity to add alt text for images. I think Excel is the only disappointment there, the others have never benefited from good tagging support. I can’t imagine how you would usefully tag Visio, but I’ll have a look later.

The Excel functionality was described this way:

while Excel does some tagging of <TR> and <TD> with the Office plug-in, it doesn’t do it well unless you use the new tables feature in 2007 for the data you want to tag. Because there is no mechanism to mark the header row in an Excel table or in the spreadsheet itself, there is no tagging for <TH>. Word is currently the only Office application that has the ability to identify table headers. As a user, the Excel behavior doesn’t make sense to me because most spreadsheets look like they are a type of table (whether you apply the new table feature or not). But Excel spreadsheets are not tables unless you use the new feature.

The important thing is that it’s possible to structure the PDF from the base document, before the PDF process is started. Then the next most important aspect of creating accessible PDFs is that it’s easy, default, or possible to enforce the accessible practices in the base document.

So we now have step one.

This tool allows you to visualise good colour combinations on a Photoshop style colour picker. It’s primary use is finding acceptable colours from an existing inaccessible combination – while maintaining the aesthetic appeal of the original.

Tom created it for internal use to speed up his design process, but I think it’s good enough to make available now, even though Tom wants to add more to it. Although I don’t do design as such, if I did, this would be a very useful tool to choose colours from. Just click on the SWF download at the bottom of the Colour Contrast Visualiser page, or download the AIR version for local use.

Of course, to create an accessible PDF from Word, the Word document needs to be done properly, otherwise it doesn’t matter what you use to create the PDF, it won’t be accessible.

I had previously heard that Office 2007 (or 12 back then) was going to have built in PDF support, with tagging (i.e. accessible output). Not too long ago I installed Vista and Office 2007 on my work machine, but there was no sign of it. Then I found the Microsoft Save as PDF or XPS Add-in for 2007 Microsoft Office.

It would be great if you could just ‘save as’ (which itself is an improvement on having to remember that PDFs are print-outs) and create a PDF of your document from Word, Excel or Powerpoint.

Whilst preparing the materials for a course on accessibility PDFs, I thought I’d give it a go with a really simple document. The results initally looked great (apart from being several times the file size), but then I dug in a little.

The document is very simple, with just headings, lists, paragraphs and images, but all the text is saved as images.

These images do have ‘actual text’, but that just strikes me as a work-around. According to Adobe’s own Accessibility Techniques, ‘Actual Text’ is for:

text that will be sent to a screen reader. If text is entered, the entered text will be read, and not the text that may comprise the displayed document content. This property should be entered only if you
want something other than the content of an element to be read by a screen reader. Basically, this is replacement text.

For comparison, ‘Alternate Text’ is additional or descriptive text that can be used to describe an image, formula, or other item in the document that does not translate naturally into text.

So it isn’t wrong to use this attibute for passing text through to alternative readers, but why isn’t it just text?

Compared to the same document created from Word 2003 & Acrobat 8:

The difference it makes in a screen reader is fairly stark, even if you consider it technical accessible:

how

difficult

is

it

to

understand

like

this?

Because of all the separated images a screen reader can’t tell what’s a sentence and what’s just a word. (These simple test documents can be made available if you want to check this.)

Worse still, the accessibility features built into Acrobat are useless:

• Reflowing the document to fit the screen width just blanks out the content.
• Zooming into the text shows blockier text than when using an Acrobat created PDF.
• Using different colours schemes doesn’t work (again, blank content).
• You can’t select text to copy and paste elsewhere (not strictly accessibility, but annoying).

I would say that this is a very misleading dialogue:

Given that the Office 2007 PDF pluggin is a free download (once you’ve paid for Office 2007 of course), I was hoping that most people internally could use that instead of paying the Adobe tax for accessible PDFs.

Unfortunately, without providing reasonably accessible output, I can’t use or recommend that option.

Update – it’s a font thing

Thanks to the quick responses from Microsoft, it turns out not to be as bad as initially thought. The use of a non-standard font seems to have triggered the use of bitmapped text. I changed the font to Arial, and the structure and text came out fine, possibly clearer than the Adobe version.

In comparison to the non-standard fonts version:

• Reflowing the document to fit the screen width shows the text content, but blanks out the image.
• Zooming into the text is fine.
• Using different colours schemes is fine.
• You can select text to copy and paste elsewhere.

So, much better, although I can’t work out why the image disappears.

However, half the reason we use PDF in the first place is that we can embed our (nicer) company font into documents we send out. The Microsoft test team are currently investigating why this font triggered the issue, but for now the advice (from me) has to be to use ‘standard’ fonts and test thoroughly for accessibility.

Oh, and although I’m writing this article, much of the implementation (and Flash expertise) is from my colleague and co-author Tom Hooper. Any Flash questions will be directed his way!

Intro

Recently we re-launched our CMS’s site, defacto-cms.com, and with it a flashy (in both senses) case study selector. If this were a clients site it probably wouldn’t be worth the time for this purpose, but now the framework is in place it will be easy to replicate.

The ‘carousel’ navigation widget is only used in the case-studies section at the moment, and it is essentially local navigation for that section. You select a case study, it spins into the center, and if you select it the content below is replaced by that case study’s information. The visual effect is not 100 miles away from the iTunes ‘coverflow’ effect, although there are some subtle differences. It uses the Papervision3D open source ActionScript 3 engine for the 3D effect, plus a fair bit of scripting!

NB: Don’t use this in Safari yet! There’s a crash-bug we’ve discovered in Safari affecting the AJAX. You can load and play, but don’t select a case study with the Flash.

It is worth noting that we needed to use quite a recent version of Flash to get that effect (V9.0.28+).

What’s different?

I don’t think there is much new in terms of techniques, although I haven’t seen people use the content of a page as source for the Flash in this way before. It has also had quite a lot of attention in terms of bullet proofing and making accessible.

The foundation

The foundation is straight XHTML 1.0, and on a basic browser you get a list of links with images.

The HTML needed to run it is a container div, its content (used in the Flash), and an object which is used to configure the Flash element on the page. This is a very generic method that we will be using for any Flash content, but as an example, for carousel that skeleton is:

<div class="flash-object" id="landing-proposition-inner">
<h2>Websites powered by Defacto include...</h2>
<ul>
 <li><a href="page1.html">
<img alt="Organisation website screenshot" src="shot1.gif" />Organisation Name</a>
</li>
<!-- more items -->
</ul>
<object>
	<param value="/defacto/live/swf/carousel.swf" name="swfLocation" />
	<param value="200" name="height" />
	<param value="#0E3E80" name="bgColour" />
	<param value="url" name="sendMode" />
	<param value="9" name="reqMajorVer" />
	<param value="0" name="reqMinorVer" />
	<param value="28" name="reqRevision" />
</object>
</div>

What the scripts do

A JavaScript script is used to embed the actual Flash into the page, in broad strokes, the page loads and the script then:

1. Runs, if you have a fairly recent browser (we used jQuery, so it matches Yahoo!’s graded browser support table fairly closely).
2. Checks the version of Flash that you have, and either:
   • Replaces the content of the container div with the Flash, or
   • Adds a small “Would you like to upgrade your Flash” link.
3. If the Flash is added, the current URL and container ID is passed to the Flash.

The Flash then loads, then displays the carousel using the images and links from the URL and ID it was sent. When a case study is selected, the Flash calls a JavaScript function to replace the content of the page (using AJAX).

Reasoning

If I were you, there would be several questions going through my mind:

Question: Why use AJAX?
It prevents you having to re-load the Flash each time you view a case study. Even cached, it’s doesn’t load instantly, and this way you don’t have to sit through the initial animation again and again

Question: Flash has to load the page itself to get the content, why not pass the content from the JavaScript to Flash?
We tried that, but it seemed very CPU intensive, and given that the nature of the widget is already CPU intensive, we steered away from that. Although it may mean loading the thumbnails twice, they should be cached for the second load. In our initial testing, the caching/loading differed between browsers:

• Firefox loaded the page fully before the Flash, which is strange, so Flash gets the cached images.
• IE seems to load the Flash and page simultaneously, so the first request for the images is usually from Flash.

Technically as the images are removed from the page when the DOM is ready, they shouldn’t all load, but I can’t confirm this yet.

Question: Why not do the Flash version detection in the Flash?
In the case of Flash not being installed, you either get a warning from the browser, or a broken plugin display. There is also a problem with signposting users what to do next, as you end up with dodgy inaccessible buttons or messages in Flash. Since the AJAX interaction requires JavaScript anyway, we decided to use JavaScript detection to deliver a much smoother user experience.

Progressive layering / enhancement

The easiest way to describe the layering is to describe the progressive enhancement, i.e. what you get with what capabilities the browser has:

Basic browser (no CSS or JavaScript)

An HTML list (ul) of standard links that work and image thumbnails.

Standard browser without JavaScript support

An HTML list of links that work. (Images are hidden with CSS, as they are too big when you have the layout in place.)

Standard browser with JavaScript, but without the required version of Flash

An HTML list of links, and a little link at the bottom of the area suggesting you update Flash.

Standard browser with JavaScript and required Flash version

The Flash carousel version, using AJAX to load the content.

In the first version the “has JavaScript but not Flash” condition used AJAX to load the content, which seemed like a more even step. However, the accessibility and browser support issues mean that the weak point is really scripting (AJAX), not Flash.

Benefits

There are several advantages to this whole method that appealed to us:

• The method scales up. The first time we tested this was for a micro-site that replaced the whole site with Flash.
• Search Engine Optimisation (SEO). Since your content is well structured XHTML, Google doesn’t even know you’re using Flash.
• The presentation in Flash can be very different from HTML, even with the same source content. (Caveat: the more Flash elements you layer on top of the source content, the less flexible the content becomes.)
• Flash can call JavaScript functions to interact with other parts of the page, so you can still use (X)HTML when it is best suited to the content.
• You can have multiple Flash instances on the same page, each with it’s own variables.
• It is easy to turn on/off, bulletproofing the accessibility.
• No duplication of content, you don’t have to update two things.
• You can edit the content within any XHTML capable CMS.

I’ll repeat that for those at the back: You can edit the content in a CMS, not one coded specifically for editing Flash or custom XML files.

Obviously, you can’t add or change functionality, but in this case you can add case studies (links and their thumbnails), and in other cases you could change the content of pages (i.e. text and images).

Accessibility issues

We are tripping several alarm bells in terms of accessibility by using Flash and AJAX, but actually it wasn’t that hard.

The pages work fine without JavaScipt. The AJAX loads on a keypress of enter, so screen readers will generally update the virtual buffer. There could be a problem if the content takes a little while to load, but adding Juicy studio’s update buffer function should resolve that.

For the the Flash you just have to put in the work (and knowledge and testing) to ensure that it works with both visual keyboard access and with screen readers. You also have to work out what should be shown to screen readers in what order for it to make sense. We did find a bizarre bug in JAWs (8.0 original version) where the whole pages content was repeated when it entered the Flash, but applying the later patches to JAWs fixed that.

User control

One of the basic assumptions we accepted is that people may not be able to, or want to, use this feature. Therefore we added a “Disable scripts” option at the top. This essentially turns off the advanced scripted features such as the flash, but leaves the cosmetic ones in place (e.g. adding rounded corners).

This is very useful for older screen readers, which may understand just enough JavaScript to get into trouble. At the moment, it’s also useful for Safari, as we’ve encountered quite a severe bug when it encounters the AJAX function.

Usability additions

Usurping the innate page model of the web comes at a cost, some of which we’ve worked around. If you just use the Flash, it’s fine, but if you switch between navigation methods it’s a little clunky as the Flash is not reloaded.

The aspects we did work around were primarily changing the page title when you load a new case study, and providing a mechanism to get back to the index page (in the breadcrumbs).

We also made the visual aspect somewhat more HTML-like, so that a case study has underlined text “View case study”, then when you select it that disappears. Adding this made the keyboard/screen reader aspects easier to deal with as well.

Improvements still to make

There are a few things we would still like to adjust, the first of which has to be the Safari bug we’ve tripped. It actually crashes Safari! Unless we can track it down, we might have to add an “if browser is Safari then don’t run” type rule. JavaScript debugging in Safari isn’t that easy, and yes messieurs Christian & PPK, you can say “I told you so”. However, it would have taken an awful lot longer than we had (1.5 days on JS) to complete it without a library.

Although we’ve restored the titles to individual (AJAX) pages, we haven’t re-enabled bookmarking of individual pages. Although search engines will have no trouble finding the pages, people will have difficulty bookmarking individual case studies.

I’m also not convinced that the double click aspect (i.e. one to move the case study to the center, a second to select it) is the way to go. Some people expect the first click to select a new page, some don’t.

Which did you expect?

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.

I’ve written about the four types of PDFs you get on the internet in general, and from experience with training people, I thought I had a pretty good idea of how many accessible PDFs would be available. However, Sitemorse have been running automated tests, and say that 74.8% of checked PDF’s failed accessibility from the FTSE 100.

75%? [Insert rude word here.] Maybe three quarters of of the PDFs were tagged, but I’m very skeptical that any examination of those 25% of PDFs would show a real attempt at creating accessible PDFs (i.e. with alternative texts and good structure).

The report from Sitemorse was in PDF format, and included this little promotion:

SiteMorse now includes support for examining Adobe PDF files. We perform twenty eight (28) checks on PDF documents to ensure users do not experience problems such as broken links, or failing email addresses – we are also the first to test the accessibility compliance of PDF’s.

(My emphasis.)

Now, I rarely check these things without being asked to, but I couldn’t resist. How does this PDF stack up? Because PDF is a mostly binary format, you need a tool to check ‘under the hood’, but with Acrobat Pro it’s quite easy to run a quick check. The results were actually worse than I expected:

The report showed:

• It’s not tagged, the most basic form of applying accessibility to PDFs.
• The security settings actively prevent accessibility.
• No images have alternative texts.
• The language is not set.

Now I would be the first to admit that accessifying PDFs can be real pain, and to do so you currently have to pay an Adobe tax, because no one else will create the tools (even though it’s a published format and anyone can).

However, I don’t understand why you would actively prevent accessibility?

The other main point is understanding what a 75% fail rate means. I’m guessing that the Sitemorse tool checks whether a PDF is tagged, and possibly whether images have alternative text. I’d be quite surprised if there were any other accessibility oriented checks, so it actually means 25% might be accessible.

Still, without knowing exactly what a tool checks, you can never know what the numbers mean.

Update – 22nd July ’07

The last Sitemorse newsletter I recieved did not include a PDF (too hard to do perhaps?), and now the notes on PDF include:

SiteMorse identifies PDF files which do not include these tags.

This pretty much confirms the observations on pass/fail rates above, if there were other checks I’m sure they would be boasted about.

Translations

• Saatavana myös suomeksi

Portable Document Format (PDF) accessibllity is not a new topic, it is well understood and explained by certain experts.

However, the implications are universally unknown by organisations.

Perhaps by outlining the four broad levels of technical PDF accessibility, and what most organisations do, someone will take note?

Levels of accessibility

Broadly speaking, any PDF will fall into one of the following categories depending on how it was created:

1. Created from unsupported graphical tool. (Not accessible)
2. Created from unsupported text based tool. (Probably not accessible)
3. Tags automatically added. (Might be accessible)
4. Tags added and carefully edited. (Accessible)

Created from unsupported graphical tool

A typical scenario is creating a poster or leaflet that is made with a desktop publishing tool such as Quark. This does not embed text in any useful way when a PDF is created, so it will be invisible to screen readers, and the other accessibility features available when reading will not work.

These files cannot be considered accessible in any way.

Create from unsupported text based tool.

When you use Acrobat Pro (version 5 or greater, preferably 7 or greater) with a supported application (e.g. MS Word), you can add ‘tags’ to PDF documents, providing a structure to the document that is used by screen readers and other access (and mobile) technologies.

If you aren’t using a supported application with Acrobat Pro, then you will be creating a PDF without the HTML-like tags. This is where there is some grey area.

If the document is simple, then it is likely that many people using access technologies will still be able to access it if they have the latest software. However, there is no guarantee, and it is possible many people won’t be able to access it.

These also cannot be considered accessible, and the vast majority of PDFs online fall into this category.

Tags automatically added

Using a supported application such as Word, with Acrobat Pro, and adding tags, you have the basis for an accessible PDFs.

However, whether people with access technologies will be able to use it is another matter, and varies greatly depending on the source document. The type of things that can and usually do go wrong are:

• Images included in a document don’t have alternative texts.
• Word styles are not used, meaning Acrobat has little chance of working out what the structure should be (although it does try).
• Word’s formatting has become confused, separating content in strange ways that are not visible until you check the reading order.
• The document includes tables, which need marking up through the Acrobat interface.

If you run an accessibility check (part of Acrobat Pro) on any document that hasn’t been manually altered, you are likely to get problems, and an automatic check cannot identify some of the above problems.

A document that has tags has a chance of being accessible. For simple documents (no columns, tables or images) it is probably OK. For anything more than basic, it is likely to take manual intervention to be properly accessible.

Tags added and carefully edited

If you’ve used the right software, and edit the PDF in Acrobat Pro afterwards, you can:

• Check the the structure is right, and correct it.
• Check the reading order is right, and correct it.
• Specify the language (e.g. English).
• Add alt texts.
• Mark up tables properly.
• Remove non-text artifacts.

And generally clean it up. At this point, you can be satisfied that the document is accessible.

In my experience, if you have a 40 page Word document which has been perfectly marked up with Word styles, includes 1 large table, and 10 images: Allow about 3 hours for this process. If the source isn’t Word, or it isn’t using styles for headings, double that time.

And if you or someone else edits the word document? You have to re-do it, PDF is an end format.

Implications for organisations

Many organisations put a lot of PDFs online, and certain content may only be available through that document. This is an accessibility issue, quite a big (legal/moral/technical) one.

What to do?

There are several factors to balance, the main ones are:

• The difficulty that people can have with PDF documents, especially those with access issues.
• How appropriate it is to put up long documents as web pages.

The bottom line in terms of accessibility is that some people cannot access PDF documents easily. However, that does not mean adding a very long HTML page (or set of pages) is most appropriate.

Where a document is very long and not suitable for online reading, a PDF would seem to be the most obvious format to use.

Working on the assumption that a typical scenario is for a PDF to be added to a news story, council meeting, AGM notice or similar, the steps to ensure accessibility & interoperability are:

1. Include a summary on the HTML page (which itself is good for online reading).
2. Make the PDF itself accessible (i.e. use one of the approved source applications such as Word and create a ‘tagged’ PDF document).
3. Include the ability for people to request another format such as Word or Rich Text Format (RTF).

If the above advice is followed, an organisation is making a reasonable effort to ensure that everyone can access their content. PDFs are not inherently inaccessible, however, they have only become accessible in recent versions, and are not currently easily accessible.

In time (as people catch up with more up to date software), step C may not be necessary.

Taking a step back, this should obviously affect policy. It would be unrealistic to expect organisations to convert thousands of historical documents to accessible PDFs. However, as in the above recommendations, giving people the ability to request a different format would make it available in practice without creating undue work.

It is still difficult for organisations to change processes to start using accessible PDFs from this point on. It requires significant authoring changes to how people produce content such as enforcing the use of Word styles, and adding alternative texts for image. Then the knowledge to create accessible PDFs can be used.

Tags:

• PDF
• Acrobat
• Accessibility