WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Ryan E. Benson
Date: Jun 6, 2018 6:30PM

> Technically true, but since 87 of those checks don't require a human
(except to review failures), 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.

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

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

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

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

--
Ryan E. Benson

On Wed, Jun 6, 2018 at 2:56 PM, Duff Johnson < <EMAIL REMOVED> > wrote:

> Thanks for the information, Ryan,
>
> > What each agency accepts is up to
> > each agency, but there is a strong effort to make one checklist for each
> > file type.
>
> Ok, I thought so. This is helpful… I will have a idea put-together to
> bounce off you soon. :-)
>
> >> Do you use the PDF/UA flag as part of your deliverable?
> >
> > Speaking with knowledge of HHS only. HHS has used PDF/UA as a basis for
> our
> > March 2013 release of the PDF checklist.
>
> OK, excellent.
>
> > We don't cover every element of
> > the PDF/UA checklist because there's 130 or so checks in UA's
> requirements,
>
> Technically true, but since 87 of those checks don't require a human
> (except to review failures), 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.
>
> > as one of 2 primary authors, I knew handing a checklist of 130 to the
> > various groups that needed to sign off on it, it would never fly. UA is
> not
> > explicitly mentioned in the 2013 version because that would blow up for
> > using a new term. HHS requires our PDF checklist for PDF deliverable. The
> > checklist is required because there's no 100% accurate test, though I
> know
> > some third-party tools come close.
>
> OK, so…
>
> - PDF/UA helped inform development of your own checklist
> - 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?
>
> 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?
>
> Could the checklist for PDF be simpler if it was composed of:
>
> - PDF/UA conformance (verified by vendor and spot-tested (or whatever) by
> the procuring agency
> - Additional specifications (i.e., the gap between whatever PDF/UA
> represents and the standard you want to meet)
>
> Is the problem…
> - PDF/UA is TOO restrictive? (perhaps, because it requires sensible
> heading-levels)
> - PDF/UA is too hard to achieve with current tools?
> - Other?
>
> I am NOT judging / doubting / complaining! I just want to understand how
> you thought about this.
>
> Thanks,
>
> Duff.
> > > > >