E-mail List Archives
Re: clarification please -> PDF/UA
From: Jon Metz
Date: Feb 26, 2015 9:52AM
- Next message: Andrew Kirkpatrick: "Re: clarification please -> PDF/UA"
- Previous message: Karl Groves: "Re: Accessibility of Salesforce"
- Next message in Thread: Andrew Kirkpatrick: "Re: clarification please -> PDF/UA"
- Previous message in Thread: Andrew Kirkpatrick: "Re: clarification please -> PDF/UA"
- View all messages in this Thread
On Thu, Feb 26, 2015 at 7:44 AM, Jonathan Avila < <EMAIL REMOVED> >
wrote:
> I think PDF/UA is great but it is not a replacement to WCAG and I will be
> commenting on that to the US Access Board.
>
Sure, saying that PDF/UA is a higher standard probably implies that it's
better than something else. I can admit I was wrong to agree with that
sentiment. Instead I would say that PDF/UA is a better fit to make up for
gaps when solely applying WCAG recommendations.
But it also seems like the Access Board acknowledges that it isn't a
replacement either: "The Board proposes that all covered electronic content
would be required to conform to WCAG 2.0 Level A and Level AA Success
Criteria and Conformance Requirements specified for Web pages or, where
applicable, ISO 14289-1 (PDF/UA-1) (
http://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/proposed-rule/v-major-issues)
."
I have included a snippet below from Matterhorn that talks about PDF/UA 7.1.
I'd like to point out that Matterhorn isn't ISO 14289 (PDF/UA-1). It's
probably closer to "How do you meet" than an actual specification. For the
real deal you'd still need to buy a copy of the specifications. It's a
short document, but if you're used to the way WAI organizes things, the
specifications can be a bit weird.
Nothing in the above [omitted from original message-JM] requires that
> alternatives to color be visible to people who are colorblind - only that
> alternatives be available in the tags structure.
and
Nothing in the above requires that sufficient contrast be used in the
> document content - only that contrast isn't used to convey meaning.
You're right. Because it has nothing to do with the actual filetype. PDF/UA
is set up to "[identify] the set of PDF components that may be used and
restrictions on the form of their use (ISO 14289-1:2012, Introduction)." It
continues to state that it is meant to be used in conjunction with ISO
32000 and other standards as required, including WCAG 2.0.
Therefore, you're right that ISO 14289 is NOT a better standard, but I
would argue that using it for PDFs will be closer to making a more
accessible PDF.
Also you'll find nothing mentioned about the PDF containing closed captions
> or audio description when multimedia is present.
That's not true: 7.18.6 deals with multimedia. PDF/UA requires using a
method from the PDF Spec that lets the PDF reader to locate an appropriate
player for it. Additionally, it requires "alternate text descriptions for
the media clip data in case it cannot be played (from PDF 1.7, Table 274)."
It also states that if you use embedded media, it must be accessible "as
defined by applicable accessibility standards (if any) for its type."
Therefore, if you use multimedia, it is required by PDF/UA to also conform
to any provision required by A and AA in WCAG, or CVAA, or [insert Spec
here] if it's applicable. It also requires a method be implemented to
ensure that the file is usable regardless of a user's platform (Mac, DOS,
Windows, UNIX).
> Yet a bunch of what WCAG recommends could easily be classified as out of
>> scope (scripting, captions, embedded media, etc.),
>
>
> I have PDF with all of these components in them -- so they are definitely
> not out of scope -- just maybe not as common.
I am not saying that WCAG doesn't apply to those components when they are
in the PDF, but rather that the developers of Automated Checkers didn't
seem compelled to delve deeper into those requirements. Therefore, in my
opinion, unknowns seemed to be considered an out of scope requirement from
the Accessibility Checker developer's point of view. I will say that
Acrobat does a better job of handling unknowns than Word does. However,
here's what Adobe has to say about script accessibility: "Check the scripts
manually. Remove or modify any script or content that compromises
accessibility. (
https://helpx.adobe.com/acrobat/using/create-verify-pdf-accessibility.html)"
I don't consider this an endorsement. The fact is many if not most people
> are using Word, InDesign, and Acrobat at some point in the process to
> create tagged PDF content These tools are also something that people are
> familiar with and not providing steps to use them would be more harmful. I
Hmm. Suppose you were trying to understand what components are needed to
build a car radio, and the FCC explained that the "easiest way to use the
radio would be follow along with photos of the Ford F-150, making special
note of the controls on the Steering wheel as well as the proximity of the
radio to the right."
The problem with this approach is that, while the Ford F-Series is the most
popular car sold in America (
http://en.wikipedia.org/wiki/List_of_best-selling_automobiles#National_bestsellers),
it doesn't provide an overview of the requirements that every radio has to
include, but it sure looks like the FCC is making the statement that the
standard is based on this model car, not a specification defined from an
International Standard.
ISO 14289 requires that if you have a numbered list, you MUST use a label
tag and identify the numbering attribute. The Working Group basically said
that since current authoring software don't do that, they weren't going to
require it, even though there was a specification for it. That sure seemed
like an endorsement to me.
Thanks,
Jon Metzz
On Thu, Feb 26, 2015 at 7:44 AM, Jonathan Avila < <EMAIL REMOVED> >
wrote:
> Ã PDF/UA for sure is a higher standard than anything one could derive
> from WCAG when thinking about how to make PDFs accessible.
>
> Unfortunately I have to disagree with part of that comment. I think
> PDF/UA is great but it is not a replacement to WCAG and I will be
> commenting on that to the US Access Board.
>
> For example, take color and contrast. I have included a snippet below
> from Matterhorn that talks about PDF/UA 7.1.
>
> 04-001 Information is conveyed by contrast, color, format or layout, or
> some combination thereof but the content is not tagged to reflect all
> meaning conveyed by the use of contrast, color, format or layout, or some
> combination thereof.
>
> Nothing in the above requires that alternatives to color be visible to
> people who are colorblind - only that alternatives be available in the tags
> structure.
>
> Nothing in the above requires that sufficient contrast be used in the
> document content - only that contrast isn't used to convey meaning.
>
> There are also similar notes about use of sound:
>
> All information conveyed with sound should also be available without sound.
>
> In my opinion the above should needs to be a must.
>
> Also you'll find nothing mentioned about the PDF containing closed
> captions or audio description when multimedia is present.
>
> So, while PDF/UA is important it only gets you part of the way to WCAG
> conformance. - you still need WCAG.
>
> On a related note, I have used the axesPDF QuickFix program and I've found
> it to be very helpful in fixing documents that had corrupted tag
> structures. So, for anyone who has tagged a 100 page PDF only to find that
> the tag structure is corrupt and suddenly you can't tag content properly
> this tool can be invaluable. While there may be other products that do
> this some tool manufacturers won't sell to others they see as competition
> so it's great to have several choices like QuickFix on the market.
>
> Jonathan
>
> --
>
> Jonathan Avila
>
> Chief Accessibility Officer
>
> SSB BART Group
>
> <EMAIL REMOVED>
>
>
>
> 703-637-8957 (o)
>
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
On Thu, Feb 26, 2015 at 7:51 AM, Jonathan Avila < <EMAIL REMOVED> >
wrote:
> > Yet a bunch of what WCAG recommends could easily be classified as out of
> scope (scripting, captions, embedded media, etc.),
>
> I have PDF with all of these components in them -- so they are definitely
> not out of scope -- just maybe not as common.
>
> > II doubt I'm not the only one raising an eyebrow that an organization
> that advocates against endorsing software or using blatant superlatives
> uses screenshots of proprietary software and publicly claims "On the Home
> ribbon, use the lists tools to create or repair lists in Word documents.
> This is the easiest way to ensure that lists are formatted correctly when
> they are converted to PDF.".
>
> I don't consider this an endorsement. The fact is many if not most people
> are using Word, InDesign, and Acrobat at some point in the process to
> create tagged PDF content These tools are also something that people are
> familiar with and not providing steps to use them would be more harmful.
> If you feel additional software such as LibreOffice or Nuance PDF Creator
> Pro should be listed by all means submit a pull request to have those added
> to the github repository.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> <EMAIL REMOVED>
>
> 703-637-8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
- Next message: Andrew Kirkpatrick: "Re: clarification please -> PDF/UA"
- Previous message: Karl Groves: "Re: Accessibility of Salesforce"
- Next message in Thread: Andrew Kirkpatrick: "Re: clarification please -> PDF/UA"
- Previous message in Thread: Andrew Kirkpatrick: "Re: clarification please -> PDF/UA"
- View all messages in this Thread