Exit
  • Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
  • 한국 커뮤니티
0

Artifact table cell lines to comply with the wcag 2.1 standards

Community Beginner ,
Sep 13, 2019 Sep 13, 2019

I make a lot of pdf files with tables for a client and they should all be accessible. When i export the tables to PDF, all the cell lines convert to paths in the PDF Content panel- and this is not compliant with the wcag 2.1 standards. Is it possible to artifact all the lines in the cells when exporting to PDF. 

- Jakob.

3.2K
Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
People's Champ ,
Sep 13, 2019 Sep 13, 2019

If you're using the current version of Adobe InDesign (and it's built-in PDF export utility), there's no need to do this; tables export correctly and are compliant (in terms of borders/paths).

 

You might be confusing the different panels in Acrobat. Per the PDF/UA-1 accessibility standards (ISO 14289-1 https://www.iso.org/standard/64599.html), it's the Tags Panel that controls the accessibility through tags and structure (or reading order).

 

The Content Panel shows every computer object in the file, so yes, it would show the cell borders as paths. But the paths are not visible or tagged in the Tags Panel so they are, by default, artifacted and not recognized by assistive technologies (AT).

 

FYI, PDF files are evaluated for accessibility compliance with the PDF/UA-1 standard. WCAG was developed specifically for web content that is HTML-based, not PDF.

 

Although the 2 standards "harmonize" on the core principals of accessibility and many of the tags are similar, the file formats themselves are vastly different. Some people think of PDF/UA as "WCAG designed for PDFs" and they're not too far off with that comparison.

 

See the example below: when voiced by a screen reader, the table is read correctly without any "path" or <Figure> tags.

 

A table created in InDesign CC:2019

Sandbox Table_2019_Indy.png

 

The exported PDF in Acrobat's Tag Panel: no "path" or <Figure> tags.

Sandbox Table_2019_PDF.png

 

The exported PDF in Acrobat's Content Panel shows all elements in the PDF, including "path".

Sandbox Table_2019_PDF2.png

 

Hope this helps.

—Bevi Chagnon

Accessibility consultant

PubCom.com | Technologists for Accessible Design + Publishing

 

|    Bevi Chagnon   |  Designer, Trainer, & Technologist for Accessible Documents |
|    PubCom |    Classes & Books for Accessible InDesign, PDFs & MS Office |
Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jan 12, 2023 Jan 12, 2023
quote

WCAG was developed specifically for web content that is HTML-based, not PDF.


I was on the WCAG working group, and from WCAG 2.0 onwards, the standard is intended for all types of web content, not just HTML. The standard only describes the result and is technology-independent. Separate techniques documents explain how to achieve the standards in different technologies, including the  PDF Techniques for WCAG 2.0.

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
People's Champ ,
Jan 12, 2023 Jan 12, 2023

@yhoitink, I was on the WCAG 1 original working group, and am a former PDF programmer and HTML developer. I'm now on the PDF/UA ISO committee.

 

I'm attempting to clear up some misinformation about accessible PDFs.

 

There were many problems when WCAG claimed a while back that "WCAG is device neutral" and WCAG is the standard for all digital media regardless of whether it was HTML or not.

 

It was a catchy phrase that everyone repeated, without really thinking about the technologies involved.

 

PDF and Office files are independent document files that are very different from HTML in countless ways, but they still share the overriding goals of WCAG and POUR: make the content accessible. Document files require programming, which is a very different task from marking up HTML content with tags.

 

Same with EPUB files: although similar to HTML, they have their own properties and features — and their own EPUB standard for accessibility.

 

But there's a more important legal aspect when WCAG tried to define accessibility for a file format that was owned and maintained by another entity: Infringement of patents and copyright.

 

The PDF file format was initially developed by Adobe in the late 1980s and was released in the early 1990s. At that time, only Adobe brand software could create and read PDFs: it was a proprietary technology from start to finish.

 

Fast forward to 2008, when Adobe donated the PDF file format and its matching PDF standard (but not the Acrobat software) to the ISO to maintain it in the public interest. Several related events happened about the same time:

  • Other companies began to release PDF-writing and  PDF-reading software, so the industry is no longer wedded to Adobe Acrobat brand software.
  • The PDF Association was created to curate all of the different types of PDFs: office quality PDFs, press-quality PDFs, engineering PDFs, 3D PDFs, PDFs for the formal archival of information, accessible PDFs, and several more that are in development by the PDF Association. It also manages the development of the standards for these different types of PDFs.
  • The ISO formally created the ISO TC 171 SC 2 working group to develop the PDF standards, including PDF/UA for accessibility. The Secretariat for the working group is ANSI, and the appointed liason to the working group is the PDF Association — not WCAG/W3c/WAI. [Reference: https://www.iso.org/standard/64599.html and https://www.pdfa.org/about-us/]

 

Therefore, WCAG can't make up its own standard for accessible PDFs.

 

The reference cited above — PDF Techniques for WCAG 2.0. — has so many errors and missing requirements that WCAG should be embarrased for misleading the accessibility community. And it's grossly out of date. It cites Acrobat 9 (circa 2008 — before the first PDF/UA-1 standard was released in 2012) and Word 2010 (circa 2010, which lacked most of the tools needed for accessibility). And WCAG's revised PDF guidelines in WCAG 2.1 are not much better, although I note that the language suggesting that all PDFs follow WCAG has now been removed.

 

It's such shameful behavior and doesn't help either the publishing community or people with disabilities.

 

If any WCAG member wants to contribute to the PDF/UA standards, then join the PDF Association and the technical committee, and come work with us. Several of us on PDF/UA have WCAG backgrounds, and I can truthfully say that in most of our meetings the question "how does WCAG handle this" comes up. We use the goals of WCAG to produce "real" functional accessibility standards for PDFs.

 

And if you want to learn more about how to make accessible PDFs, then I welcome you into any of my classes and can give WCAG members a professional courtesy discount. Just contact me directly.

 

|    Bevi Chagnon   |  Designer, Trainer, & Technologist for Accessible Documents |
|    PubCom |    Classes & Books for Accessible InDesign, PDFs & MS Office |
Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Sep 14, 2019 Sep 14, 2019

Thanks Bevi, it's good to know that the screen reader reads the table correctly.

But even though the screen reader reads the file correctly, the pdf will not pass the PAC 3 checker and that is what my client wants. I can remediate the pdf file in Acrobat and artifact all the paths, but I wanted to know if there is a way to do this from InDesign. is there a script for this maybe?

All the Paths will not pass the PAC 3 checker.All the Paths will not pass the PAC 3 checker.

 

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
People's Champ ,
Sep 14, 2019 Sep 14, 2019

PAC3, CommonLook, and other accessibility checkers are created by commercial companies. There is no checker that is made by the ISO committee itself, which in my opion would be the defacto "one" opinion that would matter.

 

Although these companies sit on the ISO standards committee with me, we all at times interpret the standards slightly differently. There are several areas of PAC3 that are flagged as errors when, in my firm's opinion, they actually aren't and this is one.

 

The PDF/UA standard says all viable content must be in the tag tree, tagged with the appropriate tag, and in a logical reading order in the tag tree. The cell borders aren't in the tag tree for AT to access.

 

Checking the file with real screen reading software, the borders are not announced. Nor do they appear in the Order panel, either. These borders only appear in the  Content Panel which shows every single item in the document file, whether it's viable content or artifacted or neither.

 

In our shop, this is a "non-error" error. I'd prefer that PAC 3 give us a better feedback on these borders, something like:

  • Do the borders appear as <Figure> or "Path" in the tag tree?  If yes, then flag the error.
  • If the borders only appear as <Figure> or "Path" in the content panel and don't have the Artifact tag on them, then give a warning rather than an error, and recommend manually checking them for compliance.

 

Keep in mind that all of the accessibility checkers are not the standard itself, but merely someone's interpretation of the standard.

 

From a practioner's viewpoint...

If my client insisted on perfect compliance with PAC 3:

  • I would select all of the "Path"s in the Content panel and artifact them with a mouseclick.
  • "Gently" educate the client on this issue.
  • And ask the client why they decided on PAC 3 rather than CommonLook or Acrobat's built-in checker.

 

And in my shop, we use all 3 accessibility checkers as well as a checklist that has items not covered by any of them. None of the software checkers catch everything or evaluate the same items.

 

|    Bevi Chagnon   |  Designer, Trainer, & Technologist for Accessible Documents |
|    PubCom |    Classes & Books for Accessible InDesign, PDFs & MS Office |
Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
People's Champ ,
Sep 14, 2019 Sep 14, 2019

Quote: << is a way to do this from InDesign. is there a script for this maybe? >>

 

No, InDesign's PDF export utility is in control of this. Ideally, the PDF converter SHOULD be artifacting these borders so make a request for them to do this at http://www.indesign.uservoice.com

 

You might try a commercial plug-in for InDesign, Made To Tag, by Axaio Software (also on the ISO committee).

|    Bevi Chagnon   |  Designer, Trainer, & Technologist for Accessible Documents |
|    PubCom |    Classes & Books for Accessible InDesign, PDFs & MS Office |
Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jan 11, 2023 Jan 11, 2023

Hi Bevi

I appreciate this thread relates to InDesign and dates back to 2019, but I have been experiencing a similar issue (ongoing) with numerous PDFs with tables generated from Word using the Acrobat plugin, where paths show in the tags tree and then error in PAC for PDF/UA compliance. Despite searching for and using various preflight 'fixes' in Acrobat Pro (2019 and 2022 versions), these paths cannot seem to be changed to artifact. Are you aware of a solution to this issue that can be applied natively in Acrobat? I was under the impression this could be done in a later version of Acrobat, but I can't see how/where. Is the only solution to use Commonlook or similar as a plugin to Acrobat to address this? I've attached a couple screen grabs to illustrate. Thanks - Paul

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
People's Champ ,
Jan 11, 2023 Jan 11, 2023

@Paul-BT, your screen captures look like an older version of PDF Maker was used.

<P>PathPathPathPath was a bug in the utility that was corrected about a year ago.

 

PDF Maker is part of Acrobat Standard or Pro. When Acrobat is installed, it adds the PDF Maker plug-in to MS Office applications. So if you want the latest PDF Maker, you must update Acrobat itself.

 

Check your vesion of Acrobat (Help / About Acrobat) against Adobe's release list:

https://helpx.adobe.com/acrobat/release-note/release-notes-acrobat-reader.html

 

Note that the newest release was just a few days ago (January 2023) and has a revamped user interface. Many don't like the layout change, but you can revert back to the traditional interface from the File menu (now known as the hamburger menu in the upper left).  But PDF Maker isn't affected by which interface you use.  https://helpx.adobe.com/acrobat/using/whats-new/2023-january.html

 

Update to a more recent Acrobat and I expect that the <P>PathPathPath problem will be gone!

 

As an added measure to take, run Acrobat Pro's Preflight to identify and correct many of these errors (and others).

  1. From the Standards tool menu, select Preflight:

    Preflight-PDFua_01.png
  2. In the next menu, choose:
    • PDF Standards from the top.
    • Profiles thumbtab.
    • Fix Problems in the PDF/UA section.
    • Then click Analyze and fix.
      Preflight-PDFua_02.png

Hope this helps.

|    Bevi Chagnon   |  Designer, Trainer, & Technologist for Accessible Documents |
|    PubCom |    Classes & Books for Accessible InDesign, PDFs & MS Office |
Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jan 12, 2023 Jan 12, 2023

Hi Bevi

 

Typically, our IT department had rolled out a later version of Acrobat yesterday and I hadn't created a new PDF using the PDF Maker at the point I posted. Having just created a new PDF from an old file that contained a large portion of tables, the '<P>PathPathPathPath' issue has indeed been resolved!

 

I have been aware of the Preflight 'Fix' option for quite some time and have used it extensively with both the 2015 Profiles and Standards options. Whilst they do fix a lot of potential issues, neither option seems to fix the Path issues on older/existing PDF files that could be remedied without having to resort to the source file and remake. One of my files has 1000+ paths, so would be too time consuming to change to artifact in the content panel. 

 

I have tested PDFs with NVDA and the paths don't get announced anyway, so I assume it perhaps doesn't warrant spending time fixing an issue that isn't really an issue? If that's the case, it's a shame PAC 3/2021 doesn't ignore them if they don't present a PDF/UA failure for assistive technologies.

 

Thanks again - Paul

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
People's Champ ,
Jan 12, 2023 Jan 12, 2023
quote

I have tested PDFs with NVDA and the paths don't get announced anyway, so I assume it perhaps doesn't warrant spending time fixing an issue that isn't really an issue? If that's the case, it's a shame PAC 3/2021 doesn't ignore them if they don't present a PDF/UA failure for assistive technologies.

By @Paul-BT

 

@Paul-BT, remember that the companies that own the PDF testing software or services have something else to sell you — software or services to correct the errors they find.

 

The same programmers that write PAC also create Axes4 and have remediation services. The same company that creates PDF Validator also creates CommonLook and has remediation services.

 

If you've thoroughly tested your files with at least NVDA and JAWS, and find that the PathPathPath is not voiced, then I think you're safe to let the file go public.  But do check it every year or so: the PDF/UA standard itself is being updated and assistive technologies will evolve afterwards. Those PathPathPaths could very well be vocalized later down the road.

 

One workaround we use at our shop: when we have a legacy PDF from an older Word.docx that's filled with PathPathPath, we open the Word file in the latest version of Word 365 and re-export a new PDF using the latest PDF Maker or the built-in MS Word File / Save As / PDF conversion utility.

 

That usually gets rid of any residual PathPathPath crapahola in the new PDF, not just around table cells, but also in hyperlink underlines and borders around text boxes and paragraphs. We find it's often the fastest way to correct an older PDF.

 

|    Bevi Chagnon   |  Designer, Trainer, & Technologist for Accessible Documents |
|    PubCom |    Classes & Books for Accessible InDesign, PDFs & MS Office |
Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jan 13, 2023 Jan 13, 2023

@Bevi Chagnon - PubCom.com - Thanks again. I have had similar thoughts about the software and services from these companies, so it's good to get your confirmation I wasn't wrong. Sadly, we don't have access to Jaws where I work, only NVDA, but we do have 365 and yes, I was thinking that the simplest method to remedy the PathPathPath issue would indeed be to create new PDFs from the older files. Good to know I'm on the right 'path'! (ahem)

Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
People's Champ ,
Jan 13, 2023 Jan 13, 2023
LATEST

@Paul-BT 

Just make sure that the "path" you're on doesn't get artifacted!

<grin>

|    Bevi Chagnon   |  Designer, Trainer, & Technologist for Accessible Documents |
|    PubCom |    Classes & Books for Accessible InDesign, PDFs & MS Office |
Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines