WebAIM - Web Accessibility In Mind

E-mail List Archives

CommonLook failures and HHS requirements

for

From: Alan Zaitchik
Date: Dec 21, 2017 7:53PM

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