In this article

Because HTML5 doesn't include a way to expose canvas content to accessibility, you should use the CANVAS element sparingly in an accessible app. If you must use CANVAS, we recommend that you use Accessible Rich Internet Applications (ARIA) attributes to describe the nature, behavior, and properties of the canvas. The most straightforward case is when the CANVAS element directly corresponds to a single ARIA role.

Typically, the CANVAS element is dynamic and you need to do more work to make app scenarios accessible. In particular, you need to implement a parallel Document Object Model (DOM) representation that is dynamically tied to the canvas content and stays in sync with it.

In this example, the ARIA grid role provides an alternate representation of a canvas that draws a chess board. The elements in the grid must be maintained from JavaScript as the canvas content changes.

As you design your app, keep in mind that the accessibility solution described here has some limitations. While it ensures the correct UI tree structure, the parallel Document Object Model (DOM) representation is not accessible in all scenarios. For example, hovering over the canvas with the mouse or touch returns only the container DIV element and not the subelements that represent canvas content.

Note The XAML Canvas element is just a Panel with absolute positioning. It doesn't have the issues described here with HTML Canvas. Its children can be read as items and will appear in a Microsoft UI Automation view if they're relevant to app logical structure (Canvas itself is a visual element for layout only and doesn't convey app structure info, so you don't typically see it in a UI Automation view).