WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: clarification please -> PDF/UA

for

From: Andrew Kirkpatrick
Date: Feb 26, 2015 8:24PM

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 REMOVED> <mailto: <EMAIL 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 REMOVED> <mailto: <EMAIL REMOVED> >

>