E-mail List Archives
Thread: PDF, Accessibility and Quality Control
Number of posts in this thread: 10 (In chronological order)
From: Zwack, Melanie C
Date: Fri, Jan 26 2007 1:20PM
Subject: PDF, Accessibility and Quality Control
No previous message | Next message →
Can people share what they do to ensure Quality Control for Accessible
PDFs they produce?
My main question: How vigilant are you that the tags used in the
tagging, accurately represent the content? For example, in the past we
have placed content in sequential order as best we can, but pretty much
ignored the tags. For example, even if a paragraph text is tagged with a
header tag, we would just let it go, because mainly due to the fact of
how much time that it would take to correct this. Now, with Jaws 7.0
that we just got, it is actually reading 'Graphic: Then the content
here' - - so it is specifying the tag explicitly. The fact that in the
past we did not pay much attention to this, is now a problem when we use
Jaws 7.0 to Qc. Jaws is specifying each tag, before reading the
content, so it is obvious in the case when an incorrect tag is used. Any
thoughts on this?
Also, I am evaluation our Quality Control process in general for
Accessible PDFs, and would be very interested to hear of any other
people's procedures for this area. I would like to make sure our process
is where it needs to be.
I'll also start off with specifying our process:
1) We apply tags to a PDF and touchup the tags as necessary (ie.,
adding ALT tags to images, re-arranging the order of the tags as
necessary.)
2) Quality Control staff spot checks the PDFs to see if the tags
are reading right. (We do not use the automated Accessibility Checker to
verify correctness, but instead we have Quality Control check each file
with a Screen Reader.)
TIA
Melanie
From: Andrew Kirkpatrick
Date: Fri, Jan 26 2007 1:30PM
Subject: Re: PDF, Accessibility and Quality Control
← Previous message | Next message →
> I'll also start off with specifying our process:
It would help to also know what your process is leading up to the PDF
editing -- how do you generate the PDFs?
AWK
From: Phil Teare
Date: Fri, Jan 26 2007 1:40PM
Subject: Re: PDF, Accessibility and Quality Control
← Previous message | Next message →
convert to HTML is an option
Check OSS Ghostscript
--
Phil Teare,
Technical Director & Lead Developer,
http://www.talklets.com from Textic Ltd.
(44) [0] 77 68479904
From: Tamas Babinszki
Date: Fri, Jan 26 2007 4:20PM
Subject: Re: PDF, Accessibility and Quality Control
← Previous message | Next message →
Hi Melanie,
When you test with a particular screen reader it can be problematic, because
as you say, a different version will give you different results. Also, this
way people who use a different screen reader might also be excluded. It is
best to follow good practices, be as maticulous about tagging as possible,
and let assistive technologies worry about reading a properly written
document. It pays off on the long run.
Tamas Babinszki
Accessibility Consultant
http://www.a11yinfo.com
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Zwack, Melanie C
Sent: Friday, January 26, 2007 3:16 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] PDF, Accessibility and Quality Control
Can people share what they do to ensure Quality Control for Accessible PDFs
they produce?
My main question: How vigilant are you that the tags used in the tagging,
accurately represent the content? For example, in the past we have placed
content in sequential order as best we can, but pretty much ignored the
tags. For example, even if a paragraph text is tagged with a header tag, we
would just let it go, because mainly due to the fact of how much time that
it would take to correct this. Now, with Jaws 7.0 that we just got, it is
actually reading 'Graphic: Then the content here' - - so it is specifying
the tag explicitly. The fact that in the past we did not pay much attention
to this, is now a problem when we use Jaws 7.0 to Qc. Jaws is specifying
each tag, before reading the content, so it is obvious in the case when an
incorrect tag is used. Any thoughts on this?
Also, I am evaluation our Quality Control process in general for Accessible
PDFs, and would be very interested to hear of any other people's procedures
for this area. I would like to make sure our process is where it needs to
be.
I'll also start off with specifying our process:
1) We apply tags to a PDF and touchup the tags as necessary (ie.,
adding ALT tags to images, re-arranging the order of the tags as
necessary.)
2) Quality Control staff spot checks the PDFs to see if the tags
are reading right. (We do not use the automated Accessibility Checker to
verify correctness, but instead we have Quality Control check each file with
a Screen Reader.)
TIA
Melanie
From: Sean Keegan
Date: Sun, Jan 28 2007 1:20AM
Subject: Re: PDF, Accessibility and Quality Control
← Previous message | Next message →
Hi Melanie,
> How vigilant are you that the tags used in the tagging, accurately
represent the
> content?
It depends on the process used to create the PDF documents. Many of the
people I have worked with are creating content from MS Word and so rely on
the tagging that results from the PDFMaker conversion in MS Word (so the
result is that instead of a "H1" tag you may have a "Heading 1" tag). For
those who work with InDesign or another application, my big focus is getting
the document creators to ensure a logical reading order to the document, add
descriptions to images and the like.
If time is not a critical issue and the PDF was not well-formed from the
start (i.e, no headings, etc.), then I do suggest using the TouchUp Reading
Order tool to reclassify the content where appropriate. While the TouchUp
tool is a major improvement to how things had to be done in earlier versions
of Acrobat, a proper workflow is a better option IMO as touching up even
short document can take more time.
In terms of QC/QA, I generally do not recommend the use of a specific
screen-reader as what works in screen-reader version "X" does not mean that
the same function will exist in version "Y" (makes for some tedious
testing!). I try out a few screen-readers when I am trying something new in
the PDF conversion process, but I have that luxury. The best results I have
had with respect to evaluating reading order is to save out a tagged PDF as
"Text(Accessible)" from the Save As... menu. You should get the proper text
flow and additional items that a screen-reader will also announce are
typically displayed in brackets. The drawback to this method is if data
tables are present (linearizes the data).
So, I would echo Andrew's question as to what is your workflow for PDF
document creation? Otherwise, your step 1 looks fine and if all you are
doing is spot checking, then I would try the Save As... and saving the PDF
as a Text(Accessible) file.
Take care,
Sean
-----Original Message-----
From: Zwack, Melanie C [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Friday, January 26, 2007 12:16 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] PDF, Accessibility and Quality Control
Can people share what they do to ensure Quality Control for Accessible PDFs
they produce?
My main question: How vigilant are you that the tags used in the tagging,
accurately represent the content? For example, in the past we have placed
content in sequential order as best we can, but pretty much ignored the
tags. For example, even if a paragraph text is tagged with a header tag, we
would just let it go, because mainly due to the fact of how much time that
it would take to correct this. Now, with Jaws 7.0 that we just got, it is
actually reading 'Graphic: Then the content here' - - so it is specifying
the tag explicitly. The fact that in the past we did not pay much attention
to this, is now a problem when we use Jaws 7.0 to Qc. Jaws is specifying
each tag, before reading the content, so it is obvious in the case when an
incorrect tag is used. Any thoughts on this?
Also, I am evaluation our Quality Control process in general for Accessible
PDFs, and would be very interested to hear of any other people's procedures
for this area. I would like to make sure our process is where it needs to
be.
I'll also start off with specifying our process:
1) We apply tags to a PDF and touchup the tags as necessary (ie.,
adding ALT tags to images, re-arranging the order of the tags as
necessary.)
2) Quality Control staff spot checks the PDFs to see if the tags
are reading right. (We do not use the automated Accessibility Checker to
verify correctness, but instead we have Quality Control check each file with
a Screen Reader.)
TIA
Melanie
From: Zwack, Melanie C
Date: Mon, Jan 29 2007 8:40AM
Subject: Re: PDF, Accessibility and Quality Control
← Previous message | Next message →
Here are some key responses I got the the questions about PDF,
Accessibility, and Quality Control:
* If time is not a critical issue and the PDF was not
well-formed from the start (i.e, no headings, etc.), then I do suggest
using the TouchUp Reading Order tool to reclassify the content where
appropriate. While the TouchUp tool is a major improvement to how
things had to be done in earlier versions of Acrobat, a proper workflow
is a better option IMO as touching up even short document can take more
time.
* In terms of QC/QA, I generally do not recommend the use of a
specific screen-reader as what works in screen-reader version "X" does
not mean that the same function will exist in version "Y" (makes for
some tedious testing!). I try out a few screen-readers when I am trying
something new in the PDF conversion process, but I have that luxury.
The best results I have had with respect to evaluating reading order is
to save out a tagged PDF as "Text(Accessible)" from the Save As... menu.
You should get the proper text flow and additional items that a
screen-reader will also announce are typically displayed in brackets.
The drawback to this method is if data tables are present (linearizes
the data).
* When you test with a particular screen reader it can be
problematic, because as you say, a different version will give you
different results. Also, this way people who use a different screen
reader might also be excluded. It is best to follow good practices, be
as maticulous about tagging as possible, and let assistive technologies
worry about reading a properly written document. It pays off on the long
run.
These are all interesting responses, and I really appreciate the input.
My points about the above are:
* For MS Word and InDesign, I recognize the fact that in those
sorts of PDFs, I have control over how the tags will be outputting.
These sorts of PDFs are much easier to deal with. However, I guess my
real concern is for those PDFs, such as those developed in Quark or
other programs, where the output tags is not so clean, and there's no
control over the source-files. At this point, we've just been making it
work - - getting the content in the correct sequential order and
applying alt tags to images. This is a pretty basic goal, but given the
fact that the PDF is a difficult one to work with, and the goal of
trying to tag it perfectly could really literally take 2-3 times as
long, we've made the decision that this basic goal - - getting the
content in the correct sequential order is good enough. I've disregarded
whether the tags correctly associated with <h3> <p> <figure> - - so far
this has worked. Do you feel that this is acceptable in terms of quality
control? Or, should we try to actually tag these correctly?
* Another question I have, You speak of well-formed documents.
What exactly do you mean by that. I guess I'm not totally clear about
what the meaning of a well-formed document is?
* We are currently using Acrobat 7 Pro, and possibly soon
working with Acrobat 8 Pro. Since Acrobat 5, it was just amazing to get
a document tagged in the first place. But, now several years later, I
think it is important to re-evaluate these standards, and figure out if
there are better ways that we need to do things.
TIA
Melanie Zwack
-----Original Message-----
From: Zwack, Melanie C [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Friday, January 26, 2007 12:16 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] PDF, Accessibility and Quality Control
Can people share what they do to ensure Quality Control for Accessible
PDFs they produce?
My main question: How vigilant are you that the tags used in the
tagging, accurately represent the content? For example, in the past we
have placed content in sequential order as best we can, but pretty much
ignored the tags. For example, even if a paragraph text is tagged with a
header tag, we would just let it go, because mainly due to the fact of
how much time that it would take to correct this. Now, with Jaws 7.0
that we just got, it is actually reading 'Graphic: Then the content
here' - - so it is specifying the tag explicitly. The fact that in the
past we did not pay much attention to this, is now a problem when we use
Jaws 7.0 to Qc. Jaws is specifying each tag, before reading the
content, so it is obvious in the case when an incorrect tag is used. Any
thoughts on this?
Also, I am evaluation our Quality Control process in general for
Accessible PDFs, and would be very interested to hear of any other
people's procedures for this area. I would like to make sure our process
is where it needs to be.
I'll also start off with specifying our process:
1) We apply tags to a PDF and touchup the tags as necessary (ie.,
adding ALT tags to images, re-arranging the order of the tags as
necessary.)
2) Quality Control staff spot checks the PDFs to see if the tags
are reading right. (We do not use the automated Accessibility Checker to
verify correctness, but instead we have Quality Control check each file
with a Screen Reader.)
TIA
Melanie
From: Robinson, Norman B - Washington, DC
Date: Mon, Jan 29 2007 12:50PM
Subject: Re: PDF, Accessibility and Quality Control
← Previous message | Next message →
Melanie,
We have many different functional organizations creating
content. We are most likely to provide an accessible PDF if the original
document is maintained for updates and accessibility. Applying tags to
the PDF is a second-hand approach unless you expect the PDF to never be
updated and stored as the "original" document. Our policy is to always
provide and accessible text alternative along with the PDF
(http://www.usps.com/cpim/ftp/hand/as508a/508a_c6.html#508hdr59 and
specifically
http://www.usps.com/cpim/ftp/hand/as508a/508a_c6.html#508hdr79) which
I've found HTML to be the most consistently accessible.
Note that I've seen many business units create PDF versions of
anything they could normally print (e.g., Presentations, Documents,
Slides, Spreadsheets) because they think PDF is accessible and because
they (although they don't usually state this) want something that is
platform-neutral (will work on any computer or operating system) so
end-users won't generally bother them for a specific format.
I'm a little archaic in that I start with the premise that PDF's
primary purpose is for PRINTING. I keep that in mind when I challenge
individuals with why the business wants to make a PDF version of a
document. It is important to question why before we simply work on
making PDFs accessible, when the business process (e.g., document
management) is broken or non-existent. I'll get off my soap-box and wish
you the best of luck.
I hope that was useful in some way.
Regards,
Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Zwack,
Melanie C
Sent: Friday, January 26, 2007 3:16 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] PDF, Accessibility and Quality Control
Can people share what they do to ensure Quality Control for Accessible
PDFs they produce?
My main question: How vigilant are you that the tags used in the
tagging, accurately represent the content? For example, in the past we
have placed content in sequential order as best we can, but pretty much
ignored the tags. For example, even if a paragraph text is tagged with a
header tag, we would just let it go, because mainly due to the fact of
how much time that it would take to correct this. Now, with Jaws 7.0
that we just got, it is actually reading 'Graphic: Then the content
here' - - so it is specifying the tag explicitly. The fact that in the
past we did not pay much attention to this, is now a problem when we use
Jaws 7.0 to Qc. Jaws is specifying each tag, before reading the
content, so it is obvious in the case when an incorrect tag is used. Any
thoughts on this?
Also, I am evaluation our Quality Control process in general for
Accessible PDFs, and would be very interested to hear of any other
people's procedures for this area. I would like to make sure our process
is where it needs to be.
I'll also start off with specifying our process:
1) We apply tags to a PDF and touchup the tags as necessary (ie.,
adding ALT tags to images, re-arranging the order of the tags as
necessary.)
2) Quality Control staff spot checks the PDFs to see if the tags
are reading right. (We do not use the automated Accessibility Checker to
verify correctness, but instead we have Quality Control check each file
with a Screen Reader.)
TIA
Melanie
From: John Foliot - Stanford Online Accessibility Program
Date: Mon, Jan 29 2007 6:20PM
Subject: Re: PDF, Accessibility and Quality Control
← Previous message | Next message →
Zwack, Melanie C wrote:
>
> * Another question I have, You speak of well-formed documents.
> What exactly do you mean by that. I guess I'm not totally clear about
> what the meaning of a well-formed document is?
Melanie,
While your question focuses on PDFs, the same requirement exists for web
documents: i.e. they need to be "well-formed" as well. A very good article
that explains this concept may be found at A List Apart:
http://www.alistapart.com/articles/grokwebstandards
While it speaks of "web standards", the section about "Think Like a Writer"
pretty much sums it up.
HTH
JF
From: smithj7@peoplepc.com
Date: Mon, Feb 05 2007 7:06AM
Subject: Re: PDF, Accessibility and Quality Control
← Previous message | Next message →
I also have a few questions about PDF and accessiblity. Well it's actually
more about the main document if it is created in indesign. I have limited
experience with indesign. Can that document convert to a PDF that is
accessible? I always have to spend lots of times with documents that are
given to me in PDF format to put on the web that are created in indesign.
The most recent was probametic because it was in a forgein language that
sometimes switched to english.
----- Original Message -----
From: "John Foliot - Stanford Online Accessibility Program"
< = EMAIL ADDRESS REMOVED = >
To: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
Sent: Monday, January 29, 2007 8:14 PM
Subject: Re: [WebAIM] PDF, Accessibility and Quality Control
> Zwack, Melanie C wrote:
>>
>> * Another question I have, You speak of well-formed documents.
>> What exactly do you mean by that. I guess I'm not totally clear about
>> what the meaning of a well-formed document is?
>
> Melanie,
>
> While your question focuses on PDFs, the same requirement exists for web
> documents: i.e. they need to be "well-formed" as well. A very good
> article
> that explains this concept may be found at A List Apart:
> http://www.alistapart.com/articles/grokwebstandards
>
> While it speaks of "web standards", the section about "Think Like a
> Writer"
> pretty much sums it up.
>
> HTH
>
> JF
>
>
>
From: Sean Keegan
Date: Mon, Feb 05 2007 7:06AM
Subject: Re: PDF, Accessibility and Quality Control
← Previous message | No next message
> Can that document convert to a PDF that is accessible?
The short answer is yes. I have been working this week on a few InDesign
projects and have been getting tagged PDFs that are accessible (caveat:
these have been relatively simple documents compared to what you can do in
InDesign). Not quite as simple as working with something like MS Word, but
the learning curve is not too steep.
Take care,
sean
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, February 01, 2007 5:29 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] PDF, Accessibility and Quality Control
I also have a few questions about PDF and accessiblity. Well it's actually
more about the main document if it is created in indesign. I have limited
experience with indesign. Can that document convert to a PDF that is
accessible? I always have to spend lots of times with documents that are
given to me in PDF format to put on the web that are created in indesign.
The most recent was probametic because it was in a forgein language that
sometimes switched to english.