PDF vs. HTML
Last week I had an opportunity to visit with some faculty and staff at a Community College around the topic of accessible distance education. The school had recently chosen Blackboard as their Learning Management System and is working to adopt an attitude of Universal Design before their instructors learn any other way of doing things- kudos to them.
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:
- �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.
- �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.
- �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.
- �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.
- �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.
- �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.
I think that the good folks at WebAIM make some important points, in general, about pdf documents and accessibility. I do have to say, though, that I was surprised at the somewhat flimsy “words of caution” that were put forth by WebAIM when thinking about using Acrobat to create “accessible files.” I agree with most of John-Paul’s points that he makes in refuting the WebAIM document. The first five cautions do not in fact have anything to do with the Acrobat software itself- they caution that USERS might not “have the software.. be afraid to use it, etc.” I think that it is a very good thing that Adobe is working hard toward making pdfs accessible… this is certainly a positive step in the right direction, albeit not perfect.
In a perfect world, everyone creating websites would have access to a web developer who is up to speed on the latest in accessibility, and perhaps even the money to hire that person. This, unfortunately, is not so now, nor will it ever be that way. Web experts these days need to be more specialized than ever. There is no escaping the fact, however, that schools and other organizations will continue to create websites without using “professionals.” There is also no doubt that both Microsoft Word or Adobe Acrobat are not going away anytime soon. If anything they are becoming more ubiquitous. So if (and admittedly this is a big IF…) Adobe continues to move toward making it easy to mark up simple word docs so that the resulting pdfs are accessible, then I think it is more realistic to go this way, at least for now, then to cling to the hope that teachers and others will somehow yearn to become expert in XML and the subtle nuances of code.
Now please take this all with the knowledge that I have not had much experience in marking up Word docs or pdf so that they are able to be read by screen readers. If people need to go ahead and get some advanced training on how to mark these up just like one would go about posting accessible text in general, then I believe that one should go ahead and learn html. My feeling is that this is not in fact the case. But that is for someone else to comment on.
I am not a usability expert, but here are my comments:
I thought that version 6.0 speech feature was cool, and found it without any notice that it was available.
I don’t like pdf for general information, because it is harder to index in a site search, and I would rather not download an entire article, just to read in the first five lines that it is not what I was looking for.
But it has a place, for archive information that needs to be looked at more that once, for printing, and for re-distribution in a common format.
It has a strong place as a file/reporting format.
Adobe Acrobat became popular because of its ability to preserve the layout, typographic, and other visual qualities of documents in a world frustrated by so many variations in available fonts, browser quirks, and proprietary document viewing programs. Designers and authors were willing to put forth the money and time to use Acrobat because the final product’s visual accuracy was “worth it”. But in creating this safe zone for preserving visual design, Adobe ignored, until version 6, the need for internal markup to reflect the conceptual organization of content. This fundamental preference for visual design over conceptual organization will not disappear any time soon because Adobe will never abandon their original purpose for Acrobat. They are trying to have it both ways, but at its very best, Acrobat will always be visual with structure added. HTML on the other hand was designed around hierarchically structured content and only became concerned with visual design as an after-thought. In an accessible Web-based learning environment, structure and consistency are everything and visual design fidelity is nearly nothing. Therefore HTML (or better yet XHTML) IS the future of accessible markup and PDF has no short-term future. Universities would be wiser to develop and distribute well-designed CSS2 style sheets to be applied to standard HTML tagged documents than to train their faculty and staff to master the mysteries of Acrobat Accessibility Plug-ins.
Thanks for your comments- this is definitely an important issue. My experience with marking up Word/PDF documents is that it is not an extremely intuitive or user-friendly process. Is it easier than creating an HTML page? I suppose that depends primarily on what training and resources are available to faculty. If faculty were given a template with a well-defined style sheet for a Word to PDF document it would definitely be doable for most people, but I think that the same could be said of an HTML document.
Unfortunately few if any of the tools commonly used in creating either format still have a ways to go in encouraging (or forcing) users to create accessible documents.
As for some of the reasons that I prefer HTML over PDF- look for a post in the near future…