E-mail List Archives

Search E-mail List Archives for

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

From: Elizabeth Thomas
Date: Tue, Feb 14 2023 11:34AM
Subject: PDF U/A alternate description for links
No previous message | Next message →

I have a question about alternate descriptions for links and was unable to find an answer online; I thought someone on this list must know the answer.
Why does PDF U/A require alternate descriptions for links? If my link is human readable, and makes sense out of context, why do I also need an alternate description for that link? It seems like the rule should only apply to badly written links or full URLs.
For example, if the link text in my PDF is the web page title, and that text is a content object that is a child of the link, won't technologies associate that text with the link? And won't assistive technologies, like a screen reader, read that text when they encounter the link?
Are there some technologies that don't correctly read the associated text when they encounter a link? Is that what the standard is addressing?
I know how to automate adding the alternate descriptions for links in a PDF, but it seems unnecessary (unless the links are full URLs or don't describe the link destination when taken out of context). PAC 3 always flags this issue, but I don't really understand why it's in the guidelines/standards.
Thanks in advance.
-Elizabeth Thomas
Digital Accessibility Specialist
New Jersey Department of Education

From: Steve Green
Date: Tue, Feb 14 2023 3:45PM
Subject: Re: PDF U/A alternate description for links
← Previous message | Next message →

It's certainly an annoying failure because it happens with every link when you create a PDF from Word, regardless of whether you use the Save As PDF option or PDFMaker.



It's worth nothing that the error message does not relate to the Link tag (which contains the link text but not the URL). It relates to the link annotation, which is the clickable area that is associated with the URL – this is not part of the Tags tree, but you can see it in the Content panel.



The Link-OBJR tag creates a relationship between the Link tag and the link annotation and is created automatically during the Word-to-PDF export process. However, not all applications create this relationship and you have to create it manually if you add links in Acrobat.



PDF/UA does not provide a rationale for this requirement, and I can only imagine that there might be some PDF reader applications that do not recognise the relationship that the Link-OBJR tag creates. That said, I have never seen any adverse effect with any PDF reader or assistive technology I have tested with.



I have done some tests with PAC 2021 and the Commonlook PDF Validator, which is much more thorough.



PAC 2021

* Before you apply any fixes it reports failures of "Alternative description missing for an annotation".
* If you add either Alternate Text or the Contents attribute, the error clears.



Commonlook PDF Validator

* Before you apply any fixes it reports failures of "Parent tag of Link annotation doesn't define the Alt attribute” and “Link Annotation doesn't define the Contents attribute”.
* If you add Alternate Text it doesn't report a failure, but it reports a warning of “Link Annotation doesn't define the Contents attribute”.
* If you add the Contents attribute it doesn't report a failure, but it reports a warning of “Parent tag of Link annotation doesn't define the Alt attribute”.

Steve Green
Managing Director
Test Partners Ltd

From: Karen McCall
Date: Tue, Feb 14 2023 3:53PM
Subject: Re: PDF U/A alternate description for links
← Previous message | Next message →

And it gets "worse" when an automated tool tells you that the Link tag in a TOC needs Alt Text. First, if you add Alt Text to that Link tag, the concept of the TOC (text, dot leaders and page number) is lost in favour of the Alt Text on the link even though the screen readers read the TOCIs.

And footnotes or endnotes shouldn't have Alt Text because they are references!

I ignore any automated tool flagging Alt Text on links because: if It is one of my documents, I know I've done things correctly and I've double checked the Tags Tree; and if I am remediating a document, I've gone down the Tags Tree and checked that both parts of the link are there.

This is why we manually test and why defining an accessible PDF or any other document by the results of automated tools is like chasing the wind. 😊

Cheers, Karen

From: Elizabeth Thomas
Date: Wed, Feb 15 2023 7:03AM
Subject: Re: PDF U/A alternate description for links
← Previous message | Next message →

Thanks Steve and Karen for your explanations. I have seen conflicting explanations from experts online on what the error means and how to fix it (e.g., add alt text to the link versus modifying the dictionary for the link in the PDF), so I really appreciate your responses. I have always ignored this error as a false flag, but wasn't sure if I was then creating a barrier for some users by doing so. So it sounds like there is no known negative impact for people using assistive technologies if I ignore this error.
Thanks for your expertise. PDFs are so fun (not!).
-Elizabeth Thomas

Sent from my iPhone

> On Feb 14, 2023, at 5:53 PM, Karen McCall < = EMAIL ADDRESS REMOVED = > wrote:
>
> And it gets "worse" when an automated tool tells you that the Link tag in a TOC needs Alt Text. First, if you add Alt Text to that Link tag, the concept of the TOC (text, dot leaders and page number) is lost in favour of the Alt Text on the link even though the screen readers read the TOCIs.
>
> And footnotes or endnotes shouldn't have Alt Text because they are references!
>
> I ignore any automated tool flagging Alt Text on links because: if It is one of my documents, I know I've done things correctly and I've double checked the Tags Tree; and if I am remediating a document, I've gone down the Tags Tree and checked that both parts of the link are there.
>
> This is why we manually test and why defining an accessible PDF or any other document by the results of automated tools is like chasing the wind. 😊
>
> Cheers, Karen
>
>

From: chagnon
Date: Wed, Feb 15 2023 7:34AM
Subject: Re: PDF U/A alternate description for links
← Previous message | Next message →

This is an error in PDF/UA, and as a member of the ISO committee that writes PDF/UA, I believe that it's the type of requirement that committee members don't fully understand. (The original standard was written before I joined the committee.)

Software checkers like PAC, Adobe's accessibility checker, CommonLook, etc. can only determine yes/no situations, such as "yes" the link has Alt Text or "no" it doesn't. It takes a human being to determine whether it's needed or not, not software.

Several of the software remediation tools flag missing Alt Text as an error, and then provide the software solution — which just picks up the hyperlink text and repeats it as Alt Text. How is that supposed to benefit the end user? It's repeating the same information but without the user controls of regular text: Screen readers clip the user's control when reading Alt Text.

We use PAC 3 to flag hyperlinks and then manually check them to determine if Alt Text is warranted. Definitely do not put Alt Text on TOCs because it clips the user's control over what they hear and how it's presented to them. Functionality is diminished.

We need to do better.

— — —
Bevi Chagnon | Designer, Accessibility Technician | = EMAIL ADDRESS REMOVED =
— — —
PubCom: Technologists for Accessible Design + Publishing
consulting • training • development • design • sec. 508 services
Upcoming classes at www.PubCom.com/classes
— — —
Latest blog-newsletter – Simple Guide to Writing Alt-Text

From: Christine Hogenkamp
Date: Wed, Feb 15 2023 2:38PM
Subject: Re: PDF U/A alternate description for links
← Previous message | No next message

Hi Elizabeth,

For whatever it's worth, when making accessible PDFs in InDesign, my team
noticed that our TOC links were announced as "Blank" using NVDA unless the
Alt text box was filled in the Hyperlinks panel in InDesign. We can perhaps
assume that other document software might be accidentally making similar
errors when exporting to PDF, so the alt text box may exist and be required
by PAC and/or PDF/UA as a way to ensure the text is "seen" by screen
reader, as a fallback?

I have definitely struggled to understand the relationship between
Link-OBJR and annotations, it may be there are some document programs that
use annotations to create links in a way that may not be compatible with
screen reader software, or maybe does so imperfectly, either due to
software code or user error in formatting the document.

One day I'd love for Adobe to take proper responsibility for the PDF file
format in relation to accessible PDFs and update their software to explain
these elements more clearly or at least put in more dedicated
panels/wizards to help prevent user error. Oh well, I can always dream ha
ha!

*x*
*Christine Hogenkamp (She, Her)*
Front-end Developer
ContextCreative.com <http://contextcreative.com/>;

>
>