[Editor] Improve a11y for newly added element (#15109) #15110

calixteman · 2022-06-28T16:26:25Z

In the annotationEditorLayer, reorder the editors in the DOM according
the position of the elements on the screen;
add an aria-owns attribute on the "nearest" element in the text layer
which points to the added editor.

test/integration/freetext_editor_spec.js

calixteman · 2022-06-28T16:33:07Z

@jcsteh, @MReschenberg I'd like to have your feedback.

timvandermeij · 2022-07-03T09:53:45Z

src/display/editor/ink.js

@@ -479,6 +479,7 @@ class InkEditor extends AnnotationEditor {
  #createCanvas() {
    this.canvas = document.createElement("canvas");
    this.canvas.className = "inkEditorCanvas";
+    this.canvas.setAttribute("aria-label", "User created image");


Shouldn't all aria-labels in this patch fetch a localized string from the translation files?

Snuffleupagus · 2022-07-03T18:02:25Z

@calixteman Sorry about the delay in getting to this!
However, I was hoping for some feedback on the overall approach from the Firefox a11y-people, since you requested that in #15110 (comment), before trying to do an in-depth review of this PR.
(On the off chance that the implementation might change substantially, as a result of the a11y-feedback.)

Snuffleupagus · 2022-07-04T09:57:26Z

l10n/en-US/viewer.properties

+editor_ink_canvas_aria_label=User created image
+editor_ink_aria_label=Ink Editor
+editor_freetext_aria_label=FreeText Editor


For consistency, both in naming and ordering, should this be formatted as follows instead?

Suggested change

editor_ink_canvas_aria_label=User created image

editor_ink_aria_label=Ink Editor

editor_freetext_aria_label=FreeText Editor

editor_free_text_aria_label=FreeText Editor

editor_ink_aria_label=Ink Editor

editor_ink_canvas_aria_label=User created image

Please also add the strings in https://github.com/mozilla/pdf.js/blob/master/web/l10n_utils.js as well, otherwise fetching of l10n-strings won't work correctly in general.

Snuffleupagus · 2022-07-04T10:08:14Z

src/display/editor/annotation_editor_layer.js

+    const textLayer = this.div.parentNode
+      .getElementsByClassName("textLayer")
+      .item(0);
+    if (!textLayer) {
+      return shadow(this, "textLayerElements", null);
+    }


Given how most things in the viewer are asynchronous, the textLayer could potentially not yet exist when this code runs or at least not have been completely rendered yet; hence this could lead to intermittent behaviour/failures.

If the textLayer has finished rendering, its last element will be a div with a endOfContent-className. Otherwise you'd have probably have to, somehow, wait for the relevant "textlayerrendered"-event before running this code.

In any case, it seems to me that this code (and probably the rest of this patch) needs to be able to properly deal with the asynchronicity of the viewer here.

For some (possible) inspiration, please note how the structTree-functionality is handled in the viewer to account for the various kinds of asynchronicity involved:

pdf.js/web/pdf_page_view.js

Lines 785 to 815 in a1ac1a6

// The structure tree is currently only supported when the text layer is

// enabled and a canvas is used for rendering.

if (this.structTreeLayerFactory && this.textLayer && this.canvas) {

// The structure tree must be generated after the text layer for the

// aria-owns to work.

this._onTextLayerRendered = event => {

if (event.pageNumber !== this.id) {

return;

}

this.eventBus._off("textlayerrendered", this._onTextLayerRendered);

this._onTextLayerRendered = null;

if (!this.canvas) {

return; // The canvas was removed, prevent errors below.

}

this.pdfPage.getStructTree().then(tree => {

if (!tree) {

return;

}

if (!this.canvas) {

return; // The canvas was removed, prevent errors below.

}

const treeDom = this.structTreeLayer.render(tree);

treeDom.classList.add("structTree");

this.canvas.append(treeDom);

});

};

this.eventBus._on("textlayerrendered", this._onTextLayerRendered);

this.structTreeLayer =

this.structTreeLayerFactory.createStructTreeLayerBuilder(pdfPage);

}

Snuffleupagus · 2022-07-04T10:14:26Z

src/display/editor/annotation_editor_layer.js

+  removePointerInTextLayer(editor) {
+    const { id } = editor;
+    const node = this.#textNodes.get(id);
+    if (!node) {
+      return;
+    }
+
+    this.#textNodes.delete(id);
+    let owns = node.getAttribute("aria-owns");
+    if (owns?.includes(id)) {
+      owns = owns
+        .split(" ")
+        .filter(x => x !== id)
+        .join(" ");
+      if (owns) {
+        node.setAttribute("aria-owns", owns);
+      } else {
+        node.removeAttribute("aria-owns");
+      }
+    }
+  }


What happens if the textLayer has already been removed, as part of viewer clean-up (or just zooming), when this code runs; are we attempting to access dead DOM-elements in that case?

Could we perhaps avoid that sort of problem by re-factoring the #textNodes into a WeakMap instead?

src/display/editor/annotation_editor_layer.js

Snuffleupagus · 2022-07-04T10:17:28Z

src/display/editor/freetext.js

+
+    FreeTextEditor._l10nPromise
+      .get("editor_freetext_aria_label")
+      .then(msg => this.div.setAttribute("aria-label", msg));


Given the asynchronicity of the code, would it be safer to do the following?

Suggested change

.then(msg => this.div.setAttribute("aria-label", msg));

.then(msg => this.div?.setAttribute("aria-label", msg));

Snuffleupagus · 2022-07-04T10:17:55Z

src/display/editor/freetext.js

+
+    FreeTextEditor._l10nPromise
+      .get("freetext_default_content")
+      .then(msg => this.editorDiv.setAttribute("default-content", msg));


Given the asynchronicity of the code, would it be safer to do the following?

Suggested change

.then(msg => this.editorDiv.setAttribute("default-content", msg));

.then(msg => this.editorDiv?.setAttribute("default-content", msg));

Snuffleupagus · 2022-07-04T10:18:06Z

src/display/editor/ink.js

+
+    InkEditor._l10nPromise
+      .get("editor_ink_canvas_aria_label")
+      .then(msg => this.canvas.setAttribute("aria-label", msg));


Given the asynchronicity of the code, would it be safer to do the following?

Suggested change

.then(msg => this.canvas.setAttribute("aria-label", msg));

.then(msg => this.canvas?.setAttribute("aria-label", msg));

Snuffleupagus · 2022-07-04T10:18:13Z

src/display/editor/ink.js

+
+    InkEditor._l10nPromise
+      .get("editor_ink_aria_label")
+      .then(msg => this.div.setAttribute("aria-label", msg));


Given the asynchronicity of the code, would it be safer to do the following?

Suggested change

.then(msg => this.div.setAttribute("aria-label", msg));

.then(msg => this.div?.setAttribute("aria-label", msg));

Snuffleupagus · 2022-07-04T10:20:20Z

src/shared/util.js

+ * @returns {number} Index of the first array element to pass the test,
+ *                   or |items.length| if no such element exists.
+ */
+function binarySearchFirstItem(items, condition, start = 0) {


Are you expecting to use this code anywhere in the src/core/-folder?

If not, you probably want to place this in https://github.com/mozilla/pdf.js/blob/master/src/display/display_utils.js instead to avoid unnecessarily duplicating this code in both of the built pdf.js and pdf.worker.js files.

calixteman · 2022-07-04T16:23:48Z

@calixteman Sorry about the delay in getting to this! However, I was hoping for some feedback on the overall approach from the Firefox a11y-people, since you requested that in #15110 (comment), before trying to do an in-depth review of this PR. (On the off chance that the implementation might change substantially, as a result of the a11y-feedback.)

I pinged Jamie and Morgan on slack, but today is the 4th of July, so I hope we'll have some feedback this week.

jcsteh

Thanks for working on this. Sorry for the delay in taking a look.

Is this expected to work on both tagged and untagged PDFs? It's hard for me to verify at present due to the aria-owns bug; see below.

jcsteh · 2022-07-06T02:07:58Z

src/display/editor/annotation_editor_layer.js

+    const node = children[Math.max(0, index - 1)];
+    const owns = node.getAttribute("aria-owns");
+    if (!owns?.includes(id)) {
+      node.setAttribute("aria-owns", owns ? `${owns} ${id}` : id);


This isn't working as expected. role="presentation" is incompatible with aria-owns because aria-owns requires that the element is in the a11y tree, but role="presentation" removes the element from the a11y tree. Firefox probably should ignore role="presentation" in this case (bug 1762116), but it currently doesn't. We can fix that in Firefox, but regardless, these attributes really shouldn't be set simultaneously. That is, role="presentation" should be removed if aria-owns is set and replaced when aria-owns is removed. Unfortunately, this is going to require changes to a bunch of other code here. :(

Ok I'll remove the presentation role and add it back.

jcsteh · 2022-07-06T02:09:35Z

src/display/editor/editor.js

@@ -213,7 +213,7 @@ class AnnotationEditor {
    this.div.setAttribute("data-editor-rotation", (360 - this.rotation) % 360);
    this.div.className = this.name;
    this.div.setAttribute("id", this.id);
-    this.div.tabIndex = 100;
+    this.div.tabIndex = 0;


This wrapping div shouldn't have a tabindex. The contenteditable is already focusable and we should rely on that for focusability. Otherwise, we end up with a pointless (arguably broken) tab stop here.

The contenteditable attribute is removed when the editor isn't in an editable state: for example when the user drags it to move it somewhere else on the page.
Anyway I'll remove the tab-index when the editor is in editing mode.
And there is too an "ink" editor in order to draw something on a pdf

The contenteditable attribute is removed when the editor isn't in an editable state: for example when the user drags it to move it somewhere else on the page.

Ah. It'll be hard for screen reader users to drag anyway, but regardless, I'm curious: what happens when a user drags the editor? Does it become non-editable altogether after that point or just while the user is holding down the mouse button?

A text editor can changed in double-clicking on it (simple click makes it the current one).
The idea behind being able to move is, is to help to adjust the position when you want to fill a form.

jcsteh · 2022-07-06T02:11:06Z

src/display/editor/freetext.js

+
+    FreeTextEditor._l10nPromise
+      .get("editor_free_text_aria_label")
+      .then(msg => this.div?.setAttribute("aria-label", msg));


Similar to focus, the role, aria-multiline and aria-label attributes must be set on the contentEditable itself (this.editorDiv), not the wrapping div.

calixteman · 2022-07-06T15:57:13Z

Thanks for working on this. Sorry for the delay in taking a look.

Is this expected to work on both tagged and untagged PDFs? It's hard for me to verify at present due to the aria-owns bug; see below.

I had a look on a tagged pdf:
https://www.cdph.ca.gov/Programs/OHE/CDPH%20Document%20Library/Accessible-CDPH_OHE_Disparity_Report_Final%20(2).pdf

and I noticed the spans containing the text are inside some span with the class markedContent.

so I'm adding the aria-owns on the inner span (the one containing the text), is it correct or should it be on its parent ?

test/integration/freetext_editor_spec.js

+              for (const span of el.querySelectorAll(
+                `span[role="presentation"]`
+              )) {
+                if (span.innerText.includes("adobe.com")) {


l10n/en-US/viewer.properties

src/display/editor/annotation_editor_layer.js

jcsteh

This is much better; thank you.

Is there supposed to be some way to dismiss the editor once you're done or does it just stay editable?

Also, how are text annotations rendered into the document after you save it? Any fixes there would probably be a separate piece of work, but I thought I'd ask here anyway.

jcsteh · 2022-07-14T04:10:27Z

src/display/editor/editor.js

@@ -213,7 +213,7 @@ class AnnotationEditor {
    this.div.setAttribute("data-editor-rotation", (360 - this.rotation) % 360);
    this.div.className = this.name;
    this.div.setAttribute("id", this.id);
-    this.div.tabIndex = 100;
+    this.div.tabIndex = 0;


The contenteditable attribute is removed when the editor isn't in an editable state: for example when the user drags it to move it somewhere else on the page.

Ah. It'll be hard for screen reader users to drag anyway, but regardless, I'm curious: what happens when a user drags the editor? Does it become non-editable altogether after that point or just while the user is holding down the mouse button?

jcsteh · 2022-07-14T04:16:11Z

I had a look on a tagged pdf: https://www.cdph.ca.gov/Programs/OHE/CDPH%20Document%20Library/Accessible-CDPH_OHE_Disparity_Report_Final%20(2).pdf

and I noticed the spans containing the text are inside some span with the class markedContent.

so I'm adding the aria-owns on the inner span (the one containing the text), is it correct or should it be on its parent ?

I don't think it matters. It seems to work as expected as is.

calixteman · 2022-07-15T14:43:00Z

@Snuffleupagus , anything to add ?

Snuffleupagus · 2022-07-15T14:45:23Z

Sorry; I've not (yet) had time to look at this since the last round of changes, but will hopefully have time for that during the weekend.

Snuffleupagus

Given that this modifies the DOM of the textLayer, have you tested that highlighting of search results still work correctly with this patch (once new annotations are added)?

Naively, without having tested, it seems to me that this could potentially cause issues. E.g. consider the case where you first search and then add a new annotation, what happens to the existing search-highlight in that case?

Assuming that this does indeed work, would it be feasible to add an integration-test for searching in "edited" documents?

Snuffleupagus · 2022-07-16T15:00:16Z

src/display/editor/annotation_editor_layer.js

  }

  /**
   * Update the toolbar if it's required to reflect the tool currently used.
   * @param {number} mode
-   * @returns {undefined}
+


Here, and in number of places below, there's empty lines inside of JSDoc-comment blocks.
This is likely caused by search-and-replace, but please go through the patch and remove these unneeded new-lines.

Snuffleupagus · 2022-07-16T15:03:15Z

src/display/editor/annotation_editor_layer.js

+    return textChildren;
+  }
+
+  #hasTextLayer() {


Perhaps make this a getter instead?

Snuffleupagus · 2022-07-16T15:04:32Z

src/display/editor/annotation_editor_layer.js

+
+  /**
+   * Find the text node which is the nearest and add an aria-owns attribute
+   * in order to position correctly this editor in the text flow.


Grammar nit:

Suggested change

* in order to position correctly this editor in the text flow.

* in order to correctly position this editor in the text flow.

Snuffleupagus · 2022-07-16T15:13:32Z

src/display/editor/freetext.js

-    FreeTextEditor._l10nPromise.then(msg =>
-      this.editorDiv.setAttribute("default-content", msg)
-    );
+    this.editorDiv.id = `${this.id}-editor`;


This is another case where I'm not sure that it's generally a good idea to add element ids to the DOM, since that makes them linkable.
Similar to other recent patches, can we use a custom data-element-id attribute instead?

(Also, if there's other pre-existing cases of ids being used in the Editor they probably need to be updated as well.)

Unfortunately aria-owns value must be an id or a list of ids:
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-owns#values
All the ideas are prefixed by:

pdf.js/src/shared/util.js

Line 55 in e08b079

const AnnotationEditorPrefix = "pdfjs_internal_editor_";

We can make it a bit more complex and dynamic to avoid any conflicts.

Snuffleupagus · 2022-07-16T15:14:48Z

src/display/editor/ink.js

@@ -418,6 +429,10 @@ class InkEditor extends AnnotationEditor {
    this.#fitToContent();

    this.parent.addInkEditorIfNeeded(/* isCommitting = */ true);
+
+    // When commiting, the position of this editor is changed, hence we must
+    // move it at the right position in the DOM.


Grammar nit:

Suggested change

// move it at the right position in the DOM.

// move it to the right position in the DOM.

Snuffleupagus · 2022-07-16T15:15:35Z

src/display/editor/tools.js

+    this.#eventBus._on(
+      "textlayerrendered",
+      this.#onTextLayerRendered.bind(this)
+    );


Just like the event above, this one also needs to be removed on destruction.

calixteman · 2022-07-18T12:58:05Z

Is there supposed to be some way to dismiss the editor once you're done or does it just stay editable?

Once the user finished to add some text, they can click outside the area of the editor to commit it.
A double-click on it will reopen it to make it editable.

Also, how are text annotations rendered into the document after you save it? Any fixes there would probably be a separate piece of work, but I thought I'd ask here anyway.

Text annotation are rendered as basic FreeText annotations it appears that I didn't think about a11y when saving: I need to check how it works in pdf format.
In HCM the color on screen is not necessarily the same as the one in the printed/saved pdf.

calixteman · 2022-07-18T13:14:29Z

Given that this modifies the DOM of the textLayer, have you tested that highlighting of search results still work correctly with this patch (once new annotations are added)?

Naively, without having tested, it seems to me that this could potentially cause issues. E.g. consider the case where you first search and then add a new annotation, what happens to the existing search-highlight in that case?

The text layer is structurally not modified: only some aria-owns attributes are added on some nodes.
The node reordering is just applied in the annotationEditor layer and it has no impact on the search stuff.

Assuming that this does indeed work, would it be feasible to add an integration-test for searching in "edited" documents?

Yep I can but I'm not sure to see how it could be useful.
Do I miss something ?

pdfjsbot · 2022-07-19T10:41:39Z

From: Bot.io (Linux m4)

Received

Command cmd_integrationtest from @calixteman received. Current queue size: 0

Live output at: http://54.241.84.105:8877/467f21b0eddbec9/output.txt

pdfjsbot · 2022-07-19T10:46:45Z

From: Bot.io (Linux m4)

Failed

Full output at http://54.241.84.105:8877/467f21b0eddbec9/output.txt

Total script time: 5.09 mins

Integration Tests: FAILED

pdfjsbot · 2022-07-19T10:53:40Z

From: Bot.io (Windows)

Failed

Full output at http://54.193.163.58:8877/57a129dacc30229/output.txt

Total script time: 12.04 mins

Integration Tests: FAILED

calixteman · 2022-07-19T16:04:59Z

/botio integrationtest

pdfjsbot · 2022-07-19T16:05:00Z

From: Bot.io (Linux m4)

Received

Command cmd_integrationtest from @calixteman received. Current queue size: 0

Live output at: http://54.241.84.105:8877/75fab4705366967/output.txt

pdfjsbot · 2022-07-19T16:05:00Z

From: Bot.io (Windows)

Received

Command cmd_integrationtest from @calixteman received. Current queue size: 1

Live output at: http://54.193.163.58:8877/6a4f65955766292/output.txt

pdfjsbot · 2022-07-19T16:09:32Z

From: Bot.io (Linux m4)

Success

Full output at http://54.241.84.105:8877/75fab4705366967/output.txt

Total script time: 4.51 mins

Integration Tests: Passed

pdfjsbot · 2022-07-19T16:20:30Z

From: Bot.io (Windows)

Failed

Full output at http://54.193.163.58:8877/6a4f65955766292/output.txt

Total script time: 10.03 mins

Integration Tests: FAILED

- In the annotationEditorLayer, reorder the editors in the DOM according the position of the elements on the screen; - add an aria-owns attribute on the "nearest" element in the text layer which points to the added editor.

calixteman · 2022-07-19T16:53:20Z

/botio integrationtest

pdfjsbot · 2022-07-19T16:53:22Z

From: Bot.io (Linux m4)

Received

Command cmd_integrationtest from @calixteman received. Current queue size: 0

Live output at: http://54.241.84.105:8877/18e5845e66ce512/output.txt

pdfjsbot · 2022-07-19T16:53:22Z

From: Bot.io (Windows)

Received

Command cmd_integrationtest from @calixteman received. Current queue size: 0

Live output at: http://54.193.163.58:8877/11ba4890119d0d6/output.txt

pdfjsbot · 2022-07-19T16:57:55Z

From: Bot.io (Linux m4)

Success

Full output at http://54.241.84.105:8877/18e5845e66ce512/output.txt

Total script time: 4.54 mins

Integration Tests: Passed

pdfjsbot · 2022-07-19T17:00:32Z

From: Bot.io (Windows)

Failed

Full output at http://54.193.163.58:8877/11ba4890119d0d6/output.txt

Total script time: 7.16 mins

Integration Tests: FAILED

Snuffleupagus · 2022-07-19T17:03:35Z

/botio-windows integrationtest

pdfjsbot · 2022-07-19T17:03:37Z

From: Bot.io (Windows)

Received

Command cmd_integrationtest from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.193.163.58:8877/8f5289254ea60f0/output.txt

pdfjsbot · 2022-07-19T17:13:18Z

From: Bot.io (Windows)

Failed

Full output at http://54.193.163.58:8877/8f5289254ea60f0/output.txt

Total script time: 9.66 mins

Integration Tests: FAILED

Snuffleupagus · 2022-07-19T17:48:54Z

/botio integrationtest

pdfjsbot · 2022-07-19T17:48:56Z

From: Bot.io (Linux m4)

Received

Command cmd_integrationtest from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.241.84.105:8877/ad8ad86eccb330f/output.txt

pdfjsbot · 2022-07-19T17:48:56Z

From: Bot.io (Windows)

Received

Command cmd_integrationtest from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.193.163.58:8877/d0929c543c7c034/output.txt

pdfjsbot · 2022-07-19T17:53:29Z

From: Bot.io (Linux m4)

Success

Full output at http://54.241.84.105:8877/ad8ad86eccb330f/output.txt

Total script time: 4.55 mins

Integration Tests: Passed

pdfjsbot · 2022-07-19T17:58:23Z

From: Bot.io (Windows)

Failed

Full output at http://54.193.163.58:8877/d0929c543c7c034/output.txt

Total script time: 9.44 mins

Integration Tests: FAILED

calixteman · 2022-07-19T18:00:06Z

@Snuffleupagus, once I've some time I'll try to fix the PageOpen issue on windows (I can't reproduce it locally).

Snuffleupagus · 2022-07-19T18:04:32Z

once I've some time I'll try to fix the PageOpen issue on windows (I can't reproduce it locally).

It's the same for me as well, it works just fine locally on Windows.

calixteman added the editor label Jun 28, 2022

calixteman linked an issue Jun 28, 2022 that may be closed by this pull request

Make the newly added elements accessible #15109

Closed

calixteman requested a review from Snuffleupagus June 28, 2022 16:27

github-advanced-security bot found potential problems Jun 28, 2022

View reviewed changes

test/integration/freetext_editor_spec.js Fixed Show fixed Hide fixed

test/integration/freetext_editor_spec.js Fixed Show fixed Hide fixed

calixteman force-pushed the editing_a11y branch from a1bd92a to 87178bf Compare June 29, 2022 13:52

timvandermeij reviewed Jul 3, 2022

View reviewed changes

calixteman force-pushed the editing_a11y branch from 87178bf to 205d562 Compare July 3, 2022 16:08

calixteman requested a review from timvandermeij July 3, 2022 16:26

Snuffleupagus requested changes Jul 4, 2022

View reviewed changes

calixteman force-pushed the editing_a11y branch from 205d562 to 0f65a6d Compare July 5, 2022 14:52

calixteman requested a review from Snuffleupagus July 5, 2022 14:52

jcsteh suggested changes Jul 6, 2022

View reviewed changes

calixteman force-pushed the editing_a11y branch from 0f65a6d to 353b0f1 Compare July 6, 2022 16:33

github-advanced-security bot found potential problems Jul 6, 2022

View reviewed changes

timvandermeij reviewed Jul 9, 2022

View reviewed changes

calixteman force-pushed the editing_a11y branch from 353b0f1 to 02fadc8 Compare July 13, 2022 09:30

jcsteh approved these changes Jul 14, 2022

View reviewed changes

calixteman force-pushed the editing_a11y branch 2 times, most recently from 9ce3678 to 4c0f442 Compare July 15, 2022 14:31

Snuffleupagus requested changes Jul 16, 2022

View reviewed changes

calixteman mentioned this pull request Jul 19, 2022

[Editor] Simplify the way to create an editor on click #15184

Merged

calixteman force-pushed the editing_a11y branch from 27fe376 to f868e47 Compare July 19, 2022 16:04

[Editor] Improve a11y for newly added element (mozilla#15109)

624b26e

- In the annotationEditorLayer, reorder the editors in the DOM according the position of the elements on the screen; - add an aria-owns attribute on the "nearest" element in the text layer which points to the added editor.

calixteman force-pushed the editing_a11y branch from f868e47 to 624b26e Compare July 19, 2022 16:52

Snuffleupagus merged commit f46895d into mozilla:master Jul 19, 2022

Snuffleupagus mentioned this pull request Aug 14, 2022

Move binarySearchFirstItem back to the web/-folder (PR 15237 follow-up) #15313

Merged

	// The structure tree is currently only supported when the text layer is
	// enabled and a canvas is used for rendering.
	if (this.structTreeLayerFactory && this.textLayer && this.canvas) {
	// The structure tree must be generated after the text layer for the
	// aria-owns to work.
	this._onTextLayerRendered = event => {
	if (event.pageNumber !== this.id) {
	return;
	}
	this.eventBus._off("textlayerrendered", this._onTextLayerRendered);
	this._onTextLayerRendered = null;

	if (!this.canvas) {
	return; // The canvas was removed, prevent errors below.
	}
	this.pdfPage.getStructTree().then(tree => {
	if (!tree) {
	return;
	}
	if (!this.canvas) {
	return; // The canvas was removed, prevent errors below.
	}
	const treeDom = this.structTreeLayer.render(tree);
	treeDom.classList.add("structTree");
	this.canvas.append(treeDom);
	});
	};
	this.eventBus._on("textlayerrendered", this._onTextLayerRendered);
	this.structTreeLayer =
	this.structTreeLayerFactory.createStructTreeLayerBuilder(pdfPage);
	}

	.then(msg => this.div.setAttribute("aria-label", msg));
	.then(msg => this.div?.setAttribute("aria-label", msg));

	.then(msg => this.editorDiv.setAttribute("default-content", msg));
	.then(msg => this.editorDiv?.setAttribute("default-content", msg));

	.then(msg => this.canvas.setAttribute("aria-label", msg));
	.then(msg => this.canvas?.setAttribute("aria-label", msg));

	* in order to position correctly this editor in the text flow.
	* in order to correctly position this editor in the text flow.

	// move it at the right position in the DOM.
	// move it to the right position in the DOM.

[Editor] Improve a11y for newly added element (#15109) #15110

[Editor] Improve a11y for newly added element (#15109) #15110

Conversation

calixteman commented Jun 28, 2022

calixteman commented Jun 28, 2022

timvandermeij Jul 3, 2022 • edited Loading

Choose a reason for hiding this comment

Snuffleupagus commented Jul 3, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Snuffleupagus Jul 4, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

calixteman commented Jul 4, 2022

jcsteh left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

calixteman commented Jul 6, 2022

jcsteh left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcsteh commented Jul 14, 2022

calixteman commented Jul 15, 2022

Snuffleupagus commented Jul 15, 2022

Snuffleupagus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

calixteman commented Jul 18, 2022

calixteman commented Jul 18, 2022

pdfjsbot commented Jul 19, 2022

From: Bot.io (Linux m4)

Received

pdfjsbot commented Jul 19, 2022

From: Bot.io (Linux m4)

Failed

pdfjsbot commented Jul 19, 2022

From: Bot.io (Windows)

Failed

calixteman commented Jul 19, 2022

pdfjsbot commented Jul 19, 2022

From: Bot.io (Linux m4)

Received

pdfjsbot commented Jul 19, 2022

From: Bot.io (Windows)

Received

pdfjsbot commented Jul 19, 2022

From: Bot.io (Linux m4)

Success

pdfjsbot commented Jul 19, 2022

From: Bot.io (Windows)

Failed

calixteman commented Jul 19, 2022

pdfjsbot commented Jul 19, 2022

From: Bot.io (Linux m4)

Received

pdfjsbot commented Jul 19, 2022

From: Bot.io (Windows)

Received

pdfjsbot commented Jul 19, 2022

From: Bot.io (Linux m4)

Success

pdfjsbot commented Jul 19, 2022

From: Bot.io (Windows)

timvandermeij Jul 3, 2022 •

edited

Loading

Snuffleupagus Jul 4, 2022 •

edited

Loading