Probably. In general I find the XI accessibility checker to be superior to the one in X, but neither is very good and by no means should be relied upon for anything more than a quick first check. The two versions of the PDF Accessibility Checker (PAC) from the Swiss foundation Access for All are the best available, and both are free. PAC 1.3 (http://www.access-for-all.ch/en/pdf-lab/pdf-accessibility-checker-pac/dl132.html) checks for WCAG 2.0 compliance, PAC 2.0 (http://www.access-for-all.ch/en/pdf-lab/pdf-accessibility-checker-pac.html) checks for PDF/UA (i.e. ISO 14289). Keep in mind though that many accessibility checks can not be automated. Any PDF accessibility checker must be used in combination with knowledgeable human inspection and corrective action.
Hope this helps.
a 'C' student
HI C, this forum keeps chopping off my response so I'll abbreviate: I use Adobe XI, PAC 1.3, PAC 2.0, CommonLook structural/508 checkers, and manual inspection--the deal is that one member in our 508 team really takes to heart that red flag even though as the other team member has it and I don't but his check is the last check run. If I could get definite word that the red flag is officially Adobe deprecated we could put it aside (aesthetically it does look wrong but I'm not convinced it is always there--no location pointer accompanies that error)
Adobe told me that unless I purchased a developer SDK license from Best Buy (for $1,500 I think) and then called the number printed on the back no other specialist would talk to me about that issue. That isn't going to happen.
I admit I really don't understand some of the PD/UA calls--our reference screen reader JAWS will not be links aware if al text is put within the links tag itself, but PAC 2.0 and CL's PDF/UA seem to insist on that--but placing the alt text in that link tag short-circuits JAWS accessibility link parsing. Other meta and PDF identifiers that are being requested and the Note/reference IDs--I don't get where they are supposed to go. Our shop is not on a PDF/UA standard, I've read statements from Acrobat that they philosophically support it 1000 percent but I think I also came across a statement that they have no immediate plans to incorporate it in their 508 tools--and so when you use Acrobat to tag a document its own checker passes what PDF/UA checkers fail. But that's another discussion.
Ah. I think I understand. Yes, PDF/UA and consequently PAC 2 require that link tags have alt text. As I recall WCAG 2.0 discourages link tag alt text, and PAC 1.3 flags it as an error – for the very reasons that you point out, it hides the link contents from some AT.
There is a way to make all the accessibility checkers happy – but it is a bit of a pain using current tools. A careful reading of the Matterhorn Protocol compliance criteria for PDF/UA reveals that link tag alt text should be placed in the tag’s Contents key rather than the Alternative Text field. In the tag properties dialog, click the “Edit Tag …” button, then drill down through “Tag Element”, “/K [Array]”, “ <<Dictionary>>”, and “/Obj <<Dictionary>>”, select the latter, then click “New Item” and add:
Value: link alt text goes here
Value Type: String
If you google “PDF/UA Reference Suite” you will find documents with lots of example links tagged this way.
This should make JAWS happy as well but I have not tested it – I test with NVDA when necessary but prefer screen reader emulators.
If you are dealing with a lot of links this will be time consuming. The upcoming version of CommonLook, renamed PDF Global Access, will reportedly automate the process, but will be pricey.
An alternative, since you are not on a PDF/UA standard, is to make sure your links make sense in context, and forego the alt text. If your colleague does not like the red flag advise him or her to test with Acrobat XI and PAC 1.3, not X and 2 respectively.
C, this is fascinating! I will try this myself and see if JAWS reads it--with and without the parallel placement in alt text--and then transmit the results 508 POC team head. We aren't on PDF/UA (yet) but this really explains the conundrum if it works.
I have Global Access--they've scrapped the GUI of CommonLook 4--all those glyphs and the CL preview are gone--the preview is now the document itself--so it is much more Acrobat-like though I still find the Acrobat GUI more intuitive--I will ask the trainer of my upcoming session about the automated process.
Our policies force alt text since many of our links are internal links to bibliographic references and our policy stands that citations (say a superscript of 2) to bibliographical references have to have alternate text--"(refer to reference 2)"--so that alternate text now has to be positioned within the link at some point--because our policy is also not to eliminate live links that might be useful for the originally intended sighted end user.
My colleague only has X and doesn't want to give up that test (it doesn't look right to see those nests) but CL GA's tag search very easily permits you to search for the type of nests where that error occurs--if you do a search for a StyleSpan nested inside a Span for example then when you fix that you might also find that the top Span has alt text -- by bringing up the content of the StyleSpan tag to the Span tag you've solved that issue.
I will try that text in Contents key w/JAWs and post the results here.
What is the Matterhorn Protocol?
I think I figured out the method you were suggesting but JAWs pays no attention to any alt text entered that way. PAC 2.0 also ignores that alt text. Here is the menu of my test link paragraph properties--the contents is there as the Key, the value (alt text goes here) is there as a string but not doing anything for PAC 2.0 checker or JAWS:
I dunno man, they've stuck the content pane entries within a /Border [Array]--it isn't freestanding within the /Obj <<Dictionary>> what's that all about? Do you have access to the file itself? Could you send it to me at firstname.lastname@example.org? or email@example.com
what is the Matterhorn Protocol? sounds like a Clint Eastwood movie version of a Robert Ludlum novel circa 1978
The Contents key as at the same level as /Border [Array], both are under /Obj <<Dictionary>>. The Matterhorn Protocol (cool name, I have not bothered to learn the etymology) provides compliance criteria for PDFs to meet the PDF/UA standard. You can find it here http://www.pdfa.org/wp-content/uploads/2014/06/MatterhornProtocol_1-02.pdf, or with the other excellent examples that make up the PDF/UA Reference suite here PDF/UA Reference Suite | PDF Association.
I love that old Eastwood movie, by the way.
- Ah. So it is. Those little plus signs confoozed me. But then the prior screen shot of my test may or may not show a valid procedure w/negative JAWS recognition, dcpending on whether renesting that within the top elements starting with /K [Array] then down to  <<Dictionary>> & etc. has JAWS respond.
But even if it does, unless the values can at some point be entered via pre-potted Adobe Acrobat/CL 508-remediation tool fields we probably won’t adopt. We have a lot of internal links that require alt text in some files and entering a nested set of values from /K [Array] down to  <<Dictionary>> and then onto the /Contents –alt text pairing is too cumbersome. Still, we know this on the horizon.
Thanks for the links, I’ll check them out, retest, and we’ll see where we are down the road.