WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: PDF U/A alternate description for links

for

From: Karen McCall
Date: Feb 14, 2023 3:53PM

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

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Steve Green
Sent: Tuesday, February 14, 2023 5:46 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] PDF U/A alternate description for links

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




-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Elizabeth Thomas
Sent: 14 February 2023 18:34
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: [WebAIM] PDF U/A alternate description for links





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