Skip to main content
J
jakob_diversa
Participant
September 14, 2019
Question

Artifact table cell lines to comply with the wcag 2.1 standards

  • September 14, 2019
  • 2 replies
  • 3462 views

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.

    This topic has been closed for replies.

    2 replies

    J
    jakob_diversaAuthor
    Participant
    September 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?

     

    Bevi Chagnon - PubCom.com
    Bevi Chagnon - PubCom.com
    Legend
    September 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.

     

    |&nbsp;&nbsp;&nbsp;&nbsp;Bevi Chagnon &nbsp;&nbsp;|&nbsp;&nbsp;Designer, Trainer, &amp; Technologist for Accessible Documents ||&nbsp;&nbsp;&nbsp;&nbsp;PubCom |&nbsp;&nbsp;&nbsp;&nbsp;Classes &amp; Books for Accessible InDesign, PDFs &amp; MS Office |
    Bevi Chagnon - PubCom.com
    Bevi Chagnon - PubCom.com
    Legend
    September 14, 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

     

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

     

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

     

     

    Hope this helps.

    —Bevi Chagnon

    Accessibility consultant

    PubCom.com | Technologists for Accessible Design + Publishing

     

    |&nbsp;&nbsp;&nbsp;&nbsp;Bevi Chagnon &nbsp;&nbsp;|&nbsp;&nbsp;Designer, Trainer, &amp; Technologist for Accessible Documents ||&nbsp;&nbsp;&nbsp;&nbsp;PubCom |&nbsp;&nbsp;&nbsp;&nbsp;Classes &amp; Books for Accessible InDesign, PDFs &amp; MS Office |
    yhoitink
    yhoitink
    Known Participant
    January 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.

    Bevi Chagnon - PubCom.com
    Bevi Chagnon - PubCom.com
    Legend
    January 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.

     

    |&nbsp;&nbsp;&nbsp;&nbsp;Bevi Chagnon &nbsp;&nbsp;|&nbsp;&nbsp;Designer, Trainer, &amp; Technologist for Accessible Documents ||&nbsp;&nbsp;&nbsp;&nbsp;PubCom |&nbsp;&nbsp;&nbsp;&nbsp;Classes &amp; Books for Accessible InDesign, PDFs &amp; MS Office |
    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices