Closed Bug 1793419 Opened 2 years ago Closed 2 years ago

Screenreader does not read annotated text in PDF documents

Categories

(Firefox :: PDF Viewer, defect, P1)

Desktop
All
defect

Tracking

()

VERIFIED FIXED
108 Branch
Accessibility Severity s2
Tracking Status
firefox-esr102 --- unaffected
firefox106 --- wontfix
firefox107 + verified
firefox108 --- verified
firefox111 --- verified

People

(Reporter: oardelean, Assigned: calixte)

References

Details

(Keywords: access)

Attachments

(4 files)

Found in

  • Firefox 106.0b7

Affected versions

  • Firefox 106.0b7;
  • Nightly 107.0a1;

Tested platforms

  • macOS 12;
  • Windows 10;
  • Ubuntu 22;

Affected platforms

  • macOS 12;
  • Windows 10;
  • Ubuntu 22;

Steps to reproduce

  1. Launch Firefox and go to any pdf form, for example https://www.africau.edu/images/default/sample.pdf.
  2. Click on the Text button from the upper right side of the PDF Toolbar.
  3. Select a place on the PDF and enter any text.
  4. Enable the screenreader(VoiceOver on macOS, NVDA on Windows, ORCA on Linux).
  5. Focus the previously written text.

Expected result

  • Screenreader should be able to read the text correctly.

Actual result

  • Screenreader reads any text as "group"/"blank"(depending on OS).

Regression range

  • Not a regressions since this is a new feature.

Additional notes

  • I noticed that if the user is writing the text slowly with VoiceOver enabled, VoiceOver will read the input letter by letter. On Windows, NVDA reads "blank" instead of "group". Orca does not recognize the text at all on Linux if focused. Please see attached video with the issue.
Has STR: --- → yes
Severity: -- → S3
Keywords: access
Summary: Screenreader incorrectly reads focused text in PDF documents → Screenreader does not read annotated text in PDF documents
Whiteboard: [access-s2]

Re-triaging to PDF because I'm not convinced this is an a11y platform issue -- it sounds like we're exposing this element consistently across platforms ("blank" and "group" seem similar enough).

:marco, when a user adds annotated text, what kind of element do we use to display it? Is it an SVG?

Component: Disability Access APIs → PDF Viewer
Flags: needinfo?(mcastelluccio)
Product: Core → Firefox
Severity: S3 → --
Attached image image.png

:morgan, you can see in devtools how the annotation is structured (see the image in attachment).
I wonder if it could be related to the fact that the div we use to edit the annotation gets a contenteditable="true" when edited and this one will wrap each line in a div.

Flags: needinfo?(mcastelluccio)

I managed to have something working on Windows with NVDA in using the attribute aria-activedescendant to make it pointing to the nested div (the one containing the text).
I tested the patch on mac 12.6 with VoiceOver and a fresh Firefox build and unfortunately I'm still stuck on "You're in a group".
:morgan, would you have any advice ?

Assignee: nobody → cdenizet
Status: NEW → ASSIGNED
Flags: needinfo?(mreschenberg)
Priority: -- → P1

With VoiceOver, once we're on a newly added text, it's possible for the reader to read the contents in hitting ctrl+option+right arrow.

Followed up on github :) Let me know if you're still having that issue, things look good to me when I test this locally.

Flags: needinfo?(mreschenberg)

It would be nice to uplift this, since this is a new feature in 106 and we want it to be as accessible as possible.

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 108 Branch

[Tracking Requested - why for this release]: See comment 7.

:marco could you please confirm the bug tracking the pdf update which includes this fix?
Looks like Bug 1796243 needs a beta uplift request?

Flags: needinfo?(mcastelluccio)

Bug 1796243 contains the whole update, but we might want to cherry pick only the patch that fixes this bug specifically.

Flags: needinfo?(mcastelluccio) → needinfo?(cdenizet)

Oana, could you verify the fix?

Flags: needinfo?(oana.ardelean)

Comment on attachment 9300146 [details]
Bug 1793419 - Make FreeText annotations visible for screen readers in editing mode r=#pdfjs-reviewers

Beta/Release Uplift Approval Request

  • User impact if declined: Newly added annotations will be invisible for users using a screen reader.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: See the STR in comment #1.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The patch is very small and it's just a matter of adding an aria property to a html element.
  • String changes made/needed:
  • Is Android affected?: No
Flags: needinfo?(cdenizet)
Attachment #9300146 - Flags: approval-mozilla-beta?
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

On Nightly 108.0a1(2022-10-25) Screenreader perceives the inserted text as follows:

  • macOS 12(with VoiceOver): on focus, instead of “group”, it now says “Text Editor, group”. If navigating with CTRL+Option+Right Arrow, then VoiceOver will spell the correct words afterwards. Here's a recording for more detail on the exact behaviour.
  • Windows 10(with NVDA): on focus, instead of “blank”, on the first tabbed word(which was test), the spelling is “Clickable test", but the rest of the inserted words are spelled correctly.
  • Linux(with OS's native Screenreader): on focus, it now spells "Text Editor" before each inserted word. This applies to all words/phrases.
Flags: needinfo?(oana.ardelean)

Comment on attachment 9300146 [details]
Bug 1793419 - Make FreeText annotations visible for screen readers in editing mode r=#pdfjs-reviewers

Approved for 107.0b6.

Attachment #9300146 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

(In reply to Ardelean Oana from comment #14)

On Nightly 108.0a1(2022-10-25) Screenreader perceives the inserted text as follows:

  • macOS 12(with VoiceOver): on focus, instead of “group”, it now says “Text Editor, group”. If navigating with CTRL+Option+Right Arrow, then VoiceOver will spell the correct words afterwards. Here's a recording for more detail on the exact behaviour.
  • Windows 10(with NVDA): on focus, instead of “blank”, on the first tabbed word(which was test), the spelling is “Clickable test", but the rest of the inserted words are spelled correctly.
  • Linux(with OS's native Screenreader): on focus, it now spells "Text Editor" before each inserted word. This applies to all words/phrases.

:calixte, I think the VO and Windows behaviour here is acceptable, but the linux behaviour sounds like it makes annotations borderline unusable.
:eeejay is this an issue you've seen on linux before? having the role spelled out? I'm wondering if that's a platform bug vs. a markup one

Flags: needinfo?(eitan)
Flags: needinfo?(cdenizet)

(In reply to Morgan Reschenberg [:morgan] from comment #17)

:eeejay is this an issue you've seen on linux before? having the role spelled out? I'm wondering if that's a platform bug vs. a markup one

I just tested it, and it seems to behave properly. Says role ("text editor") and the text contents of the field.

Flags: needinfo?(eitan)

Tested on Windows 10, Ubuntu 20 and on macOS 12 on Firefox 111.0b5, I can confirm the behave of screen reader is correct.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
Accessibility Severity: --- → s2
Whiteboard: [access-s2]

Needinfo not needed anymore, given the bug was fixed on Linux too according to comment 18 and comment 19.

Flags: needinfo?(cdenizet)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: