[Role Parity] What do we do about canvas?

[asurkov]

canvas semantics is different from image semantcis, and also(thus) has a separate role in platform API mappings. Not sure whether ARIA has to replicate HTML semantic, but if yes, then I'd say to have role="canvas".

[joanmarie]

As we discuss this further (during the face-to-face): While there are platform accessibility API mappings for something which is a "canvas", canvases themselves aren't really exposed/consumed by ATs are they??

As I understand it, what gets exposed is the fallback content. In which case, should this instead be mapped as a generic?

[css-meeting-bot]

The ARIA Working Group just discussed canvas.

The full IRC log of that discussion

<HarrisSchneiderman> topic: canvas
<HarrisSchneiderman> https://github.com/w3c/aria/issues/927
<HarrisSchneiderman> Github: https://github.com/w3c/aria/issues/927
<HarrisSchneiderman> jamesn: do platform APIs have canvas?
<HarrisSchneiderman> joanie: yep
<HarrisSchneiderman> jamesn: maybe canvas sounds harder than it is
<HarrisSchneiderman> joanie: its kind of like I just proposed on the audio/video ticket
<HarrisSchneiderman> joanie: this isn't a group in that it is not a block of text. So the question is do we want a canvas role? or do we want a canvas-y property?
<HarrisSchneiderman> joanie: we already have ways to specify logic to say "if it is a role x and has aria attribute y then it is mapped to z"
<HarrisSchneiderman> melanierichards: role makes more sense to me
<HarrisSchneiderman> mck: the nice thing about the role approach is that you can make sure it doesn't inherit a bunch of junk
<joanie> https://trac.webkit.org/browser/webkit/trunk/LayoutTests/platform/mac/accessibility/roles-exposed-expected.txt#L67
<HarrisSchneiderman> joanie: this to me means canvas is not exposed on a mac
<HarrisSchneiderman> mck: are there elements that can go in a canvas?
<HarrisSchneiderman> jamesn: anything
<HarrisSchneiderman> joanie: thats the fallback content
<HarrisSchneiderman> mck: doesn't that mean we could just map it to a generic since its just a container
<HarrisSchneiderman> carmacleod: would you want to label it?
<HarrisSchneiderman> mck: generics don't get exposed like that
<HarrisSchneiderman> jamesn: they often do get exposed
<HarrisSchneiderman> mck: only if they're focusable
<HarrisSchneiderman> mck: we're diving off into generic - let's not do that

[AmeliaBR]

My recommendation: if the canvas has no accessible children, it's role should be image.

If it does have children, its role should be graphics-document, the same as an <svg>.

[jnurthen]

As detailed at https://github.com/w3c/aria/wiki/Plans-regarding-role-parity#no-consensus-yet-will-do-for-1-3 moving to 1.3

[brennanyoung]

I'm seeing pretty inconsistent behavior with canvas fallback content across user agents and ATs. (Some combinations e.g. NVDA+Chrome or NVDA+Edge even announce tab and linebreak sequences as " " and "blank" when they appear in canvas fallback content, which is surely a mistake. FF does not have this issue).

Shouldn't the fallback content behave exactly as if the canvas was a div? In other words, the various browse-mode/document-mode shortcuts should work in the same way as they do when there is no canvas. Currently, they don't, and I suspect the missing guidelines in this area are contributing to the inconsistency. If I want to report this as a bug to the chromium bug tracker, it would be good if I could point to the relevant part of the spec.

Whether there's to be an explicit canvas role or not (btw I approve of Amelia's suggestion), I would welcome some explicit guidance about how user agent accessibility trees and ATs should handle canvas fallback content.

[JAWS-test]

Shouldn't the fallback content behave exactly as if the canvas was a div?

I would like that. It may be necessary to distinguish whether the canvas was marked with role=presentation or not. Without role=presentation, it would make sense in my opinion if the AT would recognize the canvas as a graphic and output it as graphic. However, the content of the canvas element should then be output normally. Similar to a region or group, the screen reader could, for example, announce the beginning and end of the graphic (if possible, with a label, which is assigned by aria-label, for example).

In other words, the various browse-mode/document-mode shortcuts should work in the same way as they do when there is no canvas. Currently, they don't

With JAWS and Chrome, they all work, but the output is not correct because "graphics" are output with each navigation step (with arrow keys), even if the canvas was marked with role=presentation.