Open joanmarie opened 5 years ago
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?
The ARIA Working Group just discussed canvas
.
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>
.
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
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.
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.
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".