I completely understand what you are saying. The Insurance Company example is spot on. The difficulty lays (lies) when a user or advocacy group has a hate-on for a particular format and uses a possible, but unlikely, scenario to claim discrimination. Without some type of harmonized standard for authors to conform to, everyone is at risk.

These same standards must be applied to all levels in the service delivery chain. AT advocates have long professed that formats must be accessible in the users preferred method of use. This is Wrong. The ISO Standard on Usability clearly makes a distinction between preference and the "context of use."

As for the timeliness of the WCAG WG  updating the Techniques, I think they are doing a great job. We were stuck with WCAG 1 for 11 years.

If we can set the stage for a harmonized method of accessibility conformance that doesn't rely upon a particular AT vendor's support, we can actually attain a truly measurable  level of accessibility.

Being called away, more to follow...

Duff, thanks for taking the time to identify the critical shortcomings of the Australian study and, therefore, of the conclusions drawn from it. The problems associated with creating accessible content — and, indeed, in evaluating that content to ensure that it actually is accessible — are highly complex, of course.

As for the way to ensure that documents are more accessible in the first place, you note:

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.

I would argue that you needed to add two words to the beginning of that sentence: "Part of."

I myself found it difficult to create accessible documents after having had the kind of training you describe. And I noticed that others who had received the same training paid great lip service to accessibility but themselves produced documents that were completely inaccessible.

Why was that so?

In addition to better training, we need better tools. And the simple fact is that modern word-processing applications lack the interface necessary to be tools well designed to support the creation of accessible documents. Look at the Home tab on the ribbon in Word, or the menus presented in Apple's Pages, or the toolbar for WordPerfect, or even the same for Open Office — the most prominent, easiest-to-use commands change the appearance of the text without adding semantic tags to the text.

If the job is to create an accessible document, why are those commands presented so prominently?

Let me put it another way: Why are those useless tools in the way?

We need Microsoft, Apple, Corel, and all the other developers of word processors to realize that we need interfaces that steer us in the direction of creating accessible documents. They need to look at every command on every menu, at every button on a toolbar or ribbon, and ask themselves, "Does this tool induce the user to create an accessible document, or an inaccessible document?"

Each tool that leads the user astray should be removed from the default interface — not removed from the software, just removed from its default interface. The newly available space should be given over to tools that, although useful, are now hidden deeply within the application's menus or, in some cases, user settings. For example, a button of command for changing the document template should be readily available by default. A button or command for modifying styles would be a good idea, too.

Because if we expect the user to separate content from presentation, we shouldn't constantly barrage the user with "features" that intermix the two.

I'd mentioned "hop about" in the structure tree of the PDF from down under.

"Hops" encountered were due to the major topic content's "cover page" having associated content sent to Artifact.
Appropriate in context of a "design decision" by those owning the content.

Other items that I find splintery I've send under separate cover.

Be well...

Thanks for posting such a well thought-out critique.

This article provides a balancing perspective which is needed to help people understand both sides of the PDF Accessibility debate.

My biggest take-away from the Australian Government's Report was quite similar to the crux of your article: the capability exists to create accessible PDF documents and the accessibility issues encountered are largely the result of poor authoring practices, content management oversight, and insufficient AT support for the Portable Document Format.

The "study" which is the basis of this report was commissioned by the Australian Government and was conducted by Vision Australia, a service provider for the visually impaired. It is apparent there certain advocacy tone contained in the report.

Earlier drafts had a much stronger position and did not include some of the balancing factors or more objective comments that the data would lead one to conclude. It was good to see the final report correct a lot of this. There are still some statements where I believe PDF gets a bad rap.

Yes, that spread layout definitely should not have been included in the study!

One thing which was left out - rightly so - is the historical user experience by AT users when interacting with PDF files. This often leads to a knee-jerk reaction by these users to automatically assume the worst and when they encounter something unexpected, they simply give up. Many AT users expect to be able to interact with any web technology in the same manner in which they interact with HTML. They often do not take the time to learn the features and navigation mechanisms of other technologies.

AT support for PDF is probably one of the biggest hold-backs. I was disappointed to read the one vendor response in particular: "More accessible PDF files are required before vendors justify further research and development time for PDF over other emerging technologies;" I feel this does a great disservice to their user-base. One has to wonder why AT users are not holding the vendors to a similar standard to which they hold authors and technology providers.

With regard to requiring Sufficient Techniques for Accessibility Supported Uses of Web Technologies, I feel this is a reasonable position. There are many resources on accessibility of a great number of technologies. Often, these resources provide conflicting guidance so there needs to be some way to harmonize what would be needed to conform to the applicable WCAG 2 Success Criteria.

The WCAG Working Group provides a means for new techniques to be submitted and vetted. Admittedly, the Working Group is small but I would hope they are open to any assistance that may be offered.

One final note: you make the comment "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." actually this is their position as noted by: "Where no WCAG 2.0 Sufficient Techniques exist to test the conformance of a technology or product, then WCAG 2.0 conformance cannot be claimed." (from - http://www.finance.gov.au/publications/wcag-2-implementation/scope.html).

Thanks again.

Thank you for a rational and insightful discussion. Having pulled in the PDF document that contained the report, I walked the structure tree. After all, it is a tagged PDF by way if InDesign. In short order it became clear that the PDF was largely unusable from an accessibility perspective. A sequential descend through tag elements resulted in random hops through the content; Link elements, while present, were not properly formed; and more. It is as if the PDF were meant to be unusable.

Really rather sad and does not speak well of the document's owners.

Accessible PDF just in not that hard to achieve.

Be well...