1780375 - Text in annotations is not accessible

Status: VERIFIED FIXED

(Firefox :: PDF Viewer, defect, P1)

Description

[Calixte Denizet (:calixte)]

A pdf can contain some annotations with some text but this one is not accessible from a screen reader.

Comment 1

[Marco Castelluccio [:marco]]

From Jamie's comment in bug 1777257, I guess we can consider this S2.

Comment 2

[Calixte Denizet (:calixte)]

More generally I think we must "attach" annotations to some text nodes in the text layer in using an aria-owns like we do for newly created annotations:
https://github.com/mozilla/pdf.js/commit/624b26e1de58828f2c4be08f656dc395c018fd39#diff-660c5961c3eab2b03e7a0ab7766be0d25e2e040c2423cc663297c830911264b7R447
This way annotations are visible in the text flow.
The second thing to do is to extract the text content from an annotation and then create a text node in annotation container.

Comment 3

[Calixte Denizet (:calixte)]

But aria-owns need to have some element ids and we recently get rid of them:
https://github.com/mozilla/pdf.js/pull/15099

A solution could be to generate a unique prefix for the ids in using for example:
https://developer.mozilla.org/en-US/docs/Web/API/Crypto/randomUUID

which should avoid any potential issue with the anchors (at least the probability to have a valid id in an url is very low).
:Snuffleupagus, what do you think ? Can you imagine an other way to "insert" the annotations in the text stream ?

Comment 4

[Jonas Jenwald [:Snuffleupagus]]

(In reply to Calixte Denizet (:calixte) from comment #3)

A solution could be to generate a unique prefix for the ids in using for example:
https://developer.mozilla.org/en-US/docs/Web/API/Crypto/randomUUID

According to https://developer.mozilla.org/en-US/docs/Web/API/Crypto/randomUUID#browser_compatibility that functionality is new enough that cross-browser support isn't great. Obviously that doesn't really matter for the Firefox PDF Viewer, but will require "defensive" code to not outright break in older browsers (given the generic PDF.js library).

which should avoid any potential issue with the anchors (at least the probability to have a valid id in an url is very low).
:Snuffleupagus, what do you think ? Can you imagine an other way to "insert" the annotations in the text stream ?

Given how we render Annotations, by including them in the regular OperatorList, could something similar be done (optionally) for the textLayer as well for the Annotation-types where that makes sense?
Obviously I'm not entirely sure if it's generally desirable to "extend" the textLayer with Annotation-data in that way, but it might be the overall simplest solution if it actually works. The caveat here is that'd only really help for Annotations that already exist in the PDF document and which have suitable /AP-entries.

Comment 5

[Calixte Denizet (:calixte)]

If I understand correctly, right now only the text layer is "visible" for blind people or maybe a screen reader will read the text layer and then announce the containers for annotation if they have some aria data.
So for example, if we've a text (in text layer) followed by a textfield (in the annotation layer), then for blind people there are no link between both elements when there is one for the others.
So my idea is to aria-role the span and the input, even if they don't belong to the same layer, in order to let the screen reader guesses that the input follows the text.

About annotations containing some text (with an /AP entry), my idea was to call getTextContent and add the extracted text in the annotation container (with an invisible text like in the text layer). Or the extracted text could be in an aria-description or something like that but then the text wouldn't be searchable.
I don't feel like to change the structure of to the text layer but an aria-role (or any other useful attributes) shouldn't break anything.

Comment 7

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub pull-request: https://github.com/mozilla/pdf.js/pull/15237

Comment 8

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub pull-request: https://github.com/mozilla/pdf.js/pull/15267

Comment 9

[Timea Zsoldos [:zstimi/tzsoldos], Desktop QA]

I can confirm this issue is fixed, I verified using Firefox 106.0a1 and Firefox 105.0b3 on Win 10x64, Ubuntu 20 x64 and macOS 10.15.