Ignore table of contents padding marks in Acrobat when reading PDF files

[Qchristensen]

Steps to reproduce:

Reported by an organisation in the NVDA user email group: https://nvda.groups.io/g/nvda/message/113359

1. Create a file in Word with a generated Table of Contents (using Word's table of contents feature. Use the standard default TOC type which uses ..... as a padding mark between each entry and its page number)
2. Export the file as a PDF file
3. Open the file in Acrobat (in fact this reproduced in most PDF readers / browser viewers)
4. Read the TOC

Actual behavior:

At step 5, reading the TOC, NVDA reads similar to:

Link heading dot, link one hundred dot, link 48 dot 1.

Expected behavior:

It would be good if these repeated dots weren't read, at least at the default punctuation level.

NVDA logs, crash dumps and other attachments:

System configuration

NVDA installed/portable/running from source:

NVDA version:

NVDA 2023.3 installed

Windows version:

Windows 11 (64-bit) Version: 22H2, Build: 22621.2715

Name and version of other software in use when reproducing the issue:

Adobe Acrobat Pro 2020, but also replicates in Foxit PDF reader version 12.1.1.15289, and browsers - I believe this is more to do with how and when NVDA reads multiple characters like this rather than the programs in use.

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

Have you tried any other versions of NVDA? If so, please report their behaviors.

If NVDA add-ons are disabled, is your problem still occurring?

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

[Qchristensen]

There are several workaround for this:

• From the document creation side, use a TOC template which does not add repeated dots as a padding character (there is one or you can customise it)
• From the user side, change the punctuation level

But as noted in that user group thread, this is a common way of presenting tables of contents and it would be useful if they were read out without extraneous information as the default.

[CyrilleB79]

Is the issue also present in other screen reader such as Jaws or Narrator?

[seanbudd]

Unfortunately this is a "can't fix" situation, the job of the screen reader is to read the text.

[CyrilleB79]

These lines of dots are here for presentation and, in the first place, it would be the job of the PDF converter to avoid these dots to be rendered as text in the PDF.

@seanbudd wrote:

Unfortunately this is a "can't fix" situation, the job of the screen reader is to read the text.

I would not be so categorical.
Narrator does not reads it with its default punctuation level.

A solution could be for example to create a new complex symbol consisting in 4 points (regexp = r".{4,}"), which is not reported at default lower punctuation level.

Reopening so that NV Access indicates if they could accept such workaround.

[Adriani90]

Reopening so that NV Access indicates if they could accept such workaround.

I second this. IN fact the community will definitely accept this workaround because it is annoying indeed to hear everytime the number of dots displayed on the screen. At least theere would be an option to suppress that announcement by choosing another level of punctuation.

Unfortunately this is a "can't fix" situation, the job of the screen reader is to read the text.

@seanbudd I wonder if you guys talked about this internally at all? I mean not every visible text on the screen makes always sense to be reported in any case. That's why we have different puncutation levels, different symbol reporting levels, etc.
It would be very appreciated if you give some more input on how you came to this decision before closing such issues.

Note that before closing such issues, it is important to test the behavior with other screen readers, especially when you make a general statement about screen readers.

[Adriani90]

These lines of dots are here for presentation and, in the first place, it would be the job of the PDF converter to avoid these dots to be rendered as text in the PDF.

That's not entirely true. Dots are also displayed in table of contents even in printed documents which makes it easier for sighted people to follow the line until the page numbers. So for sighted people it makes indeed sense to have these dots on the display, and even more for people who have a bit of vision ability.
I don't know how the printing mechanisms work in the backend of a pdf viewer, but I think it is not that trivial to present dots in another way having in mind that people want to print the documents as well. As far as I know from PDFs which are not fully accessible, if you are presenting stuff that's expected to be text as non text, you fail the accessibility tests.

[CyrilleB79]

These lines of dots are here for presentation and, in the first place, it would be the job of the PDF converter to avoid these dots to be rendered as text in the PDF.

That's not entirely true. Dots are also displayed in table of contents even in printed documents which makes it easier for sighted people to follow the line until the page numbers. So for sighted people it makes indeed sense to have these dots on the display, and even more for people who have a bit of vision ability.

Sorry, maybe my previous statement was not very clear. I mean:

These lines of dots are here only for visual presentation and, in the first place, it would be the job of the PDF converter to avoid these dots to be passedto ATs via the accessibility APIs. Though, I do not know if PDF specification has something equivalent to HTML where a text can be visually displayed, but hidden to screen readers.

[Adriani90]

On the topic about hiding content in PDFs but still displaying them visually, the PDF community is quite strict about this and doesn't like behavior like this:
https://community.adobe.com/t5/acrobat-discussions/how-to-force-acrobat-screen-reader-to-skip-ignore-an-entire-page/m-p/9744360

Indeed if you want to pass the accessibility tests, you have to provide an alt text for all non text elements.

[CyrilleB79]

@seanbudd, this issue is labeled "blocked/needs-product-decision".

Have you been able to discuss this at NV Access?
The complex symbol fix described in #15845 (comment) would be quite simple and should not cause undesirable side effects.

Thanks.

[seanbudd]

@CyrilleB79 - that solution seems appropriate