WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Ryan E. Benson
Date: Jun 9, 2018 9:38AM

> 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

eggactly (sorry). But yes, that is the other side of the coin. I mentioned
I couldn't plop down the full PDF/UA checklist, but I am hoping some day we
can get closer to that. The flip side is look at HTML, most people would
say automatic tools only can hit 45% of issues if we are being generous.

> Now.. is the language [and metadata] set correctly? That's a different
check..

Usually PDF Creators grab the author's details for the author metadata, so
for me it is Benson, Ryan E (HHS/Agency/Center/Division). To protect
employees, we require the author metadata be Center/Division or Name of
Program, so that's a test that is not useful. You point out the issue with
language, I would argue that one is pointless because a human still has to
check. Yes you can pop up a dialog to show those details, but I would argue
telling people how to look at the properties directly.

> If your checker used PDF/UA, you would be able to check that much more
about the file in an automated fashion.

In the blurb above this line, you talked about how yes you can test the
language, but a human still need to verify that it is set correctly. l
would say it isn't worth counting as a test because the results aren't
reliable at the end of the day.

> Otherwise, they should simply be concerned with: [snip]

Yes. That was my undocumented baseline, and had to parse them out into
non-technical English.

> 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.

YES! Also the cost of the tool is a factor.

--
Ryan E. Benson

On Fri, Jun 8, 2018 at 11:49 AM, Duff Johnson < <EMAIL REMOVED> > wrote:

>
> > 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.
> > > > >