1485076 - The canvas accessibility hack for bug 495912 is observable.

Status: NEW

(Core :: Layout, enhancement, P3)

Description

[Emilio Cobos Álvarez (:emilio)]

Bug 495912 introduced a hack that allowed canvas contents to be rendered, by putting them in an anon block.

That not only causes a bunch of extra layout work, but it's observable via CSSOM / cssom-view / DOM methods that depend on layout like innerText.

Can we do something else here?

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Attachment: testcase

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Alex, can we do something else here to avoid rendering the HTML fallback?

Comment 3

[alexander :surkov (:asurkov)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)
> Alex, can we do something else here to avoid rendering the HTML fallback?

This one is a tricky one: accessible tree heavily relies on a frame tree in addition to a DOM tree. However we don't really need to have it physically rendered. I'm not sure if it will help to performance, but it might be a point of compromise.

Daniel, do you have any thoughts on this?

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to alexander :surkov (:asurkov) from comment #3)
> Daniel, do you have any thoughts on this?

Nothing concrete (this is the first I've heard of bug 495912 and I don't know a lot about a11y::layout interactions).  Somewhat hand-wavingly: perhaps we could make the canvas-alternative-content-frametree be opt-in, and make the canvas inner-content effectively display:none (no frames) until we detect that there's an a11y tool that needs it?

(Do we do something like that for other a11y APIs?)

Comment 5

[Daniel Holbert [:dholbert]]

[triage: this feels P3, unless there's known interop/perf issues from real websites where this is biting us]

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Ideally we wouldn't have a frame tree at all. Having a frame tree is what causes this incompatibility.

Alex, do you have any idea of how often people put something more complex than text in there? Could A11Y use the textContent of the canvas element instead as alternative text?

Comment 7

[alexander :surkov (:asurkov)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)
> Ideally we wouldn't have a frame tree at all. Having a frame tree is what
> causes this incompatibility.

agreed, however there's no currently other was to provide geometry for canvas content.

> Alex, do you have any idea of how often people put something more complex
> than text in there? Could A11Y use the textContent of the canvas element
> instead as alternative text?

that was a whole idea of canvas content. You can put there literally anything to make canvas content accessible.