alice
commented
1 month ago Thoughts from the session just now:
@chrishtr suggested having modes where fallback content which isn't placed is/isn't exposed to AT.
That might be a start; perhaps you could have placeElement() etc. cause the fallback content to not be exposed by default (with content shown on the canvas always exposed), and you can opt in (maybe an attribute on the <canvas> or something) to saying "yes, I intend this fallback content to be exposed as well".
Another alternative might be, to potentially solve a more narrow problem, if there are a set of elements which are intended to replace one another with some being considered "stale", to offer authors a way to declare those elements as mutually exclusive on the canvas, so that placing one will remove the others, similar to how re-placing an element will cause the earlier drawing to be removed.
That may be completely infeasible; I just wanted to continue thinking through the problem a little more.
Elements in fallback content which are passed to
placeElement()are still exposed to assistive technology APIs, just like all other canvas fallback content. There needs to be a way to indicate that some children are not yet in the canvas (untilplaceElement()is called on them) and hence should not be visible to assistive technologies.This can be achieved with any of the usual techniques for hiding content from assistive technology, such as using the hidden, inert or aria-hidden attributes, or applying a display: none or display: hidden style. Browsers cannot automate this because they do not know which fallback content is for non-placeElement portions of the canvas, and hence should remain accessible.
Some mechanism could be defined for distinguishing the two different use cases for fallback content and should at least be noted in the spec. We may wish to define a specific method of hiding so that the attribute/property can be removed when
placeElement()is called.