SVG primitives and role=button

frankelavsky commented 2 years ago

I want to be able to use role=button in combination with aria-pressed=true||false on an SVG primitive. NOTE: I also want to be able to use aria-selected as well but we will only be testing role=button for now (which is not compatible with aria-selected).

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

Notes: parent structure above the button is also an unknown. It is possible that some parent semantics will affect button and aria-pressed performance.

Should we use region -> group -> button? Figure -> group -> button? Graphics-document -> graphics-object -> button? Menu? Tree? Grid? Treegrid?

How do we make these elements accessible to keyboard-only users (users that do not leverage a screen reader)? tab-index, wrapped in an <a> element, javascript and custom keypress handling?

Expectations:

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 a SR will announce the aria-label correctly.
We expect that a SR will be able to toggle the element on or off.
We expect that a SR will announce the toggle state correctly when navigated to.
We expect that a SR will announce the toggle state correctly when changed.
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).

frankelavsky commented 2 years ago

I would ideally expect all possible combinations to work unless there is something somewhere that notes otherwise. I am also very curious how a text SVG primitive will perform across testing cases.

frankelavsky commented 2 years ago

This example should be ready for an initial pass of testing. One thing we want to consider as well: javascript-driven interactivity/navigation and not just a bunch of tab indices. But to keep the scope of testing small, we will just use tab index.

frankelavsky commented 2 years ago

I removed the dropdown in 499a8092d7396eba562d73fb53c0d7503b603314, but we may want to bring it back for this particular test based on the results of other tests. I also simplified the semantics/roles for this test as well in 32a46fbac4ccd75f2e304b450f3e7b2f2884952a.

frankelavsky commented 2 years ago

It is possible that tabindex is helping SRs navigate/recognize SVG elements with role=button -- we may want to consider including a toggle to add or remove the tabindex attribute from elements. If this works without any hiccups in testing, then I have some unanswered questions. Several other charting libraries out there utilize tabindex=-1, which could indicate that the attribute may be required even when javascript is used for navigation. Cc'ing @shepazu

shelbyelavsky commented 2 years ago

@frankelavsky After our conversation about the test and my initial findings, I was wondering if you could update the "Interaction instructions" to be more specific? For example,

"Move into the chart using TAB for keyboard only. If using a screen reader, navigate as normal. Then press SPACEBAR on an element to select it."

shelbyelavsky commented 2 years ago

@frankelavsky Hi! Mentioning the bug we found in the code that needs to be fixed. The aria pressed attribute is toggling on the parent element in the HTML section.

frankelavsky commented 2 years ago

Hi @shelbyelavsky, the issue with toggling should be fixed now. Thanks for the heads up!

shelbyelavsky commented 2 years ago

I'm noting here that there is a difference in behavior for the role=button test environment if you press TAB versus using a screen reader's built in navigation keys. It produces different results.

Since our goal is to focus on how SRs interact and explore SVGs, I will only be testing/recording using each screen reader's default arrow keys to navigate.

shelbyelavsky commented 2 years ago

Important note with VoiceOver and Safari: Pressing SPACE versus pressing VoiceOver's Control+Option+SPACE produces slightly different results. While they are similar - VO states "selected" when using their key press setting.

Therefore, I am using VoiceOver's default Control+Option+SPACE for selecting/interacting with the toggleable buttons during my tests.

shelbyelavsky commented 2 years ago

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

fizzstudio / svg-aria-test

SVG primitives and role=button #23

NVDA and Chrome

NVDA and Firefox

VoiceOver and Safari

JAWS and Chrome