WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: CommonLook failures and HHS requirements


From: Chagnon | PubCom
Date: Dec 21, 2017 10:44PM

You're running into an industry problem.

There is no authoritative, defined "do this / don't do that" standard for those who create accessible PDFs.

The PDF/UA standard (ISO 14289-1:2012, https://www.iso.org/standard/54564.html) is a technical specification for how a PDF is to be produced by software. It really doesn't say anything much about how content creators (you, me, and HHS) should make a PDF accessible.

For example, no standard states how many H1 tags can be in a document (and some of us argue whether any standard should ever state how many should be allowed in a document). Or how many words/characters should be in Alt-text. Or what items should have Alt-text at all, such as whether it's needed on descriptive hyperlinks.

The end result of this industry shortcoming; everyone gets to make up their own requirements of what makes a PDF accessible. HHS (Health and Human Services) has theirs. CommonLook and other industry tool makers have theirs. My firm has ours. WCAG has its version. And I'm sure every single remediator on this list has their own version, too.

Your comments on the five issues you stated below are valid. RE: Number 5 about embedding fonts, I strongly urge you to always embed fonts (with subsetting) so that all characters are recognized and presented to the user accurately. Otherwise a screen reader, for example, will miss a math symbol.

But the bottom line for your post is that HHS calls the shots as to what they want to see in a PDF. You signed a contract to meet their PDF standards for accessibility. Reread every word of the contract. Make it happen.

A federal government agency can legally hold your company's feet to the fire to meet the specified requirements in the contract. Your opinion has little bearing on the contract's requirements. The time to question the requirements was during the bid cycle, not after the contract was awarded.

In federal government contracting, we contractors must produce what it required by the contract or the agency can take legal action and essentially ban us from future federal contracts. In my professional opinion (I am not a lawyer but teach classes on government contracting), your company should consider the feedback you received from HHS as a "cure" letter; that is, you have not met the contract's requirements and they are formally telling you to fix the deliverable or be in violation of the contract. If you don't understand this, please consult a lawyer who is knowledgeable about federal government contracting.

We can debate later if some agencies have gone overboard on some of their requirements. Right now, you have to bring your deliverables into compliance with the contract.

Hope this helps,
--Bevi Chagnon

— — —
Bevi Chagnon
www.PubCom.com | Technologists for Accessible Design and Publishing
print – digital – web – documents – pdfs – epubs
consulting – training – development – design – sec. 508 services
— — —
Bevi Chagnon is a US delegate (ANSI) to the ISO for PDF and PDF/UA standards

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Alan Zaitchik
Sent: Thursday, December 21, 2017 8:53 PM
Subject: [WebAIM] CommonLook failures and HHS requirements

Happy holidays to one and all. I'm hoping someone can help quickly despite the impending holiday and vacations.

A client has pushed back to us a large set of PDFs we remediated to comply with HHS accessibility standards (https://www.hhs.gov/web/section-508/making-files-accessible/checklist/pdf/index.html). Their complaints were based on failures reported by CommonLook. I am praying that these failures are not strictly speaking failures according to the HHS requirements since we cannot afford to re-remediate the scores of documents involved! But I am unsure about many of the alleged violations. What do you think?

Here are the client's comments with some thoughts of my own.
1. "Links do not have alt text". But the links have descriptive text, so why would the Link tag need "alt text"? That is, the structure is
<Link> (container)
descriptive text for the link (leaf)
Link-OBJR (leaf)
Why the need for an Alt Text on the <Link>? The only relevant HHS requirement I could find is 1.8 which reads "Do all URLs contain descriptive hyperlinks (i.e., avoid generic phrases like "Click here" and, instead, use phrases that let users know about the content of the linked page prior to selecting it)?"
2. "Lists are sometimes constructed without <Lbl> tag." I remember once asking in this listserv if <Lbl> is always required, e.g. when it is a meaningless dash or bullet, and being told that it is not a required element. Looking at the HHS requirement 5.1 now I am not so sure. It reads "Have lists been tagged completely, making use of all four of the following tags: L, LI, Lbl, and LBody tags?". But what is the effect (if any) of not having a <Lbl> element between the <LI> and the <LBody> as far as AT is concerned?
3. "Paths are not artifacted." Well, there are hundreds and hundreds of untagged path elements all of which are semantically void— spaces, lines, and so on. Making each an artifact seems to me pointless and exhausting. What difference does it made if these elements are not tagged at all since either way we want a voice reader to ignore them? And is it an HHS requirement in any event? I cannot find it.
4. "Document defines more than 1 H1." When I first started working with PDF accessibility I remember being told by PDF remediation experts that there is no explicit rule against multiple H1 headings in a document as long as the headings are nested correctly and do not skip a level (and of course are semantically correct, i.e. helpful.) Now rereading HHS requirement 3.3 I can see that it is _possible_ to construe it as stating that the title of a document must be the only H1 heading with other heading elements all pegged at lower levels. While one _could_ take it this way I am hoping that not all of you will insist that one _should_ take it this way! Any thoughts?
5. "Fonts are not embedded." I don't see that requirement anywhere in the HHS list, just that the choice of fonts be from the "recommended fonts" list. (See requirement 1.4.) It may or may not be best practice, but is it an HHS violation?

Thank you for your advice!

Alan Zaitchik
Center For Social Innovation