SVG primitives and graphics-document

[frankelavsky]

I want to be able to use role=graphics-document region in an SVG structure as well as role=graphics-object group and role=graphics-symbol img. These are based off of the WAI-ARIA Graphics Module.

We will need to develop scaffolding for this and also test these semantics across screen readers and browsers.

Notes: parent structure fallback is an unknown. It is possible that some fallbacks (such as region instead of document may produce better/worse outcomes). In addition, testing in isolation (without fallbacks) is recommended.

We would expect:

• We expect that a screen reader (SR) can navigate to each element with a role and aria-label using a keyboard (SVG, g, and all SVG primitives).
• We expect that the visual focus indicator moves to the correct element and has the correct bounding dimensions.
• We expect that the visual focus indicator will remain in view at all times and may even adjust the scroll position of the page while navigating.
• The SVG is labelled by the chart's title and subtitle (these should be read as a single text when navigating to the root element).
• The title and subtitle are hidden from a screen reader because they are announced on their parent element instead. These elements should not be read out loud.
• The elements are grouped in pairs. The screen reader should be able to separately navigate to the group before navigating to each pair.
• Each primitive (rect, circle, path, text) should be accessible by a screen reader and read the number and label for that element.
• We expect that a SR will announce the aria-label correctly for each element, followed by its role.
• The aria label should announce the number, followed by the type of primitive (eg "7 Rect"), even though the text may be displayed viusally in a different order. This is designed intentionally to ensure that the ARIA is working correctly.
• We expect that different SVG primitives (rect, circle, path, text) will be consistent with each other based on previous expectations.
• We expect that the SVG elements will provide the same experience as the HTML elements (below the SVG space).
• We expect that if the main roles are not used, the fallback roles will be (if they are enabled). We are not sure how to design for this initially, but are mentioning it as important.

[frankelavsky]

Should we add a toggle to add/remove the role fallbacks? I feel like it might be important for testing, because the role fallbacks might actually be helping to compensate for issues that might arise with the base roles from the graphics module.

[frankelavsky]

Hi @shepazu, we need some clarification before testing: if a fallback role is supplied, is it correct for a screen reader to announce BOTH roles or only the first valid role?

When the role is "graphics-object group" which is correct role for a screen reader to announce: "graphics-object group" or "graphics-object"?

Voiceover (for example) does "graphics-object group" for our g elements and "image" for our child elements. Notably, Voiceover does "image" whether or not we supply fallbacks. This is very tricky to determine what is the correct treatment here!

CC'ing @shelbyelavsky for testing, since this will affect everything she does on this one.

[shepazu]

Should we add a toggle to add/remove the role fallbacks? I feel like it might be important for testing, because the role fallbacks might actually be helping to compensate for issues that might arise with the base roles from the graphics module.

Both scenarios should be tested. Rather than having a toggle, which adds complexity to the test framework, I suggest simply making 2 different versions of the test, one with fallbacks and one without. These could either be in the same file, or, more cleanly, in different files that refer/link to one another.

[shepazu]

Hi @shepazu, we need some clarification before testing: if a fallback role is supplied, is it correct for a screen reader to announce BOTH roles or only the first valid role?

When the role is "graphics-object group" which is correct role for a screen reader to announce: "graphics-object group" or "graphics-object"?

Voiceover (for example) does "graphics-object group" for our g elements and "image" for our child elements. Notably, Voiceover does "image" whether or not we supply fallbacks. This is very tricky to determine what is the correct treatment here!

CC'ing @shelbyelavsky for testing, since this will affect everything she does on this one.

To my understanding, an SR should only announce a single role, that is, the first one it understands. If it does understand (i.e. implement) graphics-object, then it should announce graphics-object; if it doesn't understand (i.e. implement) graphics-object, then it should announce group.

_Note that this is also the intent and interpretation by Steve Faulkner, who I trust implicitly; but also note that this may or may not be the behavior of SRs, at least as of 2015, as noted in that link. This is also described (obliquely) in the W3C spec._

We can test this with the behavior on an HTML element, with graphics-object group, or with another more well-known ARIA role like role="switch checkbox" (as mentioned by Faulkner). We may even want to have a small test for just that, to set baseline behavior for fallback treatment.

[shelbyelavsky]

I'm adding the recorded test videos for each browser/screen reader combinations here for easy access.

NVDA and Chrome

https://user-images.githubusercontent.com/98043076/156835042-b1ef1420-5484-4474-990c-cfdd7eb3e9b6.mp4

NVDA and Firefox

https://user-images.githubusercontent.com/98043076/156835048-a7fbec88-272e-4950-97d8-4d47ab49e14b.mp4

VoiceOver and Safari

https://user-images.githubusercontent.com/98043076/156835064-52c07616-ec7f-48af-993f-57a70e8a7650.mp4

JAWS and Chrome

https://user-images.githubusercontent.com/98043076/156835013-f2eb0274-b5c3-49d8-bd94-f5c895db3bf2.mp4