Both courses will run on Thursday 18th September, one in the morning and one in the afternoon. Venue RNIB head office, London. Anyone who books both courses will qualify for £25.00 reduction on the total cost, and get a free lunch. .

So much happened during the day it’s difficult to know where to start but thanks to AbilityNet you can catch up yourselves on events by via the podcasts and transcripts.

Keep an eye out for Scripting Enabled, a conference to be held September 19th and 20th, that aims to break down the barriers between disabled users and the social web.

See you there I hope!

In this special report we asked disabled users to try out the Beijing Olympics website in our interaction lab. Poor information architecture and a lack of adherence to web standards result in an uneven playing field for disabled sports fans across the world…In a departure from our standard State of the eNation review procedure we brought a range of disabled users into our lab to perform some basic tasks on the website. Users uncovered a variety of accessibility and usability issues that only real-life user testing would have uncovered.

The report contains some fascinating user videos which give real insight to the barriers people face both in terms of guidelines as well as poor usability for people with disabilities - not to be missed. These all also come with either captioning or transcripts.

For further comment on the Olympics site see also E-Access Bulletin’s Web Accessibility - Beijing Olympics: Revisiting The Errors Of The Past as well as our post on the accessibility of the Beijing Olympics website

Quick disclaimer: my background is not in localisation and internationalisation but accessibility. My interest in the two comes from where I see issues that affect people with disabilities also affect international users. As with the accessibility review this is just a snap shot of a few observations and I’d love to hear more about your thoughts on the site so please go ahead and post comments.

Before we start lets have a quick look at what is meant by internationalisation (also known as i18n) and localisation (also known as l10n).

The W3C definition of internationalisation is:

“…the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language”.

And the W3C definition of localisation is:

“…adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a “locale”)”.

This can be pretty confusing at first glance. The definition seems to apply two different things: going global versus going local. But if you’re a website owner based in the UK who wants to expand into foreign markets then you have to take the step towards going global before you can make an entrance locally. In simple terms, for the purpose of this article, what these two definitions mean is that a web site template needs to be internationalised (i.e. the back end and architecture etc) in order to support content to be localised, (text, colours, images, icons and so on).

Moving away from websites for a minute another way of looking at it is an analogy of a car. If the car is internationalised then the body of the car is built in such a way that a steering wheel can be easily fitted on either the left or the right. If the car has not been internationalised however then it wont be able to be customised to fit a steering wheel on either side so the body of the car has to be built from scratch. Once the body of the car is right then you can focus on colours and fittings. And this is a key thing to think about with both internationalisation and accessibility in a website. If both are incorporated from the start you’ll have no costly and difficult retrofits down the line.

So how does Beijing 2008 fare? In no particular order, here is a summary of a handful of issues I focused on:

Presentation versus Content

Key to both an accessible site and an internationalised site is separating presentation from content i.e. using structural mark up to indicate headings, lists and data tables and CSS for layout and formatting fonts and styles etc. Returning to the difference between internationalisation and localisation flagged at the start of this article this basically means ensuring that your web content is constructed so that it can be painted and decorated in a way that suits its target audience.

Let’s look at an example of why semantics are so important. Chinese uses italics as a form of emphasis when printed but this doesn’t tend to look that great on web pages, so using “i” tags around ideographic text is not an ideal solution. Emphasis i.e. “em” however can be used so that a dot appears over the character being emphasised or a shaded box appears as it’s background.

Looking at the Beijing 2008 site structural markup has been used for content and CSS for layout which is good. This allows for much easier localisation of each language component and flexibility to style text in a way that works for any given language. There is a slight problem with the heading structure coded in the site though, as headings are not always coded as they should be, as noted in the headings section of Beijing 2008: part one accessibility. This is a problem because if the semantics are not right the content becomes less useful or usable both in terms of access for technologies such as screen readers, (an access technology that reads aloud content to visually impaired users), and how the site is translated.

Language coding

When working on sites that have multiple languages it is important to indicate what the main language of a page is, and any language changes within the content . This is necessary for a number of reasons:

• Screen readers will be able to identify language changes.
• Browsers will be able to display text properly and display text according to language-specific hyphenation and spacing rules.
• Search engines are better able to index your pages. Google, for example, allows you to search by language.

The Beijing 2008 site is available in Chinese, English, French, Spanish and Arabic with some pages having some parts of the page written in a language other than the main language of the page. For example in the French site there may be words presented in English. This is not a problem providing the page has been coded so that the main language is indicated and any changes in language on that page have also been identified.

The main language of the page should always be coded in the HTML tag in the head of the document. After that, any changes in the language on the page should also be marked up using the LANG attribute. So for example, if you have an English site that includes the French text Au Revoir!on a page the LANG attribute for French must be used to indicate a change i.e. LANG=”Fr”.

In the Beijing 2008 site the native language of the language versions is correctly coded for the Chinese (xml:lang=”zh-CN” lang=”zh-CN”), English (xml:lang=”en”, lang=”en”) and French (xml:lang=”fr-FR”, lang=”fr-FR”) pages but changes in language within page content is not. So for example the top right hand links on the English page to 中文 and Français are not coded using lang=”cn” and lang=”fr” respectively. This would be made possible if the image links were given appropriate lang attributes and alternative text, or were replaced with text links with the language change identified .

Links to alternative language versions

When people navigate to a site that is not in their native language one of the first things they will do is look for a link that takes them to a version of the site that is in their native language. As a website owner one of the key things you need to do therefore is make links to alternative language versions as clear and easy to find as possible. There are a number of ways that websites link to alternative language versions including drop down menus, images of linked flags and text links of the languages. Ideally however the best way to do this is to provide a link to the language version in the language of the target page. The Beijing 2008 site does just that at the top right of the page with images of text for English, 中文” and Français.

So why is this technique the preferred one? Let’s look at the example of a drop down menu with the text “Select language” first.

If you are a non English speaker landing on this site it’s unlikely that you will read and understand the text label “Please select your language” (not to mention the fact that the colour contrast is pretty poor) and then look inside the drop down.

The second option of using linked flags creates problems for speakers of the same language from different countries. Do you click on the Spanish flag if you’re from South America, the French flag if you are from Quebec in Canada? This is where localisation comes into play. You need to be sensitive to people’s origins and not bundle groups of people together who consider themselves very different. It’s not unusual to get a US and UK version of the same site after all.

One thing that did initially catch me out however was the lack of prominence of the language links and presenting them as images of text. The Olympics website is the ultimate in terms of a global website and I expected there to be a clear, obvious place where I could browse language options. Using images for text is never really advisable as they can not be scaled up and enlarged for those of us who need larger font sizes, nor can the colour be changed, if the contrast or colour combination is difficult to read..

Images and animations

How accepting of a website people are, often comes down to how it looks visually, it’s use of images and animations. People from different cultures can have a very different perception of what good design is, and what they gravitate towards. In China for example people appreciate animated images more than people in Europe. Generally the Chinese are also less concerned with lengthy pages to scroll down and compact information whereas in the West we fear the fold and don’t want key links and text to be lost in the crowd.

When looking at the Beijing 2008 home page alone you are immediately presented with an animated image that takes up almost all of the top third of the screen and rotates constantly. There is also scrolling images further down as well as an animated image and the page requires you to do quite a bit of scrolling. If part of localisation is about designing to specific region or culture then in my opinion Beijing 2008 doesn’t quite hit the mark. After three years working on the web in Shanghai China I’m pretty familiar with Chinese web design and the site definitely “feels” Chinese in origin. A Chinese look and feel is wholly appropriate as it is the Beijing Olympics but it could be done in a way that makes it also appealing to a Westerner’s eye. To illustrate what I mean look at the differences between the Yahoo! China website and the Yahoo! UK website. These sites both have the look and feel of Yahoo! but there are fundamental differences between both. The Chinese version contains more images and animated images, involves more scrolling and contains more information than the UK one.

The URL

When working on international sites with different language versions clear URL’s are important so that users can figure out where they are. The URL, http://en.beijing2008.cn/ , is not that intuitive for a user as it is neither easy to remember, tidy and logical. Obviously URL’s are designed to be machine readable and read by browsers however don’t underestimate the importance of unambiguous human readable URLs. When I look at this URL I see the “en” at the front which indicates to me that the site is in English but the fact that it ends in “cn” makes me wonder if it may be in Chinese. I’d prefer to see something like www.beijing2008.com/chinese or www.beijing2008.com/cn for the Chinese site followed by clear sub-domains. Del.icio.us and Flickr have unambiguous clear URLs. Looking at my page on del.icio.us you’ll see that it is constructed by the site domain followed by my online name http://del.icio.us/iheni. If searching for links on del.icio.us that I’ve posted about internationalisation then the logical construct is going to be http://del.icio.us/iheni/internationalization. A URL that is easy to work out, reinforces the name and brand as well as does wonders when making a site more memorable and usable when presenting content in multiple languages.

Recently ICAAN announced that it was testing the possibility of internationalised domains in eleven non-Romanized languages (i.e. translating .com) . It’s not clear at the time of writing as to when these would become established on the web, but it’s an interesting consideration for the Beijing 2008 site as well as the London 2012 site for that matter.

Conclusions

These really are just top level thoughts and there is much more that could be covered by someone far more qualified than I when commenting on the internationalisation and localisation of the site. That aside I think what is clear from looking at the Beijing Olympic site from the perspective of a user with disabilities, a mobile phone user or someone from a different linguistic or cultural background is that the site still has a long way to go before it can cater to the highest number of diverse audiences.

It makes me wonder if there are a standard set of practices that an Olympic website must follow which includes the Web Content Accessibility Guidelines, Internationalisation Best Practices and Mobile Web Best Practices that is handed down from the Olympic committee when each Olympic site is started. This would help build up a body of design knowledge for each new site therefore cutting down the work needed to be done in each new build.

London will be the host of the next Olympics in 2012 and there are clearly lessons to be learnt not least incorporating accessibility, internationalisation and mobile web best practices from the outset rather that slotting them in at vast cost after the site has been built. We’ve already seen the Sydney Olympic site fail in the courts due to accessibility, perhaps London 2012 can turn that around and be an exemplar of an accessible, internationalised site that renders well for mobile users.

Further reading and references

• W3C Internationalisation: all you need to know about building internationalised websites.
• Molly E. Holzschlag’s Putting the World into World Wide Web
• Find out more about declaring languages from the W3C
• W3C I18N Techniques: XHTML & HTML Authoring
• Planet Internationalisation: an aggregator for posts on internationalisation
• Mobile Web Best Practices: from the W3C
• Web content accessibility and mobile web accessibility: cross overs between WCAG and MWBP

Got a resource? Leave a comment and let me know.

Principal Manager: Digital Accessibility - Ref 4913

Salary: £39,032 - £49,407 including London Weighting. Future potential up to £56,979 inc LW - pay award pending
Band: 3 (starting salary spinal points 44-56)
Group: Access and Innovation
Section: Accessibility
Planning unit: Digital Accessibility
Location: 105 Judd Street, London WC1H 9NE
Hours: 36 per week

Are you passionate about using and improving technology to benefit people with sight loss? As the leader of our growing Digital Accessibility team, you’ll be responsible for developing and implementing strategies that will influence commercial companies and policy makers to improve the accessibility of a wide range of new products and services.

With your help, technology can make it easier for blind and partially sighted people to learn at school, watch TV, communicate with friends, work, shop and have fun.

You’ll be knowledgeable about a broad range of ICT, with experience working in a relevant industry. Good communication skills along with the ability to build a network of strategic contacts and partnerships are essential.

Apply

Closing date for applications 18 August 2008, interviews will be held 5 September 2008

• Information Pack (Word)
• Application Form (Word)

Senior Web Accessibility Consultant - Ref 4924

Salary: £26,835 - £35,852 (plus London Weighting if applicable)
Band: 4
Group: Access and Innovation
Section: Innovation & Disability Access Services
Planning unit: Consultancy
Location: Flexible
Hours: 36 per week

RNIB’s Web Access Centre is part of RNIB Access Consultancy Services, the UK’s leading provider of accessibility solutions.

You’ll have experience of working in a web-related environment and a familiarity with, and understanding of, the Web Content Accessibility guidelines (WCAG1/WCAG2) published by the Web Accessibility Initiative (WAI).

You’ll also have in-depth knowledge of HTML and CSS and will be comfortable discussing finer coding issues with website developers as well as being an experienced accessibility specialist with expertise in providing accessibility consultancy services to blue chip organisations.

Apply

Closing date for applications 14 August 2008, interviews w/c 1 September 2008.

• Information Pack (Word)
• Application Form (Word)

Administrator (Web Access Consultancy)- Ref 4923

Salary: £19,716 - £23,279 inc LW. Future potential to £26,025
Band: 6 (starting salary spinal points 18-24)
Group: Access and Innovation
Section: Innovation & Disability Access Services
Planning unit: Consultancy
Location: 105 Judd Street, London WC1H 9NE
Hours: 36 per week

RNIB Web Access Centre, part of RNIB Access Consultancy Services, the UK’s leading provider of accessibility solutions.

You’ll review, create and maintain complex administrative systems to help support consultants and assist with the production of monthly reports. You’ll have experience of managing clients and the ability to answer calls to provide information and assistance in response to general enquiries.

You’ll have experience of Microsoft Office, to include Word and Excel and Outlook to manage diaries, allocate tasks as well as meeting requests and being able to plan and schedule busy workloads for a team of Web Access Consultants.

Apply

Closing date for applications 14 August 2008, interviews w/c 1 September 2008.

• Information Pack (Word)
• Application Form (Word)

Organised by Chris Heilmann from Yahoo! the event is set to be a first and not to be missed. Here’s a break down of what the two days will cover:

On 19th and 20th of September we’ll spend two days kicking off an ongoing research and solutions exercise to remove online accessibility barriers. The event is split into two days with different venues:

On Friday, the 19th of September we’ll meet in the Henry Thomas hall of Metropolitan University in Holloway Road, London to learn from speakers what kind of barriers there are in online offers. Instead of development experts telling us what they think the barriers are this will have speakers that deal with them day by day and cover a range of problems, not just visual impairment.

This event has 150 tickets all in all and will be a discussion/presentation day.

On Saturday, the 20th of September 50 hackers then meet at Gamelab in Shoreditch take the learnings from day one and turn them into alternative interfaces for sites that unnecessarily block out users. We’ll also create blue-print solutions for common problems that will be released open source and documented under Creative Commons.

This event is a hack day and we got space for 50 dedicated hackers.

This looks like a really exciting event so be sure to book your free ticket(s) and see you there.

So, with all that in mind, let’s talk about food instead!

Guidelines – The Recipes for a Better Web?

Recently in the office, a colleague offered me a taste of her lunch. It was the national dish of Jamaica, Ackee and Saltfish, which is a combination of a fruit called Ackee and salted cod served with rice – very nice it was too! I got her to email me the recipe so I could try my hand at cooking the dish sometime in the future.

OK, so how am I going to relate this to guidelines and user testing I hear you ask? Let’s imagine what it might be like if I hadn’t got the recipe for the dish or we didn’t have the WCAG guidelines. All we would know is that we have a goal we are trying to achieve, i.e. cooking a dish or building an accessible website. Depending on our level of expertise, we may or may not know how to go about achieving these goals.

Now, I’ve never cooked the national dish of Jamaica before in my life! In theory, the recipe should give me a fighting chance of getting it right, but that’s all it gives me. The recipe won’t guarantee I’ll get things right, but I’ll certainly have a better chance than without it. Recipes are not normally a completely foolproof set of instructions. There is a certain degree of knowledge that is taken as given when following a recipe. For example, the recipe doesn’t tell me to take the rice out of the packet before putting it in a pan – it assumes that I know at least that much!

The same goes for guidelines. They exist purely to “guide” you to creating more accessible web content. They come with no guarantees, but they can go a long way to helping people understand what some of the problems are, and the best practice solutions to those problems, which is better than nothing. There is a certain degree of knowledge that is required in order to apply them properly. This is where expert review and independent verification can be beneficial, both in terms of reassuring people about the accessibility of your site but also as a learning experience for how to apply the guidelines in the real world.

So recipes and guidelines can help you out when you don’t know how to go about doing something. If we were to abandon guidelines now, it would be like cooking something you only know the name of. The chances are, you’ll get it totally wrong and it won’t taste very nice! Similarly, if your goal is to create an accessible website, without the guidelines you may have no clue where to begin and your efforts might be very wide of the mark. With the guidelines at your disposal, you at least have a fighting chance of getting things right.

User Testing – Tasting the Results?

The age old saying goes that “the proof of the pudding is in the eating” and it certainly is! I’m very much one of the proponents that what we do with the web should be focussed around people and not technology.

What exactly do I mean by that then? Well, most of us probably spend our days building sites for our customers. The majority of the users coming to your sites won’t particularly care about the technology you’ve used to build it, they just want you to make their lives as easy as possible when using your site. As long as we are fulfilling this goal, the technology, standards and guidelines we’ve used along the way become less important. They are merely the tools we can use to achieve the end goal of satisfied customers and users.

Saying that, I’m still a strong believer in the fact that it’s important to write clean, valid code where possible and follow guidelines where appropriate, but to become too focused on this and lose sight of the overall goal of the “user experience” would be a mistake. Similarly, to ignore standards and guidelines and rely on user testing alone would be a step backwards from where we are now in my opinion. Guidelines and user testing go hand in hand, just like a recipe and tasting the finished dish go hand in hand. The important thing is to find a healthy balance between the two so they complement each other.

Guidelines are better for ensuring a site is technically accessible. Following them can help to iron out problems which may otherwise surface during user testing and nip them in the bud so to speak. This should result in fewer accessibility issues being found at the user testing stage. Following guidelines can also often naturally lead to improving the usability of a site.

User testing is useful for genuinely making sure that a site is usable in everyday use as well as being technically accessible against a set of guidelines which is an important concept. User testing is valuable in helping make sure that users can understand and find the content and features on your site. The results you get from user testing are often easy to read for non-technical people, as they offer an “account” of various peoples’ experience of using your site.

User Testing - Does This Taste Right To You?

There is one very important point to remember with user testing. The testers are rarely experts in web accessibility, and will normally only test the route to a limited number of resources to ensure that they are usable from their own perspective. It’s important to be certain that solutions applied to resolve issues highlighted by one user, don’t create problems for other users with different needs.

To ensure good accessibility for all, it’s important to have an expert to review and interpret the feedback received from users, in the same way as with guidelines. An expert can translate feedback from users into suggested solutions for developers that will ensure pan-disability access to the site (as the WCAG guidelines do).

Let’s relate the need to have an expert review the feedback from user testing to tasting a dish when it’s cooked. When I have my first attempt at cooking Ackee and Saltfish, I could taste it and think I’ve done a good job because I’m not experienced at cooking Jamaican food. More than likely, my colleague might taste my first attempt and tell me she could do a much better job, and I’m sure she would be right! It’s vitally important that the feedback from users is interpreted correctly and transformed into workable solutions by a professional.

Conclusion

To sum up, I think I can say that both following guidelines and testing with end users are beneficial practices and certainly both are a good idea to do if you have the resources.

Following guidelines can help to reduce the number of potential problems that might be uncovered by users and testing with users can help to uncover problems that might not be covered in the guidelines, so they complement each other well.

Guidelines and user testing don’t provide a “magic fix” for ensuring an accessible and usable website on their own. When used together, they still don’t provide a “magic fix” but they come a lot closer. What do you think? Comments are open!

Further Reading

• WCAG 2.0 Guidelines
• WCAG 1.0 Guidelines
• RNIB Web Accessibility Audits
• RNIB / AbilityNet User Testing Services
• AbilityNet Disabled User Testing Services
• Just Ask: Integrating Accessibility Throughout Design (Online book by Shawn Lawton Henry)
• Article by Joe Dolson - Using standards doesn’t make it right
• Article by Joe Dolson - Care about standards? No, not exactly…
• Article by Molly E. Holzschlag - Web Standards Aren’t
• Article by Molly E. Holzschlag - From Web Standards Diva to Web Standards Devo

The Opera Web Standards Curriculum is an education program to help propagate best practices and increase web standards usage on the web. It provides a thorough grounding in all the skills you need to be a proficient front end developer, including web background theory, in-depth HTML and CSS, design principles and introductory DOM/JavaScript.

This is a fantastic resource aimed at web developers, designers, students, educators; just anyone who wants to learn web design the right way. Whether you’re starting out or simply want to refresh your understanding this is the place to go. Written by experts such as Mark Norman Francis, Jonathan Lane, Linda Goin, Paul Haine, Roger Johansson, Ben Buchanan, Jenifer Hanen, Craig Grannell and Christian Heilmann you can hardly go wrong.

Presented as if you are working on a project from start to finish, the Web Standards Curriculum is broken down into a series of articles taking you from information architecture and wire-framing through to design and build of pages using (X)HTML, CSS and so on. It kicks off with some necessary scene setting describing the origins of the Internet and the Web which in turn provides the backdrop for the rationale of why we need web standards. What’s so great is that while you can opt to read the Curriculum from start to finish you can also just dip into it as it works just as well as modules.

I particularly liked the articles about colour theory, colour schemes and design mock-ups. While I may understand colour from an accessibility point of view this opened up my understanding of how uses of colour can be manipulated to enhance typography, forms, lists, tables and images, all of which are covered in more depth in other articles.

All this lovely goodness doesn’t stop there however. In total there will be fifty plus articles with future additions planned to cover accessibility, CSS and JavaScript. The Web Standards Curriculum will also be maintained to ensure that you get the most up to date information. The best bit however is that it’s for you to use not just as a resource for yourself, but also when teaching others either in schools and colleges or at work.

Opera’s Web Standards Curriculum is also supported by the Web Standards Project (WaSP) who are themselves developing The Curriculum Project. This will be a resource that is intended to be used by those in education, as well as anyone needing to update knowledge on web related technologies.

As Glenda Sims, Senior Systems Analyst University of Texas, and co-lead of WaSP says of Opera’s Web Standards Curriculum says:

Web development and design are ever evolving professions. Anyone teaching these subjects must ask themselves if they are equipping their students with best practices or burdening them with impractical methodologies. All of us in this field can benefit from this resource and use it as a catalyst to further the W3C vision of ‘Web for Everyone. Web on Everything.

Enjoy, share, teach and be part of the movement to build a better web!

Further resources

• Dev.Opera - Dev Opera is a community resource site where developers can share tips, tricks, extensions and more.
• Web Standards Project (WaSP) - a grassroots coalition fighting for standards which ensure simple, affordable access to web technologies for all.
• Business Case for Web Standards wiki - a resource that logs case studies and information supporting the business case for web standards.
• A List Apart - A List Apart Magazine explores the design, development and meaning of web content, with a special focus on web standards and best practices.
• WebAim - Web Accessibility In Mind.

First a quick explanation. Heading mark up, H1 to H6, is wrapped around headings in a page to give the page structure. When headings are coded correctly voice input users, screen reader, refreshable braille display and some browser (Opera) users benefit by being able to use voice and keyboard commands to navigate between headings. This makes pages more scanable and less restrictive for users as they don’t have to navigate content linearly, which can be very time consuming. Some search engines also use headings to index pages.

So without further ado here are our top tips:

1. All visual headings in web pages must have a heading structure applied using H1 to H6.
2. Headings must be used to describe a page’s structure and not used for visual effects.
3. Pages should only have one main heading, H1, which is the main title of the page and should be positioned at the start of unique page content.
4. Headings are like a contents overview of a page. Sub headings of the H1 must be coded as H2 and subheadings of an H2 must be coded as H3.
5. Heading levels can’t be skipped i.e. you can’t jump from H1 to H3.
6. Headings should not be coded around content that is by itself, they should always be followed by associated content.
7. Headings should not be coded around form labels i.e. the text label “Search” that comes before an input field.
8. Heading structure should be consistent throughout the site.
9. Add in headings to break up large chunks of text.
10. Keep headings short and succinct and therefore easy to scan and understand.

You can test all the above by looking at the heading structure on this page. If you have the Web Accessibility Toolbar installed select Structure then Headings or Heading structure. Alternatively you can go to View, then Source and do a search for H1, H2 and so on.

For a really clear demo of how screen readers intereact with headings and allow users to navigate check out this video on the Importance of HTML headings for accessibility (8 mins and 41 seconds)

Got a tip you want to share? Then leave us a comment.

1. Content authors

There’s really no excuse to not create accessible PDF as Adobe have built in tools to support the creation of accessible content and given us guidance on how to make the most of those tools (see the resources at the end of this post). There are other hindrances (as listed below) and arguably the overall responsibility may lie with the organisation you work for but this doesn’t mean that we have a devolved responsibility for the work we produce. If you are part of the chain that produces PDF in your organisation then you have a responsibility to do what you can to make the PDF accessible. Some ways of doing this include:

• Follow Adobe’s accessible PDF guidelines (a link to which is in the resources below).
• Ensure third party content providers are made aware that they must create accessible content and write this into their contract.
• Ensure you organisation supports you in your efforts (read on to point 2).

2. Organisational support

First there is the issue of having the skills to make accessible PDFs but often, before you even get that far, it’s all too common to find that the systems and processes within an organisation are simply not in place to support people creating accessible PDF. People may not know they a) have to do it, b) how to do it, c) have the appropriate training and support to do it and d) have time built into their workflow.

It’s no good saying to content authors "Now go forth and make accessible PDFs" and leave it at that. Systems and processes need to be put in place to ensure that what is required can be achieved. This can be done by:

• Training content authors; investing in them is ultimately an investment in your site. Ensure they have access to up to date resources and support. Join forums, attend workshops and most importantly pool knowledge.
• Document what needs to be done to create an accessible PDF. Create checklists and guidelines in-house if necessary.
• Ensure people are clear of what is expected of them: write an Accessible PDF Policy (see number 3)
• Monitor content and prevent anything being uploaded to the site that has not been quality assured.
• Have creating accessible PDFs written into objectives, sounds harsh but it works, it gives people a motivation to do it.

3. PDF policy

We talk a lot about how a website should have an Accessibility Policy to help guide people who maintain the website when making decisions on what technologies to use, maintenance, testing, compliance and so on. A key part of an Accessibility Policy is a section on using PDF (not to mention other areas that are also overlooked such as software accessibility, e-document design and procurement policies). If there is no clear steer to PDF content authors as to what is expected of them then there is less of a chance that they will fulfil the requirement.

So what sort of information should go in an Accessible PDF Policy?

• Outline of what version of Adobe Acrobat should be used. The latest version is recommended but note that all versions before version 7 lack real accessibility support.
• Outline a level of compliance or goal. This could be based on WCAG 2.0 which is designed to be technology agnostic and therefore relevant to non-W3C technologies.
• Outline what must be done if a PDF can’t be made accessible, i.e. provide a Word or HTML alternative and consider removing the PDF altogether.
• Outline what type of content is permissible in PDF - it’s not appropriate to put some types on content in PDF (see point 4).
• Outline a testing plan: who checks the PDF before it is published
• Outline a requirements document for third party providers of PDF.

4. Content

People seem to use PDF as a fallback format for content that really shouldn’t be in PDF. There are types of content that arguably can be in PDFs and others that a PDF shouldn’t even come near.

Maps and forms are a particular bug bear of mine. Maps are totally inaccessible in PDF and impossible to make accessible unless you write a text description. That being the case why not instead have an HTML page that includes, for example, the address of the place and basic directions of how to get there by car, train, tube, bus and so on. You can then always link to the map as a back up/visual aid.

The second example, forms, should really be avoided unless it is a form that is intended to be printed and signed. Forms are hard to mark up accessibly in PDFs, extremely difficult to navigate, understand and fill in if you are a screen reader user. Ideally forms should always be presented in HTML. If it is a form that needs signing then have it generated in a PDF after the user has filled it in on the web page and hit "save" i.e. an HTML form that converts to PDF once completed and can then be printed and signed.

Ways of counteracting un-necessary PDF content:

• Ask yourself when creating new PDFs "Should this content really be in HTML or Word instead?"
• Avoid putting forms, complex images and key content in PDF.
• Only put content in a PDF is it is already there in the website. For example a downloadable PDF brochure makes sense in a brochure ware website.
• Don’t scan text and put it into a PDF. Use OCR software to translate it to readable text instead.

5. Third party content

This is an issue that affects accessible web development as well as PDFs. If commissioning content from a third party you need to be clear about what you want. This includes not just content but also how the content is structured and the requirement that it meets the accessibility standards of your organisation. Just because it is not content generated by you or your organisation it doesn’t mean you are not responsible for it; if it is published on your site then as far as the user is concerned it is your content.

Ways to ensure accessible PDFs from third parties include:

• Have accessibility written into the contact. Don’t just cite WCAG and a level of compliance but list those checkpoints you want the PDFs to meet and stipulate that the accessibility must be verified by third party consultants if need be (also a great clause to have in a web design contract).
• Share your Accessible PDF policy with the third party. It’s there to guide after all so make them as aware as possible of what you expect.

6. Source documents

PDFs are often generated from other source documents. The document source can have an enormous affect on what the accessibility will be like for the finished product. As the old adage says: rubbish in rubbish out. Make sure that you use a format that can support accessibility and can have structure added.

• Create tagged PDF from a structured word document (structured using Word Styles and heading levels).
• Ensure tables in the source Word document are created using the proper table grid formatting option and that no merged cells are used.
• Ensure images have concise Alt text assigned to them.
• Ensure all text is typed in directly from the keyboard and no text is contained within Text Boxes or images.

Things to not do are:

• Create PDF from Word documents using software that cannot produce tagged PDF (at time of writing this is most software other than Adobe’s)
• Create PDFs using Quark Xpress or other page layout software and without taking the PDF into Acrobat and tagging it manually.
• Create PDF from scanned images without taking the file into Acrobat and running OCR process and then tagging it manually.

7. Legacy PDF

All of the above is all well and good but what about all the PDFs out there today that don’t even give a nod to accessibility? There are literally billions of PDF on the web; some websites make heavy use of PDF to the extent where they represent a core format for the site (think about government websites for example).

It would be unreasonable, and impossible, to go back and retrofit every PDF on the web. So how do we deal with legacy PDF?

• Look at fixing key PDFs only by reviewing your web stats and seeing what the most popular PDFs are.
• Look at fixing PDFs that have been published in the last year, two years.
• Look at fixing PDFs that you know are important for people and key to your site for example annual reports.

Conclusion

So this is really a call to action. It’s time to stop shaking the proverbial fist at PDFs the technology and start taking matters in our own hands. Adobe have worked hard to get accessibility support built into Acrobat (and very soon there may be more resources to help us publish accessible PDF - watch this space), so it’s down to us to start implemening the processes to support the creation of accessible PDF.

Resources

• Defining PDF accessibility : recently updated resources from WebAim, and very good they are too.
• Accessing PDFs using Jaws, a screen readers guide: an practical guide on navigating PDF if you are a screen reader use from RNIB’s Hugh Huddy. It also outlines how to recognise when problems are to do with PDFs and not the screen reader.
• Creating accessible PDF using Adobe Acrobat 7.0 (10.2MB, PDF) : Adobe’s ‘how to’ guide on creating accessible PDF.
• Making and generating accessible PDF: from Bruce Lawson.
• Use of PDF in accessible documents: An outline from the WCAG Samurai Errata.
• Preparing Microsoft Word documents to create accessible PDFs (PDF, 1.23 MB): tips of creating accessible PDF using Word from Adobe.
• Accessing PDF Documents with Assistive Technology: A Screen Reader User’s Guide: a screen reader user guide from Adobe.

Other things that suck

• Standards suck!: Standards Suck hosts podcasts made by Anne van Kesteren, Marcos Caceres, and Lachlan Hunt about Web standards.
• Captioning sucks!: Looks at talking about just how lousy captioning really is and alerting people to the fact that there is a solution on the horizon – the Open & Closed Project.