WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Use of Headings

for

From: Rakesh.Paladugula@cognizant.com
Date: Jul 29, 2010 10:06PM


Hi Awk,
Thank you for your early response.

I am looking for the documents which specify what should be tested to
find that the PDF document is 100% accessible. eg: Verify the
navigation mechanisms in the document to aid the screen reader users etc
.
I require a list of check-points to be tested for all kinds of
disabilities and assistive technologies.

-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Andrew
Kirkpatrick
Sent: Thursday, July 29, 2010 5:44 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Use of Headings

Rakesh,
I'm not sure what exactly you are looking for when you say "a document
with test cases for PDF". Can you clarify?

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe Systems

<EMAIL REMOVED>
http://twitter.com/awkawk
http://blogs.adobe.com/accessibility

-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of
<EMAIL REMOVED>
Sent: Thursday, July 29, 2010 1:27 AM
To: <EMAIL REMOVED>
Subject: Re: [WebAIM] Use of Headings

Hi folks,
I am searching for a document with test cases for PDF accessibility. Can
any one of you have similar info or any pointers to the same. An early
response is highly appreciated.

-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Duff Johnson
Sent: Wednesday, July 28, 2010 7:21 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Use of Headings

On Jul 28, 2010, at 8:04 AM, Simius Puer wrote:

> I think we agree on the general principles here but I'm not entirely
sure
> why my response was dissected quite so thoroughly...

The "dissection"? Because you started with "Several major problems I
can see..." in regards what I considered a perfectly reasonable and
innocuous piece of situationally-specific advice.

Otherwise, I thought it was good educational fun. Snips for brevity
below...

> I agree with you that tools such as MS Word as they do have
limitations. In
> the real world though, the vast majority of bad mark-up is actually
down to
> the user not using the tool properly. I've also seen people say "Word
can
> not do XYZ" when I know full well that it can.

This is undeniably the case.

> Actually, it is entirely
> possible to give a document layout in Word without resorting to
tables. It
> might not be easy or intuitive, but it is a capability.

...but as we know, users will use the tool that's more intuitive or
otherwise familiar.

If the dang tool was capable of interacting with the user's choices to
effectively assist them in validating their intentions, then "table"
would simply be a content-handling concept that either may or may not
have logical-structure implications when deployed / published / output,
etc.

Of course, I'm not sure if the concept of content differentiated from
logical structure "computes" in the HTML-centric mind - but we should
probably leave that aside for now! :-)

> I don't want to re-start the "good format for the web" wars unless
>> absolutely necessary!
>>
>
> Me neither as I agree there are plenty of them hence I didn't rake
them up
> again - people can read the archives for that. My point was that most
> people are not even aware of the considerations when it comes to
format
> choice...not everyone is as familiar with the topic and might not know
that
> debate already exists on this list!

Well, I thought you meant otherwise... asking the questioner to
reconsider their delivery AND (potentially) authoring platforms simply
because they want to know how to wrangle a "table" struck me as a sort
of "passive-aggressive" move in the good old HTNL vs. PDF wars!

I'm glad to hear I was wrong.

> On what basis does it "sound like web content"? The original question
had
>> to do with table structure - not exactly a "web content specific"
issue.
>>
> Primarily because this is a forum about web and web accessibility in
> general. Then there was the hint: "She writes in Word, and then we
convert
> to PDF for publication on our website".

Ah.... and here we skirt dangerously close to the aforementioned wars...
because if you're disposed to think that PDF is a perfectly legitimate
way to publish on a website for all sorts of valid business reasons,
then (a) you don't automatically question the choice, and (b) the focus
tends to stay on the problem at hand rather than stepping back to first
principles of core technology choices and skill-sets.

> Sure, the tables are the focus of
> the problem, but as any Web professional knows when you look at one
problem,
> that problem is usually related to a slightly bigger picture.
>
> Now, if you work in a silo and only ever look at the problem in front
of you
> it might just talk about how to deal with the tables.

PDF exists precisely because people don't work in silos.

> However, taking a step back as I did, I simply suggested the
originator *may
> wish to consider* the format they are using in the first instance. I
don't
> think this takes such a leap of the imagination, it is not bad advice
and I
> don't see how putting that under a microscope will add any value to
the
> thread.

Ok - no more microscope! ;-)

> How is this advice PDF-specific? It seems the same advice that would
be
>> required for authoring accessible content from any format.
>>
>
> Agreed, it is sound advice for authoring accessible content in any
format.
> It wasn't specifically intended to be PDF-specific advice but the
whole
> point of "converting from Word to PDF" certainly puts it in that
ballpark.
>
> Again, I'm not sure why this point is being challenged or what value
you
> trying to add to the thread.

I was simply responding to the "major problems" you introduced.

> Just for the record I am not anti-PDF (which I get the impression was
the
> basis for your response) and I rate the file format quite highly -
*when
> used for legitimate reasons and created correctly*.

As is probably clear, we would probably disagree on what those
legitimate reasons might be... but that's for another thread (maybe in a
bar someday).

Duff Johnson
Appligent Document Solutions
http://www.appligent.com



> On 28 July 2010 11:35, Duff Johnson < <EMAIL REMOVED> > wrote:
>
>> These are interesting points, and I'm happy to provide some
additional
>> information.
>>
>> On Jul 28, 2010, at 4:38 AM, Simius Puer wrote:
>>
>>> Several major problems I can see:
>>>
>>> 1. You are getting someone unskilled in authoring for the web to
create
>>> the content. Content authors either need to be educated in
applying
>>> semantic structure to their documents, or the conversion of the
>> material
>>> should be left to someone in the web team.
>>
>> ...or the available tools (in the example case, MS Word) simply can't
do
>> the right thing by itself, no matter who is using it.
>>
>>> 2. By auto converting from Word to PDF with a source document that
has
>> no
>>> accessibility (I'm guessing as tables are used for layout that
other
>>> structures are also missing - heading etc) you are ending up with
an
>>> inaccessible PDF. The simple rule of rubbish in - rubbish out
(talking
>>> about the quality of the mark-up/tagging, not the actual content).
>>
>> No. Tables are used for layout because tables provide end-users with
>> layout capabilities in addition to semantic-structure capabilities.
>>
>> The problem is simply that software developers have yet to provide
>> conventional facilities to allow users to distinguish layout tables
from
>> tabular data when it comes to generating PDF files. It's not hard;
it's just
>> not been done yet. (just as Word doesn't yet support table row
headers).
>>
>>> 3. Whilst PDFs *can be* a million times more accessible than they
used
>> to
>>> be (if created properly), they still don't provide the best medium
for
>>> delivering Web content. There are plenty of discussions on that in
the
>>> archives of this discussion list...
>>
>> I don't want to re-start the "good format for the web" wars unless
>> absolutely necessary! I'll leave it at these hopefully
non-controversial
>> points...
>>
>> 1) There are legitimate reasons to publish in PDF.
>> 2) PDF provides a vehicle for making content from ANY source
accessible.
>> 3) The original question had to do with solving an accessibility
problem
>> in PDF
>>
>> Also note that the problem reported is NOT specific to PDF but is in
fact
>> the artifact of an authoring tool. As such, the problem also affects
Word,
>> HTML, etc.. not just PDF.
>>
>>> My suggestion would be to re-consider why you are using PDF to
publish
>> what
>>> sounds like Web content (as distinct from a document you simply wish
to
>>> share over the Internet) in the first place.
>>
>> On what basis does it "sound like web content"? The original
question had
>> to do with table structure - not exactly a "web content specific"
issue.
>>
>>> Most of the reasons people
>>> give for this are a little misled (I need people to be able to print
it
>>> etc...) and other reasons like SEO have not even been considered.
>>
>> I am tempted, but I'm not going there! (on this thread, anyhow)
>>
>>> If you have a genuine requiremtn to publish in PDF then to get
accessible
>>> PDFs you need to either:
>>>
>>> 1. educate your content creators into applying semantic markup and
also
>>> applying post-conversion QA *and *cleaning up any tag soup/apply
>> missing
>>> mark-up
>>>
>>> 2. have someone apply mark-up to the document professionally either
pre
>>> or post conversion...there are pros and cons to both approaches but
>> both are
>>> pretty labor intensive.
>>
>> How is this advice PDF-specific? It seems the same advice that would
be
>> required for authoring accessible content from any format.
>>
>> Duff Johnson
>> Appligent Document Solutions
>> http://www.appligent.com
>>