WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: VPATs for Word, PPT, Excel, etc.

for

From: Duff Johnson
Date: Jun 8, 2018 9:49AM

> On Jun 6, 2018, at 20:30, Ryan E. Benson < <EMAIL REMOVED> > wrote:
>
>> Technically true, but since 87 of those checks don't require a human
> (except to review failures)

That's very true… but review of failures is inevitable. I guess the problem here is that too many PDF files are still of poor quality (from an accessibility point of view) out of the egg.

> , and the rest are the inevitable "human
> judgement" questions such as logical reading order and semantic
> appropriateness, testing for PDF/UA conformance doesn't have to be too
> fraught.
>
> How accurate is that though? Unless there have been big changes in the last
> year, most of those 87 are trust, but verify.

Well, the 87 machine tests have to do with factors that aren't something humans would normally verify. Either fonts are embedded, or they are not. Either there's Title metadata, or there is not. Either a language is set, or it is not, and so on. Now.. is the language set correctly? That's a different check.. and that is indeed either a "trust the provider" or a "human check required" - but I'm not sure how that's avoided at all, irrespective of technology.
>
>> - But you don't use the fact of the claim of PDF/UA conformance (which is
> intended for use only when all software and human-checks have been verified
> for that file) as part of your model? Is that so?
>
> The checklist was written in 2013, did not want to require external tools.
> To get conformance at that time, you either needed a good understanding of
> UA, or a third-party tool and decent knowledge. That is largely true still
> today. For HHS, a PDF is considered accessible if it passes our checklist.
> It involves passing the built-in checker.

OK, so the checker (I assume you mean Adobe's) is part of your evaluation. If your checker used PDF/UA, you would be able to check that much more about the file in an automated fashion.

>> What I'm getting at is: If someone has claimed PDF/UA, and if the claim
> is trustworthy… what are the other checks that apply? I'm thinking… perhaps
> the specific color-contrast checks defined in WCAG 2.0?
>
> In theory, then the PDF should pass HHS checklist, with the exception of
> maybe the HHS policy guidance at the top of the checklist, for example "All
> Document properties should be filled out Title, Author, (an HHS OpDiv,
> StaffDiv, or Program Office---not an individual's names) Subject, and
> Keywords."

Right; that's a policy thing, and PDF/UA can't take responsibility for it; of course.

> Re contrast: remember the WCAG 2.0 is the minimum, so there was
> a business decision to axe the large text or 14 pt and bold part to hold
> stuff to a higher level.

Also a policy thing.

OK, so if….

1) The file claimed to be PDF/UA, and
2) You had a PDF/UA validator that did all the machine checks AND provided a good user interface and experience for human checks, and
3) You could add your policies (WCAG-specific, or otherwise) into that validator, then…

- You'd have a dramatically simplified model!

I've written a short article that (I hope) explains this.

https://www.pdfa.org/using-pdfua-in-accessibility-checklists/

>> PDF/UA is TOO restrictive? (perhaps, because it requires sensible
> heading-levels)
> As an SME, no of course not! As somebody who barely know how to use Word,
> yes. I would love to plop down the Matterhorn Protocol, but the base level
> of knowledge is not at that level.

…which is another way of saying that the tools don't yet do enough of the work. The poor user should never have to see the Matterhorn Protocol unless they want DETAIL about a given failure or suspicious case. Otherwise, they should simply be concerned with: (a) is the logical reading order correct, (b) are the semantics (Figure, Heading, Paragraph, List, etc) correct, and whether or not they are obeying rules with respect to color, contrast, etc.

> I had to thread the needle between
> getting good stuff and not putting off large swaths of people. For example,
> lists. In 2013, to get the best support for AT, at that time, you needed l,
> li, lbody, and lbl.

Still true; all four structure elements are required for proper encoding of lists in PDF.

> To get those 4 tags, I remember having to trade a few
> of the other things that I wanted to add. This was 5.5 years ago, so what
> exactly that was, is beyond me.

Interesting! So, this is all driven by the tools. If the tools were smarter about applying the four list structure element types without human help, then you would not have to trade to get this right.

>> - PDF/UA is too hard to achieve with current tools?
> Yes. Resources is included in that too.

Really good to know; thanks!

Duff.