E-mail List Archives
Thread: clarification please
Number of posts in this thread: 16 (In chronological order)
From: Lucy Greco
Date: Fri, Feb 20 2015 11:26AM
Subject: clarification please
No previous message | Next message →
OK after reading through the thread about the 508 refresh i think i need a
clarification. could some one please explain the difference between pdf and
pdf UA and is UA really more accessible then PDF.
i have not delved in to the UA pdf before as its out of my scope but maybe
i need to smile Lucy
Lucia Greco
Web Accessibility Evangelist
IST - Architecture, Platforms, and Integration
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu
Follow me on twitter @accessaces
From: Jon Metz
Date: Fri, Feb 20 2015 1:33PM
Subject: Re: clarification please
← Previous message | Next message →
Hi Lucy,
The term, "Accessible PDF", is left up to interpretation. Some view this as
simply having a tagged PDF. Others argue that it has something to do with
the Reading Order pane of Acrobat. Still others insist that the only way to
do it is to simply rely on Microsoft Word or InDesign to magically create
one for you. Regardless, it's anyone's guess as to what it is.
ISO 14289 is a standard by which people can agree that certain provisions
will be met to ensure that a PDF is accessible according to the
capabilities of ISO 32000 (which governs PDF). It basically says, these are
all the things we're committing our PDFs to do and when we use technology
that conforms to those standards, then we can assume it'll work
appropriately.
So, because Accessible PDF is an opinion of the amount of work it takes to
make something like that accessible and PDF UA is an agreement between a
file and conforming reader of that filetype, then yes it is more accessible.
Jon Metz
On Fri, Feb 20, 2015 at 1:26 PM, Lucy Greco < = EMAIL ADDRESS REMOVED = > wrote:
> OK after reading through the thread about the 508 refresh i think i need a
> clarification. could some one please explain the difference between pdf and
> pdf UA and is UA really more accessible then PDF.
> i have not delved in to the UA pdf before as its out of my scope but maybe
> i need to smile Lucy
> Lucia Greco
> Web Accessibility Evangelist
> IST - Architecture, Platforms, and Integration
> University of California, Berkeley
> (510) 289-6008 skype: lucia1-greco
> http://webaccess.berkeley.edu
> Follow me on twitter @accessaces
> > > >
From: Olaf Drümmer
Date: Sat, Feb 21 2015 3:13AM
Subject: Re: clarification please -> PDF/UA
← Previous message | Next message →
You can find am introduction to PDF/UA, called "PDF/UA in a nutshell", on the website of the PDF Association at:
PDF/UA in a Nutshell | PDF Association
http://www.pdfa.org/publication/pdfua-in-a-nutshell/
The download link for the "PDF/UA in a nutshell" PDF is at the bottom of that page.
If you wanted to get a feel for PDF/UA conforming documents, there are a couple of decent example documents in the form of the "PDF/UA Reference Suite" (as a free download) at
PDF/UA Reference Suite | PDF Association
http://www.pdfa.org/publication/pdfua-reference-suite/
In case you really wanted to drill down into the rules that make PDF/UA what it is, in a form that is still relatively formal and technical, but not as dense as the ISO standard itself, have a look at the Matterhorn protocol:
The Matterhorn Protocol 1.02 | PDF Association
http://www.pdfa.org/publication/the-matterhorn-protocol-1/
Olaf
On 20 Feb 2015, at 21:33, Jon Metz < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Lucy,
>
> The term, "Accessible PDF", is left up to interpretation. Some view this as
> simply having a tagged PDF. Others argue that it has something to do with
> the Reading Order pane of Acrobat. Still others insist that the only way to
> do it is to simply rely on Microsoft Word or InDesign to magically create
> one for you. Regardless, it's anyone's guess as to what it is.
>
> ISO 14289 is a standard by which people can agree that certain provisions
> will be met to ensure that a PDF is accessible according to the
> capabilities of ISO 32000 (which governs PDF). It basically says, these are
> all the things we're committing our PDFs to do and when we use technology
> that conforms to those standards, then we can assume it'll work
> appropriately.
>
> So, because Accessible PDF is an opinion of the amount of work it takes to
> make something like that accessible and PDF UA is an agreement between a
> file and conforming reader of that filetype, then yes it is more accessible.
>
> Jon Metz
>
> On Fri, Feb 20, 2015 at 1:26 PM, Lucy Greco < = EMAIL ADDRESS REMOVED = > wrote:
>
>> OK after reading through the thread about the 508 refresh i think i need a
>> clarification. could some one please explain the difference between pdf and
>> pdf UA and is UA really more accessible then PDF.
>> i have not delved in to the UA pdf before as its out of my scope but maybe
>> i need to smile Lucy
>> Lucia Greco
>> Web Accessibility Evangelist
>> IST - Architecture, Platforms, and Integration
>> University of California, Berkeley
>> (510) 289-6008 skype: lucia1-greco
>> http://webaccess.berkeley.edu
>> Follow me on twitter @accessaces
>> >> >> >>
> > >
From: John E Brandt
Date: Wed, Feb 25 2015 1:27PM
Subject: Re: clarification please -> PDF/UA
← Previous message | Next message →
So, I was going to ask the group if the Accessibility Checker built into
Adobe Acrobat Pro (AAP) would accurately assess a file for PDF/UA. According
to the information Olaf provided from the PDF Association, the answer is no
and that the only validator that does this kind of assessment is the PAC:
PDF Accessibility Checker (v2.0). So I checked it out with document that was
initially a VERY simple MS-Word documents (no tables, simple text, a few
links and one in-line image) that had been converted using the SaveAs PDF
utility. It passed the Accessibility Checker in MS Word (latest version) and
essentially passed the accessibility checker in AAP - I had to manually add
the Title even though it was there in the MS-Word version (I think this is a
bug) and verify "manually" that the word order was correct and contrast
ratio sufficient. But the PAC found a number of errors thus deeming the
document NOT to be PDF/UA compliant. Interestingly, one of the "errors"
noted by PAC was the fact that the PDF/UA identifier was missing!
The WC3's document "PDF Techniques for WCAG 2.0"
http://www.w3.org/WAI/GL/WCAG20-TECHS/pdf.html gives high marks to both
MS-Word and AAP as the tools to use. Apparently the PDF/UA is a "higher" -
and perhaps unattainable standard. Clearly I can't figure out a way to meet
this standard with any of the tools I have.
So, I guessing that this is bad news if Section 508 Refresh is going to
require the ISO 32000-1 (PDF/UA-1) standard...
~j
John E. Brandt
jebswebs: accessible and universal web design,
development and consultation
= EMAIL ADDRESS REMOVED =
207-622-7937
Augusta, Maine, USA
@jebswebs
www.jebswebs.com
From: Jon Metz
Date: Thu, Feb 26 2015 12:39AM
Subject: Re: clarification please -> PDF/UA
← Previous message | Next message →
Hi John,
One of the problems with relying on proprietary software to check for
accessibility is that the errors checked are based on to their opinions.
Current Section 508 means Acrobat or Microsoft only needed to follow
bare minimum rules, despite ISO 32000 as explained Tagged PDFs since 2008
(in the open).
Truthfully, PDFs have been treated like that special kid sitting in the
corner eating paste (ah, memories) for way too long. The less support that
was made available to it, the easier it was to hate and be regarded as a
troublemaker of all the other formats. Unfortunately, clients still used
them and have been posting garbage for while.
When clients started turning to WCAG for answers is probably when Acrobat
and MS Word started tying those rules into their automated checkers. Yet a
bunch of what WCAG recommends could easily be classified as out of scope
(scripting, captions, embedded media, etc.), so there hasn't really been
much change aside from cleaning up the UI a bit.
I'm probably a bit more paranoid than others in this field, but the fact
that the W3C gives "high marks" to software that is owned by two of it's
members isn't really all that surprising. I 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.".
In fact, I suggested a couple years ago to modify the technique language to
reflect existing standards (
https://lists.w3.org/Archives/Public/public-comments-wcag20/2013Sep/0007.html).
Their response amounted to refusing to adhere to a specification based on
their opinion of value, adding that they were nice enough to include a copy
of the specs for further reading.
There will be people here who will tell you that PDF/UA (ISO 14289) is good
because it will force software developers to make more accessible PDFs,
essentially making less work for you. I'm confident that Adobe and
Microsoft are probably already working on something that will make these
bad rockets. However, I still believe there will be many people who just
hit 'Print' on their Macs and pass that off as an accessible document
continuing work for people like me, so it'll be important to know what to
do when it happens.
You're notion that PDF/UA is a "higher" standard is rather astute, but I
disagree that it's a bad thing. It means that if people will want to
continue to use a filetype they've been using, they're gonna need to start
making it accessible like everything else they put online. They can't
continue using the lame excuse that it sucks because it was underfunded and
came from a broken family (I'm looking at you, Flash...). The purpose is to
set out to make a standard.
And just an aside, you should know better than to rely on automated
testing! Tsk tsk.
â Jon
On Wed, Feb 25, 2015 at 3:27 PM, John E Brandt < = EMAIL ADDRESS REMOVED = > wrote:
> So, I was going to ask the group if the Accessibility Checker built into
> Adobe Acrobat Pro (AAP) would accurately assess a file for PDF/UA.
> According
> to the information Olaf provided from the PDF Association, the answer is no
> and that the only validator that does this kind of assessment is the PAC:
> PDF Accessibility Checker (v2.0). So I checked it out with document that
> was
> initially a VERY simple MS-Word documents (no tables, simple text, a few
> links and one in-line image) that had been converted using the SaveAs PDF
> utility. It passed the Accessibility Checker in MS Word (latest version)
> and
> essentially passed the accessibility checker in AAP - I had to manually add
> the Title even though it was there in the MS-Word version (I think this is
> a
> bug) and verify "manually" that the word order was correct and contrast
> ratio sufficient. But the PAC found a number of errors thus deeming the
> document NOT to be PDF/UA compliant. Interestingly, one of the "errors"
> noted by PAC was the fact that the PDF/UA identifier was missing!
>
> The WC3's document "PDF Techniques for WCAG 2.0"
> http://www.w3.org/WAI/GL/WCAG20-TECHS/pdf.html gives high marks to both
> MS-Word and AAP as the tools to use. Apparently the PDF/UA is a "higher" -
> and perhaps unattainable standard. Clearly I can't figure out a way to meet
> this standard with any of the tools I have.
>
> So, I guessing that this is bad news if Section 508 Refresh is going to
> require the ISO 32000-1 (PDF/UA-1) standard...
>
> ~j
>
> John E. Brandt
> jebswebs: accessible and universal web design,
> development and consultation
> = EMAIL ADDRESS REMOVED =
> 207-622-7937
> Augusta, Maine, USA
>
> @jebswebs
> www.jebswebs.com
>
>
>
From: Olaf Drümmer
Date: Thu, Feb 26 2015 3:04AM
Subject: Re: clarification please -> PDF/UA
← Previous message | Next message →
On 25 Feb 2015, at 21:27, John E Brandt < = EMAIL ADDRESS REMOVED = > wrote:
> Apparently the PDF/UA is a "higher" -
> and perhaps unattainable standard. Clearly I can't figure out a way to meet
> this standard with any of the tools I have
PDF/UA for sure is a higher standard than anything one could derive from WCAG when thinking about how to make PDFs accessible.
But PDF/UA is also a much more concise standard than what can be found regarding accessible PDF in WCAG. The main consequence here for software developers actually is that all in all it becomes substantially easier in the long run to develop software that supports accessible PDF (as defined by PDF/UA) - because it is easier to implement (and market) software against clear rules as opposed to having to do the same against fuzzy rules. I can at least claim this for my own company: we would never have considered to develop any PDF creation of fixing tool for conformance with WCAG's take on accessible PDF - it's just too fuzzy. Already before PDF/UA became final and published, we started development of a tool that helps create PDF/UA conforming accessible PDF documents (now commercially available for over two years). We also created a free of charge tool that helps validate PDF/UA files (especially when it comes to assessing semantic aspects). Furthermore we co-sponsored the development
of a free of charge PDF/UA syntax checker and also co-sponsored PDF/UA specific extensions to a free of charge screen reader. All this was only possible on the background of a well defined, clear cut ISO standard. It would not have have been viable without it.
Speaking of tools (and trying to not make this look like a sales pitch) let me provide the following list of tools that help you create PDF/UA, fix PDFs to make them conform with PDF/UA, tools that let you consume PDF/UA (leveraging PDF/UA specific aspects), and tools that help you assess conformance with PDF/UA.
Create PDF/UA:
- axesPDF for Word (still in [free of charge] beta, but expected to be released in the coming months)
- CommonLook Office
- axaio MadeToTag for InDesign
Fix (tagged) PDF to become PDF/UA conforming:
- axesPDF QuickFix
- CommonLook PDF Global Access
Consume PDF/UA:
- NVDA (screenreader) [free of charge]
- VIP PDF Reader (reader for low vision users) [free of charge]
Validate PDF/UA:
- PAC 2 (PDF Accessibility Checker version 2) [free of charge]
- callas pdfGoHTML [free of charge]
Olaf
PS: My views about PDF/UA might be biased, I belong to the group of ISO subject matter experts who developed the PDF/UA standard, I have two companies currently developing and selling tools in the area of PDF/UA, and I am also the chairman of the PDF Association, a trade association with a focus on PDF technology actively promoting adoption of PDF/UA. I have been involved in a similar fashion in the development of PDF/X for the printing industry, and PDF/A for the document management and archival industry. PDF/X and PDF/A have become extremely successful, and it is my personal goal to make PDF/UA at least as successful as PDF/X and PDF/UA. I believe that standards can only become successful if they are useful to a wide audience, and I am absolutely sure that PDF/UA is by far the most useful approach when it comes to ensuring accessibility of PDF documents, and making wide availability of accessible PDF a reality.
From: Jonathan C Cohn
Date: Thu, Feb 26 2015 4:46AM
Subject: Re: clarification please -> PDF/UA
← Previous message | Next message →
PDF can and do contain scripts I have used an accessible form Pdf that computed totals and had dialog boxes warning of missing information.
And I have seen mentions of embedded flash within PDF though I have not directly experienced that to the best of my knowledge. But if there is embedded flash there is the possibility of embedded video. So perhaps these are not as out of scope as you propose.
> On Feb 26, 2015, at 02:39, Jon Metz < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hi John,
>
> One of the problems with relying on proprietary software to check for
> accessibility is that the errors checked are based on to their opinions.
> Current Section 508 means Acrobat or Microsoft only needed to follow
> bare minimum rules, despite ISO 32000 as explained Tagged PDFs since 2008
> (in the open).
>
> Truthfully, PDFs have been treated like that special kid sitting in the
> corner eating paste (ah, memories) for way too long. The less support that
> was made available to it, the easier it was to hate and be regarded as a
> troublemaker of all the other formats. Unfortunately, clients still used
> them and have been posting garbage for while.
>
> When clients started turning to WCAG for answers is probably when Acrobat
> and MS Word started tying those rules into their automated checkers. Yet a
> bunch of what WCAG recommends could easily be classified as out of scope
> (scripting, captions, embedded media, etc.), so there hasn't really been
> much change aside from cleaning up the UI a bit.
>
> I'm probably a bit more paranoid than others in this field, but the fact
> that the W3C gives "high marks" to software that is owned by two of it's
> members isn't really all that surprising. I 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.".
>
> In fact, I suggested a couple years ago to modify the technique language to
> reflect existing standards (
> https://lists.w3.org/Archives/Public/public-comments-wcag20/2013Sep/0007.html).
> Their response amounted to refusing to adhere to a specification based on
> their opinion of value, adding that they were nice enough to include a copy
> of the specs for further reading.
>
> There will be people here who will tell you that PDF/UA (ISO 14289) is good
> because it will force software developers to make more accessible PDFs,
> essentially making less work for you. I'm confident that Adobe and
> Microsoft are probably already working on something that will make these
> bad rockets. However, I still believe there will be many people who just
> hit 'Print' on their Macs and pass that off as an accessible document
> continuing work for people like me, so it'll be important to know what to
> do when it happens.
>
> You're notion that PDF/UA is a "higher" standard is rather astute, but I
> disagree that it's a bad thing. It means that if people will want to
> continue to use a filetype they've been using, they're gonna need to start
> making it accessible like everything else they put online. They can't
> continue using the lame excuse that it sucks because it was underfunded and
> came from a broken family (I'm looking at you, Flash...). The purpose is to
> set out to make a standard.
>
> And just an aside, you should know better than to rely on automated
> testing! Tsk tsk.
>
> â Jon
>
>
> On Wed, Feb 25, 2015 at 3:27 PM, John E Brandt < = EMAIL ADDRESS REMOVED = > wrote:
>
>> So, I was going to ask the group if the Accessibility Checker built into
>> Adobe Acrobat Pro (AAP) would accurately assess a file for PDF/UA.
>> According
>> to the information Olaf provided from the PDF Association, the answer is no
>> and that the only validator that does this kind of assessment is the PAC:
>> PDF Accessibility Checker (v2.0). So I checked it out with document that
>> was
>> initially a VERY simple MS-Word documents (no tables, simple text, a few
>> links and one in-line image) that had been converted using the SaveAs PDF
>> utility. It passed the Accessibility Checker in MS Word (latest version)
>> and
>> essentially passed the accessibility checker in AAP - I had to manually add
>> the Title even though it was there in the MS-Word version (I think this is
>> a
>> bug) and verify "manually" that the word order was correct and contrast
>> ratio sufficient. But the PAC found a number of errors thus deeming the
>> document NOT to be PDF/UA compliant. Interestingly, one of the "errors"
>> noted by PAC was the fact that the PDF/UA identifier was missing!
>>
>> The WC3's document "PDF Techniques for WCAG 2.0"
>> http://www.w3.org/WAI/GL/WCAG20-TECHS/pdf.html gives high marks to both
>> MS-Word and AAP as the tools to use. Apparently the PDF/UA is a "higher" -
>> and perhaps unattainable standard. Clearly I can't figure out a way to meet
>> this standard with any of the tools I have.
>>
>> So, I guessing that this is bad news if Section 508 Refresh is going to
>> require the ISO 32000-1 (PDF/UA-1) standard...
>>
>> ~j
>>
>> John E. Brandt
>> jebswebs: accessible and universal web design,
>> development and consultation
>> = EMAIL ADDRESS REMOVED =
>> 207-622-7937
>> Augusta, Maine, USA
>>
>> @jebswebs
>> www.jebswebs.com
>>
>>
>>
From: Jonathan Avila
Date: Thu, Feb 26 2015 5:44AM
Subject: Re: clarification please -> PDF/UA
← Previous message | Next message →
Ø 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 ADDRESS REMOVED =
703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
From: Jonathan Avila
Date: Thu, Feb 26 2015 5:51AM
Subject: Re: clarification please -> PDF/UA
← Previous message | Next message →
> 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 ADDRESS REMOVED =
703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
From: Andrew Kirkpatrick
Date: Thu, Feb 26 2015 8:00AM
Subject: Re: clarification please -> PDF/UA
← Previous message | Next message →
> 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.
I agree with Jon Avila's comment. These are mentioned in specific PDF techniques and we are not only willing to add additional tools, but have already done so as in the case with Open Office. The techniques do not suggest that using Word or Acrobat is the ONLY way to accomplish a specific goal, just that they provide a way. I was the one who introduced the content in the PDF techniques, including the Word and Acrobat examples, and we added the Open Office example as part of the review process within the group. We're happy to add additional tools, but we are bandwidth constrained in the group and as far as how PDF is supported in the full set of PDF-producing tools we are also knowledge-constrained. Anyone can consider this an open invitation to share information or pull requests that will help us increase the utility of the techniques.
AWK
From: Jon Metz
Date: Thu, Feb 26 2015 9:52AM
Subject: Re: clarification please -> PDF/UA
← Previous message | Next message →
On Thu, Feb 26, 2015 at 7:44 AM, Jonathan Avila < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
>
>
>
> 703-637-8957 (o)
>
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
On Thu, Feb 26, 2015 at 7:51 AM, Jonathan Avila < = EMAIL ADDRESS 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 ADDRESS REMOVED =
>
> 703-637-8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
From: Andrew Kirkpatrick
Date: Thu, Feb 26 2015 10:36AM
Subject: Re: clarification please -> PDF/UA
← Previous message | Next message →
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.
Jon, I think that your analogy is a bit off. The technique (http://www.w3.org/TR/WCAG20-TECHS/PDF21.html ) says the following:
In the Description:
"The easiest way to create lists in PDF content is to format them properly using list markup in the authoring tool, for example, Microsoft Word or OpenOffice.org Writer. However, if you do not have access to the source file and authoring tool, you can use Acrobat Pro's TouchUp Reading Order tool and the Tags panel. "
In the Word example:
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.
In the Open Office example:
Use the Bullets and Numbering tool to create or repair lists in OpenOffice.org Writer documents. This is the easiest way to ensure that lists are formatted correctly when they are converted to PDF.
I think that if you are explaining how to use a car radio, then saying "the easiest way to turn the radio on is to follow the manufacturer's instructions" and for example, "if you are using a Honda accord do this..." and "if you are using a F-150 do this..." is closer to what is being written in the technique. The technique provides the "easiest" guidance in three different locations, so the intent was to scope the term "easiest" to the applicable section. Perhaps we can make that more clear by saying " 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 in Word documents before they are converted to PDF." (and do the same for the OO example). Would that help? Do you agree with the statement as is in the description section?
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.
In late 2011 when the PDF techniques were being reviewed PDF/UA wasn't published, so while you can ask why wasn't this guidance updated it is pretty clear why PDF/UA wasn't referenced in the technique to begin with. WCAG 2.0 wants structures contained within documents to be utilized by assistive technology correctly, and since the assistive technologies do support the structure both ways an author can make a reasonable claim that they meet WCAG with their lists either way. That may change at some point, and we will certainly update the advice if that happens. In the meantime, if you would like to offer language that provides a preferential direction for authors to follow, we'd be happy to review that.
Thanks,
AWK
From: Jon Metz
Date: Thu, Feb 26 2015 10:44AM
Subject: Re: clarification please -> PDF/UA
← Previous message | Next message →
On Thu, Feb 26, 2015 at 10:00 AM, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = >
wrote:
> The techniques do not suggest that using Word or Acrobat is the ONLY way
> to accomplish a specific goal, just that they provide a way. I was the one
> who introduced the content in the PDF techniques, including the Word and
> Acrobat examples, and we added the Open Office example as part of the
> review process within the group.
I can see your argument. But perhaps you can tell me why this is the only
area where an authoring software has been defined when explaining how to
implement WCAG recommendations. Why don't you include screenshots of
Dreamweaver with instructions on how to do that when writing HTML? This is
not "How to meet WCAG for proprietary software," as is the case when
talking about Flash. PDF has been with the ISO since 2008, so WCAG should
probably rely on what is required according to 1.7 rather than which
version of Word you are using.
I was the one who introduced the content in the PDF techniques, including
> the Word and Acrobat examples, and we added the Open Office example as part
> of the review process within the group.
And I truly believe this was a crucial addition to making the case that
WCAG isn't strictly for HTML, which is a frustrating misconception that I
often dispel to my clients. I think highly of you for introducing the
examples, and clearly the Working Group has benefited from your leadership.
I just believe that it doesn't go far enough to explain what is needed.
This makes it look like WCAG is saying the only way to make an accessible
PDF is to use Word and Acrobat.
And I have proof as to why this is detrimental. I had a client who had been
designing documents using InDesign, and then hired an insanely talented
designer to come in and *rebuild each heavily designed document into Word*,
based on what was recommended from WCAG as a technique!
We're happy to add additional tools, but we are bandwidth constrained in
> the group and as far as how PDF is supported in the full set of
> PDF-producing tools we are also knowledge-constrained.
So far the best answer seems to be PDF/UA. It doesn't makes sense to
recommend WCAG as the sole answer to one's PDF accessibility woes, yet then
explain how there are no resources to address it correctly. The current
process of relying on the status quo doesn't do anybody any good,
especially when there is already a recommended specification out there that
does have the resources to address it.
Anyone can consider this an open invitation to share information or pull
> requests that will help us increase the utility of the techniques.
There have been several voices on this list that seem to understand the
value of PDF/UA as well as how to implement it. Perhaps some sort of
voluntary open collaboration would best help both the ISO and WCAG. There's
no reason they couldn't work together to achieve the same goal, is there?
Best,
Jon
On Thu, Feb 26, 2015 at 10:00 AM, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = >
wrote:
> > 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.
>
> I agree with Jon Avila's comment. These are mentioned in specific PDF
> techniques and we are not only willing to add additional tools, but have
> already done so as in the case with Open Office. The techniques do not
> suggest that using Word or Acrobat is the ONLY way to accomplish a specific
> goal, just that they provide a way. I was the one who introduced the
> content in the PDF techniques, including the Word and Acrobat examples, and
> we added the Open Office example as part of the review process within the
> group. We're happy to add additional tools, but we are bandwidth
> constrained in the group and as far as how PDF is supported in the full set
> of PDF-producing tools we are also knowledge-constrained. Anyone can
> consider this an open invitation to share information or pull requests that
> will help us increase the utility of the techniques.
>
> AWK
> > > >
From: Jon Metz
Date: Thu, Feb 26 2015 2:32PM
Subject: Re: clarification please -> PDF/UA
← Previous message | Next message →
Andrew,
I apologize if I'm not making sense, because you seem really caught up on
the the "easiest method" to achieve something. I don't have a problem with
suggesting that the way to do something correctly is to use the original
authoring tool according to manufacture's directions. I also don't have any
concern for recommending methods for the only tool currently available to
remediate a document.
My issue stems from how a standards organization makes a statement that the
only thing a user needs to do is rely on the authoring document according
to the manual. If this were the way to do things, other techniques would
include similar examples as well. Instead they rely on the specifications
developed by the W3C for HTML, CSS, etc.
PDF accessibility as explained by WCAG relies too much on the authoring
software's judgement when it comes to generating an accessible PDF. As I
mentioned in my original email, the problem with relying on authoring
software to do this for you is that relies too heavily on how it's
interpretation of which rules ultimately affect their bottom line.
In late 2011 when the PDF techniques were being reviewed PDF/UA wasn't
> published, so while you can ask why wasn't this guidance updated it is
> pretty clear why PDF/UA wasn't referenced in the technique to begin with.
For what it's worth, in my original bug request in 2013, I never mentioned
PDF/UA. The Working Group did. Since you brought this up, if the techniques
were used in 2011, the published specification ISO 32000 was published 3
years earlier in 2008. PDF 1.7 specification clearly states:
"If present, the ListNumbering attribute, described in Table 347, shall
> appear in an L (List) element. It controls the interpretation of the Lbl
> (Label) elements within the list's LI (List item) elements (see "List
> Elements" in 14.8.4.3, "Block-Level Structure Elements")."
(Source: ISO 32000:2008 14.8.5.5, List Attribute)
The usage of "Shall" implies a requirement which isn't mentioned from the
WCAG technique page. After suggesting an example along with the correction,
they responded that it isn't up to them to make those changes, so there
isn't a need to address it. The only reason it's important for WCAG to
change it is because of how people view them as the defacto standard to use.
WCAG 2.0 wants structures contained within documents to be utilized by
> assistive technology correctly...
Assistive Technology does a lot of things to fix bad programming. In fact,
a lot of organizations tend to avoid designing solely for AT, since how it
cheats doesn't really address the needs of people using a different kind of
AT. I would argue that designing for AT doesn't do much more than up
promote bad software development practices.
... Since the assistive technologies do support the structure both ways an
> author can make a reasonable claim that they meet WCAG with their lists
> either way.
This sounds a lot like you are saying that the primary accessibility
objective everyone should strive for should be basically be compliance
(Interestingly, this kinda explains the rationale behind AAA
specifications), since technically passing the bare minimum requirements
would justify allowing AT to figure out the rest.
if you would like to offer language that provides a preferential direction
> for authors to follow, we'd be happy to review that.
I thought I did, but it looks like I keep getting shot down. So I'll do one
better. If someone wants a demonstration using Acrobat Pro on how to
implement PDF/UA, shoot me an email offline and I'll walk you through it.
Since people hate various screen sharing software, I'll use whichever free
one you prefer in order to demonstrate how it's done.
Eventually advances in technology will most likely address how to make
PDF/UA documents, but until then, we can help each other out.
â Jon
On Thu, Feb 26, 2015 at 12:36 PM, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = >
wrote:
> 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.
>
> Jon, I think that your analogy is a bit off. The technique (
> http://www.w3.org/TR/WCAG20-TECHS/PDF21.html ) says the following:
>
> In the Description:
> "The easiest way to create lists in PDF content is to format them properly
> using list markup in the authoring tool, for example, Microsoft Word or
> OpenOffice.org Writer. However, if you do not have access to the source
> file and authoring tool, you can use Acrobat Pro's TouchUp Reading Order
> tool and the Tags panel. "
>
> In the Word example:
> 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.
>
> In the Open Office example:
> Use the Bullets and Numbering tool to create or repair lists in
> OpenOffice.org Writer documents. This is the easiest way to ensure that
> lists are formatted correctly when they are converted to PDF.
>
> I think that if you are explaining how to use a car radio, then saying
> "the easiest way to turn the radio on is to follow the manufacturer's
> instructions" and for example, "if you are using a Honda accord do this..."
> and "if you are using a F-150 do this..." is closer to what is being
> written in the technique. The technique provides the "easiest" guidance in
> three different locations, so the intent was to scope the term "easiest" to
> the applicable section. Perhaps we can make that more clear by saying " 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 in Word documents before they are converted to PDF." (and do the
> same for the OO example). Would that help? Do you agree with the
> statement as is in the description section?
>
> 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.
>
> In late 2011 when the PDF techniques were being reviewed PDF/UA wasn't
> published, so while you can ask why wasn't this guidance updated it is
> pretty clear why PDF/UA wasn't referenced in the technique to begin with.
> WCAG 2.0 wants structures contained within documents to be utilized by
> assistive technology correctly, and since the assistive technologies do
> support the structure both ways an author can make a reasonable claim that
> they meet WCAG with their lists either way. That may change at some point,
> and we will certainly update the advice if that happens. In the meantime,
> if you would like to offer language that provides a preferential direction
> for authors to follow, we'd be happy to review that.
>
> Thanks,
> AWK
> > > >
From: Lynn Holdsworth
Date: Thu, Feb 26 2015 4:00PM
Subject: Re: clarification please -> PDF/UA
← Previous message | Next message →
Jon, I'd love to take you up on your offer, but the Acrobat XI UI isn't accessible enough for me to carry out any but the most rudimentary fixes. Indescribably frustrating.
Best, Lynn
> On 26 Feb 2015, at 21:32, Jon Metz < = EMAIL ADDRESS REMOVED = > wrote:
>
> Andrew,
>
> I apologize if I'm not making sense, because you seem really caught up on
> the the "easiest method" to achieve something. I don't have a problem with
> suggesting that the way to do something correctly is to use the original
> authoring tool according to manufacture's directions. I also don't have any
> concern for recommending methods for the only tool currently available to
> remediate a document.
>
> My issue stems from how a standards organization makes a statement that the
> only thing a user needs to do is rely on the authoring document according
> to the manual. If this were the way to do things, other techniques would
> include similar examples as well. Instead they rely on the specifications
> developed by the W3C for HTML, CSS, etc.
>
> PDF accessibility as explained by WCAG relies too much on the authoring
> software's judgement when it comes to generating an accessible PDF. As I
> mentioned in my original email, the problem with relying on authoring
> software to do this for you is that relies too heavily on how it's
> interpretation of which rules ultimately affect their bottom line.
>
> In late 2011 when the PDF techniques were being reviewed PDF/UA wasn't
>> published, so while you can ask why wasn't this guidance updated it is
>> pretty clear why PDF/UA wasn't referenced in the technique to begin with.
>
>
> For what it's worth, in my original bug request in 2013, I never mentioned
> PDF/UA. The Working Group did. Since you brought this up, if the techniques
> were used in 2011, the published specification ISO 32000 was published 3
> years earlier in 2008. PDF 1.7 specification clearly states:
>
> "If present, the ListNumbering attribute, described in Table 347, shall
>> appear in an L (List) element. It controls the interpretation of the Lbl
>> (Label) elements within the list's LI (List item) elements (see "List
>> Elements" in 14.8.4.3, "Block-Level Structure Elements")."
>
>
> (Source: ISO 32000:2008 14.8.5.5, List Attribute)
>
> The usage of "Shall" implies a requirement which isn't mentioned from the
> WCAG technique page. After suggesting an example along with the correction,
> they responded that it isn't up to them to make those changes, so there
> isn't a need to address it. The only reason it's important for WCAG to
> change it is because of how people view them as the defacto standard to use.
>
> WCAG 2.0 wants structures contained within documents to be utilized by
>> assistive technology correctly...
>
>
> Assistive Technology does a lot of things to fix bad programming. In fact,
> a lot of organizations tend to avoid designing solely for AT, since how it
> cheats doesn't really address the needs of people using a different kind of
> AT. I would argue that designing for AT doesn't do much more than up
> promote bad software development practices.
>
> ... Since the assistive technologies do support the structure both ways an
>> author can make a reasonable claim that they meet WCAG with their lists
>> either way.
>
>
> This sounds a lot like you are saying that the primary accessibility
> objective everyone should strive for should be basically be compliance
> (Interestingly, this kinda explains the rationale behind AAA
> specifications), since technically passing the bare minimum requirements
> would justify allowing AT to figure out the rest.
>
> if you would like to offer language that provides a preferential direction
>> for authors to follow, we'd be happy to review that.
>
>
> I thought I did, but it looks like I keep getting shot down. So I'll do one
> better. If someone wants a demonstration using Acrobat Pro on how to
> implement PDF/UA, shoot me an email offline and I'll walk you through it.
> Since people hate various screen sharing software, I'll use whichever free
> one you prefer in order to demonstrate how it's done.
>
> Eventually advances in technology will most likely address how to make
> PDF/UA documents, but until then, we can help each other out.
>
> â Jon
>
> On Thu, Feb 26, 2015 at 12:36 PM, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> 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.
>>
>> Jon, I think that your analogy is a bit off. The technique (
>> http://www.w3.org/TR/WCAG20-TECHS/PDF21.html ) says the following:
>>
>> In the Description:
>> "The easiest way to create lists in PDF content is to format them properly
>> using list markup in the authoring tool, for example, Microsoft Word or
>> OpenOffice.org Writer. However, if you do not have access to the source
>> file and authoring tool, you can use Acrobat Pro's TouchUp Reading Order
>> tool and the Tags panel. "
>>
>> In the Word example:
>> 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.
>>
>> In the Open Office example:
>> Use the Bullets and Numbering tool to create or repair lists in
>> OpenOffice.org Writer documents. This is the easiest way to ensure that
>> lists are formatted correctly when they are converted to PDF.
>>
>> I think that if you are explaining how to use a car radio, then saying
>> "the easiest way to turn the radio on is to follow the manufacturer's
>> instructions" and for example, "if you are using a Honda accord do this..."
>> and "if you are using a F-150 do this..." is closer to what is being
>> written in the technique. The technique provides the "easiest" guidance in
>> three different locations, so the intent was to scope the term "easiest" to
>> the applicable section. Perhaps we can make that more clear by saying " 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 in Word documents before they are converted to PDF." (and do the
>> same for the OO example). Would that help? Do you agree with the
>> statement as is in the description section?
>>
>> 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.
>>
>> In late 2011 when the PDF techniques were being reviewed PDF/UA wasn't
>> published, so while you can ask why wasn't this guidance updated it is
>> pretty clear why PDF/UA wasn't referenced in the technique to begin with.
>> WCAG 2.0 wants structures contained within documents to be utilized by
>> assistive technology correctly, and since the assistive technologies do
>> support the structure both ways an author can make a reasonable claim that
>> they meet WCAG with their lists either way. That may change at some point,
>> and we will certainly update the advice if that happens. In the meantime,
>> if you would like to offer language that provides a preferential direction
>> for authors to follow, we'd be happy to review that.
>>
>> Thanks,
>> AWK
>> >> >> > > >
From: Andrew Kirkpatrick
Date: Thu, Feb 26 2015 8:24PM
Subject: Re: clarification please -> PDF/UA
← Previous message | No next message
Jon,
I apologize if I'm not making sense, because you seem really caught up on the the "easiest method" to achieve something. I don't have a problem with suggesting that the way to do something correctly is to use the original authoring tool according to manufacture's directions. I also don't have any concern for recommending methods for the only tool currently available to remediate a document.
I'm glad you don't have a problem with this, but I also don't think that this is what the technique is doing. It shows a variety of ways, including both tools and looking at the postscript. The only reason that I was caught up in that phrase was because you kept bringing it up.
My issue stems from how a standards organization makes a statement that the only thing a user needs to do is rely on the authoring document according to the manual. If this were the way to do things, other techniques would include similar examples as well. Instead they rely on the specifications developed by the W3C for HTML, CSS, etc.
The difference is that essentially no one writes postscript by hand in the way that many people do for HTML. This was definitely discussed when we were working on the techniques.
In late 2011 when the PDF techniques were being reviewed PDF/UA wasn't
> published, so while you can ask why wasn't this guidance updated it is
> pretty clear why PDF/UA wasn't referenced in the technique to begin with.
For what it's worth, in my original bug request in 2013, I never mentioned PDF/UA. The Working Group did. Since you brought this up, if the techniques were used in 2011, the published specification ISO 32000 was published 3 years earlier in 2008. PDF 1.7 specification clearly states:
"If present, the ListNumbering attribute, described in Table 347, shall
> appear in an L (List) element. It controls the interpretation of the
> Lbl
> (Label) elements within the list's LI (List item) elements (see "List
> Elements" in 14.8.4.3, "Block-Level Structure Elements")."
The usage of "Shall" implies a requirement which isn't mentioned from the WCAG technique page. After suggesting an example along with the correction, they responded that it isn't up to them to make those changes, so there isn't a need to address it. The only reason it's important for WCAG to change it is because of how people view them as the defacto standard to use.
But it also states that the ListNumbering attribute is optional. The Shall only speaks to the location of this attribute if used. It is useful for providing information about the list, but as far as assistive technologies are currently concerned it isn't utilized as far as I know.
Assistive Technology does a lot of things to fix bad programming. In fact, a lot of organizations tend to avoid designing solely for AT, since how it cheats doesn't really address the needs of people using a different kind of AT. I would argue that designing for AT doesn't do much more than up promote bad software development practices.
Techniques are not requirements. You do not need to use a specific technique to meet any success criterion. This quickly gets into discussions of whether accessibility support by assistive technologies matters at all or whether authors just need to code content correctly. I think that we make gradual steps in that direction, but it is a constant push and pull as end users need content that actually works as much if not more than authors want simple, well-specified solutions. I do think that PDF/UA will help with this over time, especially as it provides requirements for conforming readers as well as the content itself.
... Since the assistive technologies do support the structure both ways an
> author can make a reasonable claim that they meet WCAG with their
> lists either way.
This sounds a lot like you are saying that the primary accessibility objective everyone should strive for should be basically be compliance (Interestingly, this kinda explains the rationale behind AAA specifications), since technically passing the bare minimum requirements would justify allowing AT to figure out the rest.
We are talking about a technique document which has a stated goal of showing a way (not the only way) of meeting a success criterion, so that's my frame of reference in this discussion.
if you would like to offer language that provides a preferential direction
> for authors to follow, we'd be happy to review that.
I thought I did, but it looks like I keep getting shot down.
You requested changes, and the WG said that it wasn't a high priority as there isn't a current difference, and invited you do suggest actual changes.
You wrote:
Proposed Change:
1. Show how lists are properly structured.
2. Explain which tags are optional for which list type (ordered must be labeled, unordered is optional) and which tags are mandatory.
3. Show how to properly adjust tags in PDF to create said list first without the use of proprietary means (i.e. from Word/InDesign/etc).
4. Change text from " the easiest way to ensure that lists are formatted correctly when they are converted to PDF" to "easiest way to ensure that THE BASIS for list STRUCTURE is formatted correctly when they are converted to PDF."
5. Provide examples for how to fix the incorrect placement of the tags after exporting from Word (as the example writer)
The WG responded:
Thanks for the comment. We understand that at this time PDF/UA requires that lists are constructed with Lbl and LBody tags inside each LI tag, but we also understand that current technologies do not distinguish between LI tagged elements with this internal tag structure from those that do not. The changes that you propose are reasonable but given that there is no difference for the end user we will defer this work until there is a difference. If you are interested in contributing the changes you suggest then the working group will be able to review that submission to be included. It is also worth noting that techniques assume that users are familiar with the technology spec, and that the techniques contain a reference to the PDF spec to provide more details for people who need them.
This isn't getting "shot down". This is "we have bigger fish to fry right now, if it is really important to you, provide specific language and we will review it". There's a big difference. If you want to provide that detail, you can submit a pull request on GitHub, or just write down the suggested changes in a document and send them in...
AWK
On Thu, Feb 26, 2015 at 12:36 PM, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >>
wrote:
> 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.
>
> Jon, I think that your analogy is a bit off. The technique (
> http://www.w3.org/TR/WCAG20-TECHS/PDF21.html ) says the following:
>
> In the Description:
> "The easiest way to create lists in PDF content is to format them
> properly using list markup in the authoring tool, for example,
> Microsoft Word or OpenOffice.org Writer. However, if you do not have
> access to the source file and authoring tool, you can use Acrobat
> Pro's TouchUp Reading Order tool and the Tags panel. "
>
> In the Word example:
> 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.
>
> In the Open Office example:
> Use the Bullets and Numbering tool to create or repair lists in
> OpenOffice.org Writer documents. This is the easiest way to ensure
> that lists are formatted correctly when they are converted to PDF.
>
> I think that if you are explaining how to use a car radio, then saying
> "the easiest way to turn the radio on is to follow the manufacturer's
> instructions" and for example, "if you are using a Honda accord do this..."
> and "if you are using a F-150 do this..." is closer to what is being
> written in the technique. The technique provides the "easiest"
> guidance in three different locations, so the intent was to scope the
> term "easiest" to the applicable section. Perhaps we can make that
> more clear by saying " 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 in Word documents before
> they are converted to PDF." (and do the same for the OO example).
> Would that help? Do you agree with the statement as is in the description section?
>
> 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.
>
> In late 2011 when the PDF techniques were being reviewed PDF/UA wasn't
> published, so while you can ask why wasn't this guidance updated it is
> pretty clear why PDF/UA wasn't referenced in the technique to begin with.
> WCAG 2.0 wants structures contained within documents to be utilized by
> assistive technology correctly, and since the assistive technologies
> do support the structure both ways an author can make a reasonable
> claim that they meet WCAG with their lists either way. That may
> change at some point, and we will certainly update the advice if that
> happens. In the meantime, if you would like to offer language that
> provides a preferential direction for authors to follow, we'd be happy to review that.
>
> Thanks,
> AWK
>
> > list messages to = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
>