Facts and Opinions About PDF Accessibility from A List Apart 4.0

As men­tioned all around the horn tonight A List Apart is back with a new design and a great new arti­cle from Joe Clark appro­pri­ately called Facts and Opin­ions About PDF Acces­si­bil­ity.

Towards the begin­ning of the arti­cle he sets the first point of his summary:

Most PDFs on the web should be HTML

How­ever, he then lists 14 instances where PDF may well be the appro­pri­ate file for­mat. The arti­cle also goes on to debunk some pop­u­lar myths sur­round­ing PDF, explains how they can be made more acces­si­ble and an infor­ma­tive overview of how PDF files are han­dled by three pop­u­lar screen read­ers (JAWS, Window-Eyes and Home Page Reader). Also, don’t miss out on the dis­cus­sion.

PDFs Redux

arti­cle from ear­lier this year on acces­si­ble pdf.

adobe just announced acro­bat 7.0 with “advanced acces­si­bil­ity fea­tures”– see bot­tom of page 2 here. inter­est­ing stuff on canada’s acces­si­bil­ity requirements.

PDF vs. HTML (take two)

There were a cou­ple of good com­ments on my post regard­ing the dif­fer­ences in acces­si­bil­ity PDF and HTML and I wanted to fol­low up with some more thoughts on the issue. In the ear­lier post I ref­er­enced Nielsen’s anti-PDF arti­cle and a rebut­tal to that arti­cle from McDaniels. While I may be ill-qualified and it may be some­what ridicu­lous to rebut a rebut­tal, I’d like to take issue with some of the points made in McDaniels rebuttal.

Here are some of the points made by Mr. McDaniels that I con­sider to be mis­lead­ing along with my own thoughts:

If a web author has sup­port­ing mate­ri­als like .DOC and .PPT files, it is easy to covert these to PDF rather than attempt to re-author the con­tent for HTML.

Is it not just as easy to con­vert a Word or Pow­er­Point file to HTML as to PDF? Why would you need to re-author the con­tent for HTML but not for PDF?

The con­tent and flow of a PDF is the respon­si­bil­ity of the author not the PDF file for­mat. I can employ the same web writ­ing guide­lines you rec­om­mend into a PDF file.

This is true, but the nature and func­tion­al­ity of Acro­bat lends itself much more to design­ing doc­u­ments to look like printed text, not a browser. While you can mimic the style of web con­tent using PDF doc­u­ments, the major­ity of users don’t– it takes too much time and is an unfa­mil­iar use of the PDF for­mat. Why try to mimic a for­mat when you can use the real thing?

PDF’s can be dis­played Full-screen in a browser to hide the Adobe reader inter­face, and they can be embed­ded in HTML as well.

First of all, my guess is that a major­ity of users are unaware of how to elim­i­nate the Adobe inter­ace that shows up in the browser– and if it is hid­den many users are con­fused with how to inter­act with the doc­u­ment. How do you nav­i­gate through the doc­u­ment? How do you print? How do you zoom? If you are going to use PDF’s, it makes sense to keep the inter­face there– but doing so adds a entire sec­ond set of user con­trols for the user to worry about. If you want to print a PDF doc from a browser, do you use the browser print but­ton or the Adobe Print but­ton? Fur­ther­more, when you click on a PDF link on some platforms/browsers it doesn’t dis­play in the browser unless you have a spe­cific 3rd party plu­gin. Instead it down­loads it to your com­puter and you have to then go find it to be able to open it.

PDF file size is deter­mined by the author. Images can be opti­mized auto­mat­i­cally to pro­duce fast load­ing files, and doc­u­ments can be opti­mized for fast web view­ing to allow page-at-a-time down­load­ing of long doc­u­ments. I’ve seen plenty of HTML pages that ref­er­ence 1MB images.

Here the com­par­i­son is being made between good PDF design to bad HTML design. True, images can be opti­mized for both for­mats, but my expe­ri­ence is that when the same con­tent is con­verted into both PDF and HTML for­mat, the HTML is gen­er­ally going to be a smaller file size. See
this case study.

I can build click­able but­tons and links into a PDF. I can even mimic a website’s nav­i­ga­tion bar at the top of a PDF to make things eas­ier for the viewer.

Again, yes you can mimic web­site nav­i­ga­tion using PDF– but why not just use the for­mat that you are try­ing to mimic?

Lest I be mis­un­der­stood, I whole­heart­edly that there are unique sit­u­a­tions where PDF is a more appro­pri­ate forma, but I feel that those sit­u­a­tions are rare. I have no way to test or val­i­date this, but my assump­tion is that is some­one is faced with the choice on a web­site of view­ing the same con­tent in either HTML or PDF for­mat, most peo­ple are going to click on the links to view the HTML. Given a choice, most peo­ple pre­fer to view con­tent in an HTML for­mat. Any­one using any type of tech­nol­ogy can access HTML– no plu­g­ins or 3rd party soft­ware required.

All that said, don’t take my word for it– lots of peo­ples have dif­fer­ent opin­ions on the mat­ter with some accom­pa­ny­ing issues:
Which for­mat should you choose?
How Do You Like Your Doc­u­men­ta­tion
Search Engines and PDF

PDF vs. HTML

Last week I had an oppor­tu­nity to visit with some fac­ulty and staff at a Com­mu­nity Col­lege around the topic of acces­si­ble dis­tance edu­ca­tion. The school had recently cho­sen Black­board as their Learn­ing Man­age­ment Sys­tem and is work­ing to adopt an atti­tude of Uni­ver­sal Design before their instruc­tors learn any other way of doing things– kudos to them.

We talked about under­stand­ing the per­spec­tive of learn­ers with dis­abil­i­ties, went over seman­tic markup, alt tags and acces­si­ble video . Up to this point every­one seemed to be on the same page. How­ever, there were some dif­fer­ences of opin­ion when we talked about the best for­mat for dis­play­ing con­tent online. The Direc­tor of Teach­ing and Learn­ing Tech­nolo­gies, John-Paul San Gio­vanni is encour­ag­ing instruc­tors to con­vert their course con­tent into PDF files to pro­mote a uni­form for­mat for every­thing. Since the train­ing, John-Paul and I have opened up a dia­log and with his per­mis­sion, I’m open­ing the dis­cus­sion up to Curb Cut read­ers– I hope you’ll take a sec­ond to weigh
in with your opin­ion (doesn’t every­one has an opin­ion regard­ing PDF docs?).

Our dis­cus­sion has revolved around both acces­si­bil­ity and usabil­ity. Regard­ing acces­si­bil­ity, I put forth an
arti­cle titled Adobe Acro­bat Acces­si­bil­ity Tech­niques
from the good folks at WebAIM. John-Paul thought­fully went through the arti­cle and rebutted six points made at the begin­ning of the arti­cle, here are his com­ments, verbatim:

1. �Not every­one has the lat­est ver­sion of the Acro­bat Reader�. This state­ment could be made for any soft­ware prod­uct includ­ing the browsers being used, word pro­cess­ing soft­ware, etc. So what rel­e­vant impor­tance does it really have in com­par­ing the advantages/disadvantages of con­ver­sion to HTML ver­sus con­ver­sion to PDF file? If any­thing, since Acro­bat Reader 6 is a free down­load, one can have the lat­est ver­sion at no cost and will take less time to down­load than an updated browser, etc.
2. �Not every­one who has the lat­est ver­sion has the full ver­sion with the embed­ded speech syn­the­sizer�. Again, since it is a free down­load, how is this point impor­tant rel­e­vant in com­par­ing the rel­a­tive acces­si­bil­ity achieved via a �con­vert to HTML� ver­sus a �con­vert to PDF�. I won­der when was the last time the author went to the Adobe site for the free down­load with the speech syn­the­sizer � it�s there.
3. �The embed­ded speech syn­the­sizer is not as good as the full-featured screen read­ers � (i.e., JAWS, Win­dow Eyes)�. This is the equiv­a­lent of say­ing EXCEL is not as good of a word proces­sor as WORD. ACROBAT is a tool for mak­ing 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 dis­turb­ing to me, how­ever, is that author missed (or failed to men­tion) an impor­tant point regard­ing ACROBAT 6 rel­a­tive to acces­si­bil­ity fea­tures, namely, that it accu­rately trans­lates the struc­ture and tag­ging of the base doc­u­ment with a com­pe­tence equal to that of a �con­vert to HTML� for MS Office prod­ucts � a major source of e-formatted files.
4. �Not every­one knows that the speech syn­the­sizer exists � in ACROBAT Reader�. And whose fault is that? This point is obvi­ously not an inher­ent fea­ture of ACROBAT 6. Should a sim­i­lar state­ment be made regard­ing HTML because many of the inex­pe­ri­enced writ­ers of HTML do not know all the para­me­ters avail­able within HTML? One could equally point out that many users of WORD do not know that they can �con­vert to HTML� from a menu (and, for most that do know, how long did it take them to find out?). In a sim­i­lar vein, most WORD users do not know of the �Styles� capa­bil­ity and its value dur­ing a �con­vert to HTML�? The fact that many users of WORD do not know of these fea­tures of WORD is not an inher­ent fault of WORD. Sim­i­larly, the igno­rance of a par­tic­u­lar fea­ture of any tool (espe­cially, if accessed via menus) is not an inher­ent prob­lem with the tool. Since this point does not state an inher­ent prob­lem with ACROBAT 6, it is irrel­e­vant in com­par­ing the afore­men­tioned alter­nate approaches to con­ver­sion rel­a­tive to accessibility.
5. �Users who know that the speech syn­the­sizer exists may be reluc­tant to use it because they do not know how to use it�. With ACROBAT 6, chal­lenged users may use any full-featured screen reader they choose on the resul­tant PDF. That is part of beauty of what ACROBAT 6 offers regard­ing acces­si­bil­ity. It is a very impor­tant point that it is not nec­es­sary to use the embed­ded syn­the­sizer in ACROBAT Reader 6 � the users can use what­ever they are com­fort­able with. On the other hand, in all hon­esty, with all the truly dif­fi­cult things that chal­lenged indi­vid­u­als must learn to do with a com­puter, three clicks from pull-down menus or, alter­na­tively, click­ing ALT then V then A then O or E would prob­a­bly seem rel­a­tively easy. That is all that is involved in the acti­vat­ing the ACROBAT Reader�s speech synthesizer.
6. �If the doc­u­ment is not cre­ated with acces­si­bil­ity in mind, it will likely pose acces­si­bil­ity chal­lenges to blind users�. This state­ment is equally true for �con­vert to HTML� or the ACROBAT 6 �con­vert to PDF�. The �con­vert to HTML� in WORD, Pow­er­Point, and other prod­ucts is no bet­ter at mag­i­cally gen­er­at­ing good acces­si­bil­ity code than the ACROBAT 6 �con­vert to PDF�. Con­se­quently, this state­ment says noth­ing about the rel­a­tive advan­tage of con­vert­ing to HTML ver­sus con­vert­ing to a PDF.

What are your thoughts on the above?

On the usabil­ity front, I’ll point to two arti­cles. The first one from Jakob Nielsen is titled
PDF: Unfit for Human Con­sump­tion where he out­lines the “usabil­ity crimes” of PDF doc­u­ments and the sec­ond is a rebut­tal
to the first titled Adobe’s Robert McDaniels responds (again) to
Nielsen crit­i­cisms of PDF which both make good points. What do you think about the usabil­ity of PDF docs?

I have my own opin­ions on the mat­ter, but will reserve them for the com­ments or a later post. In the mean­time, site
stats show we’re get­ting a fair num­ber of daily vis­its– even though not many of you com­ment, I know you’re out there. If you don’t mind, take a sec­ond to post your thoughts and on the topic, thanks.