You Reap What You Sow: The Australian Government’s Report on PDF Accessibility

Contents

• Executive Summary
• Introduction
• The Australian Government’s Report
  • What the Report Gets Right
  • What the Report Misses
  • What the Report Gets Wrong
• Conclusions
• References & Endnotes
• Appendix: Four Basic Policies to Promote Accessible Documents

Executive Summary

This article analyzes the recent Australian Government’s study into the Accessibility of the Portable Document Format for people with a disability (hereafter “the Report”), published in November, 2010 by the Australian Government Information Management Office (AGIMO) together with Vision Australia, a consultancy.

The Report is valuable for its accurate characterization of the current state of affairs for Assistive Technology (AT) users attempting to read and interact with PDF documents and forms. However, it does not address the significance of PDF technology for organizations and users, nor clearly identify the reasons why most AT users have a poor experience with PDF. Additionally, the Report provides no comparison of PDF accessibility, functionality, remediation complexity or cost with other formats. For these reasons and others, several of the Report’s key conclusions are unsupported by the data presented.

I argue for an alternative perspective on the Report’s data. The real story is that current Australian government policy is itself notably responsible for perpetuating the poor user experiences with PDF reported by AT-using Australians. To the extent that the Report’s recommendations bolster the current Australian policy, or influences other governments in their policy-making, equivalent access for AT users will suffer.

Finally, I outline an alternative approach to policy-making when addressing accessibility in any electronic document format, including PDF files.

Introduction

The drive to ensure electronic content is accessible by disabled users who require AT to read is led first and foremost by end-user frustration. Institutions and software developers rarely comprehend the importance of ensuring equal access to content unless their constituents or customers (and their lawyers) are banging loudly on the door, demanding equal access to content and resources that are readily available to conventionally-abled users.

In the case of blind, low-vision, motion-impaired and other users with relevant disabilities, they have been banging on the door of government and business for a long time. From bibles to train schedules to medical plan benefits to tax forms, disabled users have suffered the humiliation of constantly having to ask others for help since the invention of writing.

Electronic documents can generally be made accessible to users with many types of disability. That’s why, for disabled users, the Internet holds revolutionary potential for equal access to information. Progressive governments around the world, including Australia, Canada, the US and others are recognizing this fact, and the marketplace of ideas and technologies is (slowly) rising to meet the need. Worldwide, a variety of technologies, standards, policies and regulations have emerged over the past dozen or so years to mandate a degree of attention to accessibility. As of 2010, government content authors and managers in many countries and localities have statutory obligations to ensure the content they create or host is accessible (however defined).

Content delivered in HTML tends to be linear, relatively simple, and is typically served only one a page at a time. Since HTML is generally also created and managed by technical people, web-pages were unquestionably (and understandably) the low-hanging fruit when it comes to electronic content accessibility, and thus received the first systematic attention.

WCAG 1.0, in 1999, was the HTML-specific basis for the US Government’s Section 508 regulations that went into effect in 2001. WCAG 1.0 was superseded by the 2008 publication of WCAG 2.0, which places accessibility within a generic conceptual framework that’s not specific to any particular technology. WCAG 2.0 thus covers (but is not limited to) HTML, CSS, SVG, Flash and PDF technologies.

The Australian government requires its agencies to comply with WCAG 2.0, but unlike WCAG 2.0, it takes a dim view of PDF. Current policy states:

“…organisations that publish documents only in PDF risk complaint under the DDA unless they make the content available in at least one additional format….” (Australian Human Rights Commission, Disability Discrimination Act Advisory Notes)

Government (and business) websites and internal document collections generally include many PDF files. Most of these can’t readily make “…at least one additional format” available for the use of disabled users. Since AT users often complain about PDF files, the government understandably decided to find out why.

First… why are we talking about PDF?

Any attempt to understand PDF accessibility must start with the reasons why organizations and individuals the world over choose PDF in such a vast array of applications. PDF is an infrastructure technology, almost as essential to the modern world as HTTP, almost as basic as paper. In fact, PDF is, by design, “electronic paper”. (To learn more about why PDF is essential to the modern world, see my article: Why PDF?)

As with any electronic document format, ensuring PDF files are accessible requires an intention to do so, some basic knowledge of semantics and suitable software. For the AT user, accessible PDFs require a PDF reader and AT software capable of supporting “PDF tags” to ensure accessibility.

The Australian Government’s Report

The report’s purpose, as stated in the Executive Summary, is to study its premise; that in Australia,”Many technologies have accessibility issues but PDF is the one most often the subject of web accessibility complaints.”(1)

No data is offered to support this particular assertion, but in this case, none is required. It’s a reasonable starting-point based on the lamentable inattention to a broad-based understanding of accessibility among the vast majority of document authors and software developers. However, the problem of user ignorance about accessibility is certainly not specific to PDF, it’s just keenly felt with PDF, for reasons we’ll discuss shortly.

The Introduction goes on to point out that:

“[PDF] is widely used for making documents available on web pages and for distributing documents in electronic format.”(2)

How should the Australian government reconcile the evident popularity of PDF with its commitment to accessibility and adoption of WCAG 2.0? That is the question the Report attempts to address.

The Introduction

The Report begins with an introduction to web content accessibility, specifically, the Web Content Accessibility Guidelines (WCAG) 2.0 standard published in 2008. This document has been adopted by the government of Australia, among others. The Report notes, as mentioned, above, that WCAG 2.0 is technology-agnostic, and applicable to PDF.

When introducing PDF, the authors note in particular that producing accessible PDF files may be complex as a function of the “document design”. As noted above, making PDF accessible at the point of creation requires the author to correctly structure their document, then choose and use capable software. To check for accessibility, the author (and content manager) needs to be able to easily validate and correct documents following creation.

The Report notes that these requirements are not unique to PDF, acknowledges that accessibility requires correct structure in source documents irrespective of the document’s final format. Text messages and tweets aside, documents have the potential for equivalent accessibility only when the correct semantics are in place.

The Report asserts (without offering any data in support) that “…there is no agreed definition on what constitutes an accessible PDF that can be applied at this time.”(3).

The Report notes that PDF/UA, a forthcoming ISO International Standard providing normative language defining “Universal Accessibility” in PDF terms, is due to publish in 2011.

The Method

The study’s authors followed a three-stage process to collect data. They interviewed AT users about their experiences with PDF and requested submissions from interested parties, including vendors. They conducted a methodical performance evaluation of common assistive technologies with respect to PDF files. Finally, they asked a number of AT users to attempt interactions with tagged PDF files using the technology identified in Phase 2 as supporting PDF tags.

Phase 1: User and Public Consultation

In the initial User Consultation phase, conducted exclusively with blind and low vision users, the Report clearly found dissatisfaction with PDF. The technology is nonetheless commonly encountered…

“…from a wide variety of sources, including government, banks, telecommunication companies, restaurants, education providers and real estate agents. The need to interact with PDF files commonly occurred in activities related to their work and personal affairs….”(4)

On the other hand, AGIMO found that PDF is very popular with governments and businesses alike. As the 3rd Finding of the Public Online Consultation section recounts:

“Government submissions [to the report’s authors] revealed that the use of PDF files was prolific, [noting that] the Portable Document Format was still preferred over other formats;”(5)

Phase 2: Technical Evaluation

In the second phase, the Report examines a number of Assistive Technology products with the goal of establishing a list of currently-available assistive technologies capable of reading PDF tags, the means by which PDF files are made accessible.

Based on their findings, the authors state that:

“…it is inappropriate to state that PDF files can be regarded as an ‘Accessibility Supported’ technology under the W3C definition, without qualification.”(6)

No specific qualification is offered. The Report’s appears to base its contention that PDF files cannot be regarded as “Accessibility Supported” on the sole fact that as tested, NVDA (a free screen-reader) received a score of 41 out of a possible 43, and was thus judged only “partially sufficient”. The Report notes that the missing two points were a result of the software’s failure to correctly note language-changes encountered in text.

NOTE: We pause here to highlight that this issue – the functional difference between NVDA and JAWS according to this test, is an NVDA software bug, pure and simple. Moreover, it’s not a PDF-specific bug, but affects HTML handling as well. One does not make policy on the basis of software bugs that disappear (or appear) in each software release!

Phase 3: User Evaluations

The third “User Evaluations” phase integrates the information obtained in the first two phases of the report to provide a detailed backdrop for a specific study of measurable user experiences with properly tagged PDF files.

In this phase, individual users attempted specific tests with two groups of PDF files using the assistive technology software identified in Phase 2 as offering the best access to content in tagged PDF files.

One group of PDF files was tagged, the other was not. Unsurprisingly, the untagged files scored far lower for accessibility compared to the tagged files.

Of the tagged files, only two presented problems for AT users.(7) One such PDF included complex tables, support for which is limited in even the best current-generation AT, regardless of format and available WCAG 2.0 Techniques.

The other problem occurred when users had difficulty when asked to “navigate by page number” in a PDF in which each “page” consisted of 2 printed-page “spreads” (more on this below).

For the all-important “satisfaction rating” the Report states:

“Participants were generally satisfied with their use of the Collection A [tagged] documents and indicated they would be very comfortable in using PDF documents like these again.”(8)

What the Report gets Right

The Report follows a reasonable trajectory. In terms of characterizing user’s frustrations with inaccessible PDF files and the limitations of current-generation AT, most of the first and second phase Findings are clear, straightforward and proceed directly from the data. They may be restated as follows:

• Most document authors are largely ignorant of document semantics, and the importance of semantics to content accessibility. The report does note that this problem is not specific to PDF, but occurs as a function of “document design”.
• The software used to create PDF files may not create tagged PDF, or the tagging facility may be inactive.
• The available tools for adding and updating tags to existing PDF files are relatively complex for users unfamiliar with accessibility concepts. Formal WCAG 2.0 Techniques for PDF are still under development.
• Many AT vendors provide limited (or less) support for PDF files.(9) Certainly, in Australia, we note that vendors feel little pressure from procurement agencies to improve support for PDF.

In the third phase, screen-reader and other AT options ranging from expensive (Freedom Scientific’s JAWS) to free (NVDA) provided functionally equivalent and satisfactory performance on properly tagged PDF files as with HTML, with exceptions as discussed below.

Overall, the Report stands as an authoritative description of today’s situation. Users commonly encounter PDFs, those PDFs are rarely properly tagged and in any event, the current state of assistive technology offers relatively poor support for PDF’s accessibility capabilities. The third phase data confirms that while untagged or poorly tagged PDFs provided a generally inadequate experience, properly tagged PDFs provide a high-quality experience to AT users equipped with software capable of reading PDF tags.

The Report makes the inference that these facts are in large part a consequence of overly complex, hard-to-use software for manipulating tags in PDFs and a general lack of education and understanding about how to make accessible electronic documents. This is not unreasonable.

Adobe Systems, the developer of Acrobat, the most popular, capable and well-known PDF authoring and manipulation software, has not significantly updated Acrobat’s accessibility features since 2004. Additionally, Adobe’s Acrobat and Reader present a unfortunate picture of PDF accessibility with flawed implementations such as the “reflow mode”, “Read Out Loud” and “Accessibility Checker” features. These are not reliable or capable assistive technologies(10), but nor does Adobe claim them as such.

What the Report Misses

The Report excels at describing the sorry state of affairs that predominates for AT users encountering the vast majority of PDF files today. There are, however, a number of factors the authors simply ignore, with no small impact on the Report’s analysis and conclusions.

Why do authors, producers and distributors prefer PDF?

PDF creation happens democratically. It’s going on everywhere, all the time, for all kinds of reasons, and by people and software possessing all sorts of skill levels. Quite apart from individual users, PDFs are also increasingly churned out of automated systems for clinical reports, airline tickets, and the like. Accessibility is harder to enable, inspire or enforce because PDF is so flexible, so useful, so omnipresent, and issuing from so many sources.

Quite simply, no other format has the capabilities of PDF, capabilities that governments, businesses and individuals clearly need. There are good and substantial reasons why PDF is the world’s de facto electronic document format.

PDF reaches the needs other formats cannot

From scanned pages to print-runs to fold-out brochures, page-numbered or watermarked content, official (formal) documents, standardized forms and many other implementations, it’s often impractical to supplement or replace PDF files with HTML. A literal “page” is simply mandatory in vast numbers of real-world operational cases – and there’s no functional equivalent to a PDF “page” in HTML. (For a quick review of why PDF has quietly taken over the world, see my article: Why PDF?)

The Report’s authors missed this fact, even though a clear case-in-point was the objective cause of the single lowest score for a tagged PDF in the entire Report!

So-called “spread” pages are the only case that provoked a serious failure in Phase 3 of the study(11). This situation was scored as if PDF, or support for PDF was somehow at issue, but the simple fact is that a PDF file was selected for testing that was intended in every way for the printing-press, not for a user. It should not have been included in the study.

The authors do note that “…when documents only present one print page per screen page the issue is largely alleviated.” Indeed!

POLICY NOTE: Many of PDF’s most critical capabilities leverage the “page-based” nature of the format. Policy prescriptions should take care to ensure that accessibility requirements are applied appropriately.

Why is the typical AT experience of PDF so poor?

The Report failed to substantially investigate why the AT user’s experience with PDF files tends to be inferior to HTML. This subject is crucial to understanding the problem. The reasons are specific, and they are as follows:

PDF creation is democratic, HTML is centralized

As discussed above, most people don’t write HTML, so most don’t author documents with any attention to semantics. Since PDFs may be created and posted without the benefit of a content management professional, it’s harder to impose authoring standards outside of specific organizations.

POLICY NOTE: Document authors most frequently think of semantics by way of font typeface, size, color and text position. They typically don’t use Styles, and even when they do, they consider Styles in purely appearance terms, ignoring the fact that in most authoring applications, styles are the basic vehicle for document semantics. Without this understanding in place, any format, be it HTML, Word, RTF or PDF, will underperform in accessibility terms. The solution is to train document authors to recognize the significance of semantics for accessibility purposes, and how to leverage Styles to achieve high-quality semantics.

Most PDF creation software is incapable of translating source document semantics into PDF tags

Cheap is great, and free is better. It’s not just the free Reader that makes PDF popular, it’s the server software that creates PDF files from databases in vast numbers. It’s also the flood of low-cost alternatives to Adobe Acrobat, few of which support tagged PDF. The problem is simply that most of these software developers haven’t bothered to make software that creates or reads PDF tags because many of their institutional and government-agency customers have yet to demand it from them.

As a result, AT users have to put up with the software reading the PDF as if it was a painting, or with guesswork. Neither is properly “accessible”, to say nothing of “equal access”.

POLICY NOTE: Establishing minimum standards for software acquisition and content production will stimulate development at all levels of document software development, from automated banking systems to desktop applications. Server implementations are particularly susceptible to major advances. Improve the server software that creates PDFs, and millions of new statements, order-forms, receipts and more can become accessible overnight.

Tags-creation features are often deactivated in otherwise-capable PDF creation software

When accessible PDF isn’t required, or when the technology is assumed to be arcane or unavailable, there’s almost no education about PDF accessibility in government agencies or corporations. Many users with Acrobat and Microsoft Office installed have never even turned on the Tags feature in Acrobat’s MakePDF plugin, or create tagged PDF via the Microsoft Office Export to PDF function. Many users of InDesign are unfamiliar with accessibility – they’ve always been told it was a subject for the “web folks”.

On the other hand, there’s free office suite software (Open Office) that can make perfectly tagged PDFs from Word files. It even includes one of the bugs in Word that keep it from being able to author properly accessible tables.

POLICY NOTE: PDF creation software runs the gamut from free to very, very expensive. Many applications that can make PDFs don’t currently support the creation of tagged PDF, and software vendors don’t feel pressure to improve their products if their customers don’t demand it. Many AT developers have ignored the semantic structure capabilities of PDF even though they were published over 10 years ago. We will return to this point when considering the correct policy for accessible electronic content.

What the Report gets Wrong

In order to do science and make useful judgements for policy purposes, one requires comparisons, and there are very few comparisons provided in the Report. For this reason, we find it necessary to correct a number of unfounded assertions.

Follow basic guidelines, and PDF is not so difficult to make accessible

There’s no data provided to support the Report’s contention that PDF is difficult to make accessible, or how that level of difficulty compares to other formats, either as a theoretical or a practical matter. Crucially, the Report fails to provide information on the time and effort required to bring the Group B files used in Phase 3 to Group A (accessible) status. How are policy-makers to evaluate the relative difficulty of PDF accessibility versus conversion to or authoring in HTML without this data? Plainly, they cannot.

Beyond the work required to author or remediate accessible PDF, another key point of comparison would be to the time, effort and expertise required to create and post an accessible HTML version of the same document.

If the comparison data showed comparable time and effort – or even favored PDF (as I believe it often would), then several of the Report’s key Findings would be clearly invalidated. This question should have been rigorously examined, but remains unaddressed in the Report.

The Report states (correctly) that scanned documents present an accessibility challenge. However, the problem of scanned documents is not a PDF issue, it is a scanned document issue. It’s possible to make scanned pages into accessible PDF files by way of OCR, error correction and tags. The government is unlikely to be able to regulate away the need for scanned documents.

We’ve provided some basic references for those interested in how a user (author or content manager) can go about making PDF files accessible. It’s not rocket-science; it’s certainly no more complex than accessibility in HTML/CSS and JavaScript, the Report’s (apparent) basis for comparison. Yes, there is some confusion in some product documentation, and opinions differ in some areas. These are no more significant than the regular disagreements and heated discussions in the HTML accessibility arena.

W3C-published “Sufficient Techniques” are not required for WCAG 2.0 compliance

The Report refers to the availability of formal WCAG 2.0 Sufficient Techniques as definitive in terms of determining conformance with the Standard. However, the WCAG 2.0 document does not make this assertion. Indeed, it explicitly notes otherwise:

“…it is not necessary to use these particular techniques. If techniques are used other than those listed by the Working Group, then some other method for establishing the technique’s ability to meet the Success Criteria would be needed.”(12)

Clearly, irrespective of WCAG’s published Techniques, it’s up to the agency adopting WCAG 2.0 to determine whether “sufficient techniques” exist for a given technology to conform to the requirements of the standard – not the W3C.

While noting that formal Techniques have yet to be published for PDF, the Report’s authors fail to mention that such Techniques have also yet to be published for DAISY, RTF or DOC formats, and few are yet available for ARIA. The author’s logic would seem to require that the lack of formal Techniques means that these formats also cannot meet WCAG 2.0 standards, but this is not the Australian government policy.

WCAG 2.0 leaves “Accessibility Support” to be defined in context by an administrative entity (e.g. you for your own site, the Australian government for Australian government sites, etc.). The Report’s authors are ascribing an authority to WCAG 2.0 that the document does not claim to possess. As such, they are choosing to follow an essentially arbitrary publishing schedule over a substantive review and selection of real-world techniques.

The study conflates document design with PDF itself, with PDF software and with AT

Throughout the report, PDF as a technology is frequently conflated with PDF creation and reading software, with the skills of document authors and with AT support for PDF. The result is numerous statements and conclusions directed at the PDF format itself rather than document authors or software vendors.

A typical example occurs in Phase 2. Having determined that: “Only the JAWS screen reader and the ZoomText screen magnifier met all of the applicable tests…” the authors concluded “Therefore the technical testing finds that the Portable Document Format provides ‘sufficient’ technical capability for JAWS and ZoomText only.” The second statement does not follow from the first, because Phase 2 tests AT software, not PDF.(13)

If a given assistive technology is unable to fully process the tags in a properly-tagged PDF file, then the AT is deficient, it’s as simple as that. NVDA is open-source software and free to the end-user, and it’s not the only one. A donation would not go amiss – in fact, it would be excellent public policy.

We’ve got Techniques, but HTML accessibility is not a settled matter

Throughout the Report, the constant assumption is that HTML and AT support for HTML is a reference-point in terms of support for WCAG 2.0. The inference is that HTML/CSS/JavaScript accessibility is a settled and accepted matter, with broad AT support. This is hardly the case. In the HTML world, debate still rages on the role of alternate text, the longdesc key, links and requirements for support in older AT, to name only a few recent debates. Industry forums (the authoritative WebAIM listserv is one such example) play host to discussions on accessibility theory and practice for HTML, CSS, JavaScript and other web content concepts and technologies every day.

Even to the extent that HTML accessibility is well-defined, AT support remains a mixed bag. For example, AT software vendors have yet to provide consistent handling of tables in HTML.

Alternative formats are often expensive and may not offer “equal access”

The report infers that due to the claimed (but unsubstantiated) difficulties with ensuring PDF accessibility, attaining WCAG 2.0 conformance at a reasonable cost implies the use of alternative formats. This logic is invalid.

The cost of ensuring that a given PDF is accessible is ameliorated, first of all, by way of authoring practices that account for accessibility. Users who know how to make a Word file accessible can, with a few option-settings in place, create a tagged PDF file with a few clicks. InDesign 5.0 is only slightly more complex (and less capable) than Word, with a handful of work-arounds. It’s simply a question of education and training – just as with HTML.

At the end of the day PDF is often simply unavoidable – sometime the PDF simply “is” the document. If the same PDF can be made accessible at a reasonable cost, then the least-expensive and most practical solution is obvious. Conversion to another format is an unnecessary expense.

Conclusions

The AGIMO report gets a lot of things right, especially in describing the typical experiences of AT users when encountering the vast majority of today’s PDF files. While the Report correctly identifies a variety of difficulties for AT users, it does not usefully identify the reasons.

However, the Report does have a clear Finding in that properly tagged PDF files read by PDF-aware software in appropriate circumstances are fully accessible.

Regrettably, the Report fails to develop any case for one of its central claims: that achieving accessible PDF is significantly or inherently more difficult than the net effort required for other formats. While it’s not as stringent as WCAG 2.0, many US Federal and State agencies figured out long ago how to reliably and inexpensively create accessible PDF files as are required for conformance with Section 508.

If one does not look, however, one surely will not find.

You Reap What You Sow

The Report, to the extent that its recommendations are accepted, is a self-fulfilling prophesy. The Australian government has never required accessible PDF (as they do HTML), so naturally enough, they don’t encourage improvement. If they follow the recommendations of this report, they still won’t. Instead, they’ll get more inaccessible PDF, but they’ll also pay for a lot of HTML and Word files that their users don’t really need.

Better to insist that PDF files include valid tags as appropriate, insist that PDF creation software supports accessible PDF, and help educate and assist users in acquiring the PDF-aware AT that’s currently available. The idea that PDF accessibility is some arcane science has no basis in fact. The same energies that went into this Report could have authored a superb collection of Best Practice guidelines for Australian government document authors and managers.

In sum, the Australian government policy requiring HTML files as the “accessible equivalent” of any PDF file, as sustained by this Report, is actually counter-productive for the following reasons:

• It does not encourage authors to learn or adopt accessible authoring practices when creating or managing PDF files.
• It does not encourage PDF software developers to improve their tools for ensuring, improving or testing PDF accessibility.
• It does not encourage AT vendors to improve their support for the PDF file format.
• It is not technology-neutral

In short, it is not good government policy.

In the Appendix below, I’ve provided starting-point recommendations for electronic document accessibility policies that better meet the needs of document authors, managers, administrators and (most importantly) AT users.

Appendix: Four Basic Policies to Promote Accessible Electronic Documents

1. In applicable settings, all electronic documents irrespective of format must comply with WCAG 2.0.
   NOTE: The determination of whether an “applicable setting” exists is fundamentally common-sense, and made case-by-case. Generally speaking, documents posted to a website should be accessible. Drafts distributed only to specific users who do not require assistive technology probably don’t have to be accessible. Documents produced only for specific purposes (eg, printing) should never have to be accessible.
2. Irrespective of file-format, if a user complains about a specific document, that file must be examined and if necessary, remediated and reposted within a reasonable period of time.
3. Formal “Sufficient Techniques” are not required by WCAG 2.0(14). Document creation policies must be updated with best-practices guides for the creation of accessible content of any format (HTML, Word, PDF) capable of meeting WCAG 2.0 guidelines.
4. Once ISO 14289 is published…
   • When PDF documents are posted, such documents must comply with ISO 14289.
   • PDF reader software must comply with the “Conforming Reader” provisions of ISO 14289.
   • AT software must comply with the “Conforming Assistive Technology” provisions of ISO 14289.

Endnotes

1. The Report, Executive Summary
2. The Report, Executive Summary
3. The Report, Introduction, About PDF
4. The Report, Executive Summary
5. The Report, Phase One, User Consultation
6. The Report, Phase Two, Technical Evaluation
7. The Report, Phase Three, User Evaluations Table 5
8. The Report, Phase Three, User Evaluations Satisfaction Ratings
9. The Report, Phase Two, Technical Evaluation
10. See my review of PDF accessibility checkers and assessment of Acrobat’s Read Out Loud tool.
11. The Report, Phase Three, User Evaluations, Table 7 and following
12. WCAG 2.0: Layers of Guidance, Sufficient and Advisory Techniques
13. The Report, Phase Two, Technical Evaluation
14. WCAG 2.0: Understanding Conformance Claims and Understanding Accessibility Support

References

• The Australian Government’s study into the Accessibility of the Portable Document Format for people with a disability, November, 2010.
• Australian Human Rights Commission, Disability Discrimination Act Advisory Notes
• WCAG 1.0 and WCAG 2.0, publications of the World Wide Web Consortium (W3C)
• ISO/DIS 14289 (to be published in 2011) The Draft International Standard is currently available to ISO-accredited subject-matter experts and members of ISO TC 171/SC 2.
• A presentation describing ISO/DIS 14289, presented by Adobe Systems, Appligent Document Solutions and Microsoft, all members of AIIM’s US Committee for PDF/UA, to the ATIA Conference in October, 2010. This page includes an accessible PDF presentation.

Articles by the author referenced in the text

• Why PDF is the world’s de facto electronic document format
• Objects and Semantics
• Each PDF Page is a Painting
• It “sounded” like a good idea at the time
• REVIEW: PAC (PDF Accessibility Checker) 1.1
• Word doesn’t do Section 508, PDF gets the blame

Resources

PDF accessibility isn’t mysterious. From product documentation to agency best-practice documents, accessibility websites and more, organizations around the world have been producing accessible PDF files and sharing their techniques and standards for years.

• Draft WCAG 2.0 Techniques for PDF
• Adobe Systems PDF Accessibility Resources
• The WebAIM site includes some PDF Techniques, and hosts the respected WebAIM Listserv
• US Dept. of Health & Human Services PDF File 508 Checklist
• Illinois Department of Human Services PDF Accessibility Resources
• PDF/UA on AIIM’s PDF Wiki.
• Many other resources are a web-search away.

By Duff Johnson

About Appligent Document Solutions

Appligent Document Solutions provides PDF tagging services for producing accessible, Section 508 compliant documents.

Assistive Technology, Universal Accessibility, WCAG