Towards the beginning of the article he sets the first point of his summary:

Most PDFs on the web should be HTML

However, he then lists 14 instances where PDF may well be the appropriate file format. The article also goes on to debunk some popular myths surrounding PDF, explains how they can be made more accessible and an informative overview of how PDF files are handled by three popular screen readers (JAWS, Window-Eyes and Home Page Reader). Also, don’t miss out on the discussion.

adobe just announced acrobat 7.0 with “advanced accessibility features”– see bottom of page 2 here. interesting stuff on canada’s accessibility requirements.

Here are some of the points made by Mr. McDaniels that I consider to be misleading along with my own thoughts:

If a web author has supporting materials like .DOC and .PPT files, it is easy to covert these to PDF rather than attempt to re-author the content for HTML.

Is it not just as easy to convert a Word or PowerPoint file to HTML as to PDF? Why would you need to re-author the content for HTML but not for PDF?

The content and flow of a PDF is the responsibility of the author not the PDF file format. I can employ the same web writing guidelines you recommend into a PDF file.

This is true, but the nature and functionality of Acrobat lends itself much more to designing documents to look like printed text, not a browser. While you can mimic the style of web content using PDF documents, the majority of users don’t– it takes too much time and is an unfamiliar use of the PDF format. Why try to mimic a format when you can use the real thing?

PDF’s can be displayed Full-screen in a browser to hide the Adobe reader interface, and they can be embedded in HTML as well.

First of all, my guess is that a majority of users are unaware of how to eliminate the Adobe interace that shows up in the browser– and if it is hidden many users are confused with how to interact with the document. How do you navigate through the document? How do you print? How do you zoom? If you are going to use PDF’s, it makes sense to keep the interface there– but doing so adds a entire second set of user controls for the user to worry about. If you want to print a PDF doc from a browser, do you use the browser print button or the Adobe Print button? Furthermore, when you click on a PDF link on some platforms/browsers it doesn’t display in the browser unless you have a specific 3rd party plugin. Instead it downloads it to your computer and you have to then go find it to be able to open it.

PDF file size is determined by the author. Images can be optimized automatically to produce fast loading files, and documents can be optimized for fast web viewing to allow page-at-a-time downloading of long documents. I’ve seen plenty of HTML pages that reference 1MB images.

Here the comparison is being made between good PDF design to bad HTML design. True, images can be optimized for both formats, but my experience is that when the same content is converted into both PDF and HTML format, the HTML is generally going to be a smaller file size. See
this case study.

I can build clickable buttons and links into a PDF. I can even mimic a website’s navigation bar at the top of a PDF to make things easier for the viewer.

Again, yes you can mimic website navigation using PDF– but why not just use the format that you are trying to mimic?

Lest I be misunderstood, I wholeheartedly that there are unique situations where PDF is a more appropriate forma, but I feel that those situations are rare. I have no way to test or validate this, but my assumption is that is someone is faced with the choice on a website of viewing the same content in either HTML or PDF format, most people are going to click on the links to view the HTML. Given a choice, most people prefer to view content in an HTML format. Anyone using any type of technology can access HTML– no plugins or 3rd party software required.

All that said, don’t take my word for it– lots of peoples have different opinions on the matter with some accompanying issues:
Which format should you choose?
How Do You Like Your Documentation
Search Engines and PDF

We talked about understanding the perspective of learners with disabilities, went over semantic markup, alt tags and accessible video . Up to this point everyone seemed to be on the same page. However, there were some differences of opinion when we talked about the best format for displaying content online. The Director of Teaching and Learning Technologies, John-Paul San Giovanni is encouraging instructors to convert their course content into PDF files to promote a uniform format for everything. Since the training, John-Paul and I have opened up a dialog and with his permission, I’m opening the discussion up to Curb Cut readers– I hope you’ll take a second to weigh
in with your opinion (doesn’t everyone has an opinion regarding PDF docs?).

Our discussion has revolved around both accessibility and usability. Regarding accessibility, I put forth an
article titled Adobe Acrobat Accessibility Techniques
from the good folks at WebAIM. John-Paul thoughtfully went through the article and rebutted six points made at the beginning of the article, here are his comments, verbatim:

1. �Not everyone has the latest version of the Acrobat Reader�. This statement could be made for any software product including the browsers being used, word processing software, etc. So what relevant importance does it really have in comparing the advantages/disadvantages of conversion to HTML versus conversion to PDF file? If anything, since Acrobat Reader 6 is a free download, one can have the latest version at no cost and will take less time to download than an updated browser, etc.
2. �Not everyone who has the latest version has the full version with the embedded speech synthesizer�. Again, since it is a free download, how is this point important relevant in comparing the relative accessibility achieved via a �convert to HTML� versus a �convert to PDF�. I wonder when was the last time the author went to the Adobe site for the free download with the speech synthesizer � it�s there.
3. �The embedded speech synthesizer is not as good as the full-featured screen readers � (i.e., JAWS, Window Eyes)�. This is the equivalent of saying EXCEL is not as good of a word processor as WORD. ACROBAT is a tool for making PDF files. JAWS, etc. is a screen reader tool. Is it fair to JAWS does not make PDF files as good as ACROBAT? I do not think so! More disturbing to me, however, is that author missed (or failed to mention) an important point regarding ACROBAT 6 relative to accessibility features, namely, that it accurately translates the structure and tagging of the base document with a competence equal to that of a �convert to HTML� for MS Office products � a major source of e-formatted files.
4. �Not everyone knows that the speech synthesizer exists � in ACROBAT Reader�. And whose fault is that? This point is obviously not an inherent feature of ACROBAT 6. Should a similar statement be made regarding HTML because many of the inexperienced writers of HTML do not know all the parameters available within HTML? One could equally point out that many users of WORD do not know that they can �convert to HTML� from a menu (and, for most that do know, how long did it take them to find out?). In a similar vein, most WORD users do not know of the �Styles� capability and its value during a �convert to HTML�? The fact that many users of WORD do not know of these features of WORD is not an inherent fault of WORD. Similarly, the ignorance of a particular feature of any tool (especially, if accessed via menus) is not an inherent problem with the tool. Since this point does not state an inherent problem with ACROBAT 6, it is irrelevant in comparing the aforementioned alternate approaches to conversion relative to accessibility.
5. �Users who know that the speech synthesizer exists may be reluctant to use it because they do not know how to use it�. With ACROBAT 6, challenged users may use any full-featured screen reader they choose on the resultant PDF. That is part of beauty of what ACROBAT 6 offers regarding accessibility. It is a very important point that it is not necessary to use the embedded synthesizer in ACROBAT Reader 6 � the users can use whatever they are comfortable with. On the other hand, in all honesty, with all the truly difficult things that challenged individuals must learn to do with a computer, three clicks from pull-down menus or, alternatively, clicking ALT then V then A then O or E would probably seem relatively easy. That is all that is involved in the activating the ACROBAT Reader�s speech synthesizer.
6. �If the document is not created with accessibility in mind, it will likely pose accessibility challenges to blind users�. This statement is equally true for �convert to HTML� or the ACROBAT 6 �convert to PDF�. The �convert to HTML� in WORD, PowerPoint, and other products is no better at magically generating good accessibility code than the ACROBAT 6 �convert to PDF�. Consequently, this statement says nothing about the relative advantage of converting to HTML versus converting to a PDF.

What are your thoughts on the above?

On the usability front, I’ll point to two articles. The first one from Jakob Nielsen is titled
PDF: Unfit for Human Consumption where he outlines the “usability crimes” of PDF documents and the second is a rebuttal
to the first titled Adobe’s Robert McDaniels responds (again) to
Nielsen criticisms of PDF which both make good points. What do you think about the usability of PDF docs?

I have my own opinions on the matter, but will reserve them for the comments or a later post. In the meantime, site
stats show we’re getting a fair number of daily visits– even though not many of you comment, I know you’re out there. If you don’t mind, take a second to post your thoughts and on the topic, thanks.