difference between accessibility checker and pdf/ua checker

Report · Dec 20, 2018

Hi there.

I'm using Windows, and I have Acrobat Pro DC 2019.010.20064.

I've noticed that there are 2 distinct accessibility checkers in Acrobat, and I'm wondering if someone can explain what the difference is. One of them you get to by going to More Tools -> Accessibility -> Full Check. The other you get to by going to More Tools -> Print Production -> Preflight -> PDF/UA compliance.

Thanks,

Dave

Report · Dec 26, 2018

The difference is that each one checks to a different standard. Where the Acrobat Accessibility Checker loosely checks to the WCAG 2.0 standard, PDF/UA or "Universal Accessibility" is based on the Matterhorn Protocol and checks to a more granular level. You'll almost always find more errors checking for PDF/UA due to the added requirements.

Report · Jan 17, 2019

Disagree with some of that explanation.

The PDF Accessibility Checker (Tools/Accessibility/Full Check) since Acrobat CC:2018 has been based on PDF/UA-1, not on WCAG 1 and 2 as in previous versions of Acrobat. You can see this in the specific items it's checking: List structure, for example, is different in PDF than in HTML/WCAG. So are links, page/document content structure, and several other items.

So it is a valid checker for PDF/UA-1 compliance. But I said a "valid" checker, not a complete checker.

The Preflight checker for PDF/UA-1 is a mash-up of tests. Note that it is found in a tool panel labeled "Print Production," and I know of no standard that requires print-quality PDFs be digitally accessible for assistive technologies.

So although I agree that the Preflight checker's test is more "granular," I really call it "insanely granular with stuff that has no bearing on accessibility and is a waste of everyone's time."

Like checking the color space: is it RGB? CMYK? LAB? Does this really matter to someone who is blind or anyone else with a disability using assistive technologies? How about bitmapped/raster images vs. vectors? Resolution of graphics? Trapping? Bleeds, crop marks, trim boxes, printers marks...all of these are print-related concerns, not for accessibility.

So some of those "added requirements" aren't requirements at all. They're someone's opinion, or a suggested "best practice" at best.

Lastly, the Matterhorn Protocol is nothing more than a working test of theories and examples by members of the PDF Association. It is not a law, standard, or anything else that's required to be followed. Just a draft or test of what makes an electronic document accessible. Or COULD make a document accessible--some ideas there don't last long. Since most members of the ISO committee that writes the PDF/UA standard are also members of the PDF Association and work on the Matterhorn Protocol, you are correct to assume that the theories tested in Matterhorn do make their way into the ISO PDF/UA standard.

But only us geeks and geekettes who work on the standards should be concerned about Matterhorn.

If your job is to make accessible documents, then you should know, master, and understand PDF/UA and possibly some WCAG that's appropriate. But not Matterhorn because it's not a standard authorized by an authorizing entity (like the ISO), and it's certainly not mandated by any law anywhere.

Bottom line: neither tool does the job we need it to do.

Each misses critical accessibility points. And one tool has crapahola in it than is not needed for the standard; this confuses users and obfuscates the real critical issues we should be working on.

Suggested Solution: (and feature request for you to submit to Adobe's Acrobat team, Chad!):

Merge the Print/Preflight checker into the Accessibility panel's checker, and migrate only the checkers that make sense for accessibility and PDF/UA-1 (and forthcoming PDF/UA-2). Nix the resolution, color space, etc. stuff. (And seriously, nothing for accessibility should be under tools labeled "Print.")
Beef up the Accessibility checker so that it assesses more items than its current version does (which will mostly happen when A is done, but there's more to check).
The checker must adhere to the standard: that is, don't leave anything out. But also don't add in anything that's not in the standard. Add-ins are NOT what has been agreed to by the ISO Committee; they are merely someone's opinion or a government agency's idea of what would be nice, or a software company's suggestion because they've developed a tool to fix the problem that they identify is a problem.
And don't jump the standard! The PDF/UA-2 standard isn't even completed yet, let alone submitted to the ISO and approved for publication by ISO. So don't put in half-baked non-standard stuff into a checker. Standards first, then the checkers, authoring software, assistive technologies, etc. based on the standards. Standards first.

Apologies for the rant. Can you tell that I'm in near-daily meetings about this stuff? Gotta getta life.

Report · Jan 18, 2019

I/we appreciate you taking the time to respond with such detail Bevi 😉 Although I'd have to disagree on a few of those points, I don't think it's beneficial to do so here. We'll have to grab a beer or six next time we're together 😉

I was simply trying to distill things down for the OP because it is absolutely confusing. The idea of standards in accessibility right now is the number one point of confusion for many users. The reality is that currently Acrobat doesn't check to any one specific standard 100%, not even close actually. The PAC 3.0 checker is quite good but overkill if your target is the WCAG standard. The Acrobat Accessibility Checker, doesn't go far enough however. So the reality is that you can use a checker but will need to do additional work to the file for full compliance that isn't checked by Acrobat. The Commonlook Validator which is free promises to check to a number of standards, but even that checker produces false positives on a consistent basis and is not exactly friendly to interpret the errors that you do get.

Anyway, I think the OP got more than they bargained for on this one 😉 but hopefully it answers their question 😉

Report · Jun 02, 2020

I agree with Bevi, We probabaly need to take a practical approach. Adobe has the overall capability in creating content, editing and testing. PAC3 is only for testing and checks syntax. WCAG includes semantics. Multiple tools do things differently but we need to decide if anyone wants to spend a lot of time to make certain elements right when the object is accessibility that is mainly screen reader. Most of the USA laws recommend WCAG 2.0/2.1 standards. WCAG is comprehensive!

Report · Jun 02, 2020

agree

Report · Jun 02, 2020

"USA laws recommend WCAG 2.0/2.1". Yep. So, if you know that your users are all USA-based, and that you will only ever be held accountable to USA rules, you're good to go by conforming to WCAG. But the world does not end at USA borders. If your users might include some outside the USA, most will look to PDF/UA - the offcial world-wide standard for PDF universal accessiblity. And, really, there is no reason besides a bit of inconvenience not to conform to both WCAG and PDF/UA. Each includes a few good things that the other leaves out, and in no case do the two contradict. So - really no reason to chose between the two.

Report · Jun 02, 2020

Quote: "USA laws recommend WCAG 2.0/2.1".

Not quite. In the 2017 Sec. 508 Refresh, language was kind of murky about which standard to use. PDF/UA-1 (ISO 14289-1-2016) is referenced in "702 Incorporation by Reference," (part 702.3 specifically) and in part 504.2.2 PDF Export. Since these references were buried amid the deep and many WCAG references, they were not clear enough guidance from the US Access Board.

HOWEVER, the Access Board reaffirmed its support of PDF/UA-1 for accessible PDF documents in this announcement last year (2019):

504.2.2 PDF Export. Authoring tools capable of exporting PDF files that conform to ISO 32000-1:2008 (PDF 1.7) shall also be capable of exporting PDF files that conform to ANSI/AIIM/ISO 14289-1:2016 (PDF/UA-1) (incorporated by reference, see 702.3.1). (Source: Federal Register)

And further clarified with this statement from the Access Board:

"[Essentially], PDF/UA is required (as an option) for software that can create *modern and good* PDFs," said Bruce Bailey, Accessibility IT specialist at the US Access Board.

See:

https://www.pdfa.org/us-access-board-affirms-pdf-ua-required-for-modern-pdf-software/?highlight=acce..., and

Appendix C to Part 1194 – Functional Performance Criteria and Technical Requirements, specifically part 504 Authoring Tools at https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/fi...

No doubt about it: use PDF/UA-1 for PDF document files. So says the US Access Board.

And FYI, the ISO PDF standards committee does evaluate WCAG guidelines and tries to harmonize them when possible with PDF/UA-1 guidelines. Hence, why audio/video content defaults to WCAG standards; no need for PDF/UA to reinvent the wheel for a/v.

But in other areas, like footnotes and lists, we take a cue from WCAG but retool the guidelines for PDFs, which are a very different type of file from HTML.