Re: SVG Accessibility API Mappings -- Building the Accessibility Tree

A couple more complications to factor in:


The pointer-events property.

SVG elements can have visibility:hidden and still be interactive, by
setting pointer-events to, e.g., "painted" or "all".  A common use case is
to define large invisible but clickable data points over top of smaller
drawn data points (which are inaccessible to mouse events because of the
layer over top).  Any scripted behavior or title tooltips would be attached
to the invisible layer.


Animations.

CSS and SMIL animations can change the visibility property.  SMIL
animations can change the display property and the pointer-events
property.  Which means they need to be factored in as modifications to the
accessibility tree.

Which leads into the question of: Should ARIA properties be animatable?
E.g., should you be able to change the label or description using SMIL
animation?  Or states like aria-live and aria-expanded?

If these properties cannot be set with SMIL, this seriously constrains the
ability to make any SMIL-based interactive SVG  accessible.  You would
always need JavaScript to change the aria states and properties.