WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: CommonLook failures and HHS requirements

for

From: Metzessible
Date: Dec 23, 2017 12:08PM

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