WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: PDF U/A alternate description for links

for

From: Elizabeth Thomas
Date: Feb 15, 2023 7:03AM

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