E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 3 (In chronological order)

From: Alan Zaitchik
Date: Thu, Dec 21 2017 7:53PM
Subject: CommonLook failures and HHS requirements
No previous message | Next message →

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

From: Chagnon | PubCom
Date: Thu, Dec 21 2017 10:44PM
Subject: Re: CommonLook failures and HHS requirements
← Previous message | Next message →

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

From: Metzessible
Date: Sat, Dec 23 2017 12:08PM
Subject: Re: CommonLook failures and HHS requirements
← Previous message | No next message

Definitely take Bevi's advice about checking that contract you signed about
whether or not you must follow the HHS rules or if it's Section 508 (or
worse, both). The HHS rules a may be extremely outdated and ineffective for
accessibility, but if your procurement team signed agreed to them, you're
on the hook. In the future, it's best to advise your procurement team to
only approve documents for 508, as the HHS guidelines are ridiculous and
costly. For one thing, the font requirements in HHS guidelines will be
incredibly difficult to comply with if you're dealing with scanned
documents.

Now, to answer some of your questions, you use a label tag to provide more
semantic value to the list. Unless you're following pdfua, there isn't a
hard requirement for them to exist. However, omitting them means the <L>
tag will default to an unordered list. Any ordered list will be treated as
an unordered list without a ListNumbering attribute to distinguish it.
Unless you're making your documents pdfua however, there's no guarantee
screen readers will reliably notice that anyway. Another problem with
omitting label tags is that the content in the list body tag will include
the glyph or character representing the label, so that gets announced.
Since many bullets are actually fonts, you could end up with a bunch of 'n'
characters (or whatever dingbat character) concatenating the text.

As for the alt text for links, you need to remember that the link is
created by using a physical hotspot (I'm dumbing this down a bit) and
creating a relationship with the text it represents. That's what the
link-objr tag is for. Because it's not text, the link-objr is non-text
content, which means it requires alternative representation.

As for paths, the purpose of tagging a document is to provide a stylistic
representation of the meaning of the layout of the content. By assigning
the type of artifact each path is (layout, pagination, background, or
page), you are structuring the document to represent the layout. Otherwise
they might interrupt the logical reading order.

In not officially recommending this, but if you are only seeking compliance
and don't care about the quality of your work that your name is on, the
easiest solution is to just create a tag and choose Find>Artifact until you
obtain an entire list of artifacts in a document and blanket tag them with
an arbitrary artifact. Of course, doing this means you don't care about
your reputation as providing anything better than anybody else. But that
might prove to be job security for those of us that do quality work.

Anyway, check that contract. Not all agencies add that provision, and they
include it as scope creep during remediation because CommonLook can check
for it. If it's not a requirement, you can legally challenge them on it.
But those things you mentioned will be required anyway.

Best of luck!

Jon

On Fri, Dec 22, 2017 at 12:44 AM Chagnon | PubCom < = EMAIL ADDRESS REMOVED = >
wrote:

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