Closed Bug 1428428 Opened 2 years ago Closed 2 years ago

Do not create accessible object for custom content container in the CanvasFrame.

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla59
Tracking Status
firefox59 --- fixed

People

(Reporter: yzen, Assigned: yzen)

References

Details

Attachments

(1 file)

Right now accessibility service is creating a generic "section" accessible object for the container. This is a little bit noisy for tools that do accessibility tree inspection. I hope it is reasonable enough to add a role="presentation" attribute to avoid accessible creation.
Priority: -- → P3
Attached patch 1428428 patchSplinter Review
Attachment #8940821 - Flags: review?(dholbert)
I'm missing a lot of context/background-knowledge here that would help me review this.

Can you elaborate on the problem & why this is the right solution? (Comment 0 starts to do that, but I'm not familiar enough with a11y or role="presentation" to really understand what comment 0 is saying.)
Flags: needinfo?(yzenevich)
(In reply to Daniel Holbert [:dholbert] from comment #2)
> I'm missing a lot of context/background-knowledge here that would help me
> review this.
> 
> Can you elaborate on the problem & why this is the right solution? (Comment
> 0 starts to do that, but I'm not familiar enough with a11y or
> role="presentation" to really understand what comment 0 is saying.)

Certainly, here's some context:

Right now, most of the modern highlighters in Firefox DevTools are implemented in anonymous canvas frame. While working on accessibility inspector tool (similar to DOM inspector, bug 1151468) that inspects accessibility tree I noticed that platform accessibility creates a generic "section" accessible for the anonymous container of the canvas frame. This is expected behaviour as there is no additional (and likely should not be) semantics associated with the container. 

In itself it is not a big issue, except that it creates additional and not necessary nesting in the accessibility tree. However, with the new accessibility inspector the presence of this accessible object adds noise and confusion as it pops up in the tree whenever the highlighter is shown. I can clean up the markup of the highlighter however this is the only way I can prevent accessibility module from creating an accessible object for the container itself.

Hope this helps.
Flags: needinfo?(yzenevich)
Thanks! This seems fine.

I'm adding a loose dependency on bug 1020244, which is where "mCustomContentContainer" was introduced (for these overlays that we want to hide from a11y).
Depends on: 1020244
Comment on attachment 8940821 [details] [diff] [review]
1428428 patch

Review of attachment 8940821 [details] [diff] [review]:
-----------------------------------------------------------------

Commit message nit:
> Bug 1428428 - do not create accessible object for the canvas frame container.

The term "canvas frame container" isn't specific enough -- it sounds to me like it's just referring to the nsCanvasFrame class itself.

How about "...for the nsCanvasFrame custom-content container"?

r=me with that or similar
Attachment #8940821 - Flags: review?(dholbert) → review+
Pushed by yura.zenevich@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/50e63dd0a451
do not create accessible object for the nsCanvasFrame custom-content container. r=dholbert
https://hg.mozilla.org/mozilla-central/rev/50e63dd0a451
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
You need to log in before you can comment on or make changes to this bug.