Discussion of the application of roles such as listbox, checkbox, and textbox

[microbit-robert]

Check for duplicates

• I have searched for similar issues before opening a new one.

Description

It feels like roles such as listbox, checkbox and textbox may be incorrectly applied in the workspace. Elements with the listbox role work to some extent in that Space / Enter opens the dropdown, but the down arrow does not open the dropdown and typing characters does not open the dropdown or change its value. Typing when focused on something with the role of textbox has no effect. You have to press Enter / Space before focus is actually moved into an element that supports entering text.

Are elements that currently have these roles more like buttons to enable the editing of a field and should they have different semantics?

Reproduction steps

1. Go to the screen reader test page
2. Navigate to the width field of the create canvas block
3. The screen reader will announce "edit text" as a result of the textbox role being applied to the element, but at this point, typing characters to change the value of the field has no effect. Is this misleading?

Stack trace

Screenshots

No response

Browsers

No response

[BenHenning]

There seem to be two parts to this issue:

1. A general question of whether some of the roles are set up incorrectly, particularly for fields.
2. There are some expected default behaviors like typing-to-search in a combo box.

(1) is definitely the case, and is the premise for #9301 and its children (thus I'm marking this a child of that issue, though other sibling issues need to be resolved before this can be directly addressed).

(1) and (2) will both need to be reevaluated once fields have correct roles setup to determine if there's anything more to do here. It may be the case that some of this "just works" once the roles are correct, but I'm doubtful (at least for (2)) which means further discussion and work will be needed.

[BenHenning]

#9384 is working to address basically all of the role and ARIA structure inconsistencies that #9301 is tracking. I still need to reevaluate the solution in the framing of (2) above, but I still suspect that the shortcuts will not work out-of-the-box due to Blockly overriding basically all keyboard behaviors. The important question here is how much these shortcuts behave as part of the reader vs. expected to be handled by the application as part of the ARIA specification (and if there are any cases where it's reasonable for us to intentionally not follow the specification).

[BenHenning]

I've had some time to think about this issue more specifically, and here are my current thoughts:

It is not exactly obvious to me what users are going to expect when interacting with elements that have these (and other) ARIA roles that we're utilizing. It seems that the ARIA spec doesn't actually mandate specific keyboard interactions, but there is the APG (WAI-ARIA Authoring Practices Guide) which has recommendations for specific keyboard interactions. This is a tricky balance for us, and I think we should generally try to implement the keyboard interactions that don't interfere with general keyboard navigation. The reason for this is that Blockly is a far more complex navigation environment than most web apps which has led to us needing custom keyboard navigation in the first place. There are a lot of aspects of our approach to ARIA and generally a11y support that obviously fall outside the APG, and this particular domain (keyboard interactions) is part of that.

This begs the question of which interactions should actually be considered? @microbit-robert mentioned a few cases that seemed useful, though even these aren't precisely recommended in the APG: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/ describes multiple versions of combobox including how it's being used in Blockly. While it details how to handle autocomplete, it doesn't even recommend autocomplete in particular. That leaves autocomplete as completely up to our discretion from a UX perspective (and one that's probably worth considering). However it does outline a number of keyboard navigation recommendations, some of which should already work today (up/down arrows through the list), and others which don't and that we would not want to implement since they would interfere with broader keyboard navigation, e.g. down arrow opening the list box.

From looking through the APG I get the sense that we're largely following the recommendations for keyboard interactions except where we are deliberating not doing that, but a more comprehensive audit should be completed before closing this issue.

There's a separate question that comes up from this as well: why use one role vs. another such as button (which is asked in the issue's opening comment). My thinking on this is that every role has a fairly significant amount of context implied with it to the point that readers may use the role as an actual verbal hint to the user (ChromeVox, for example, reads out most roles as part of the focused node's readout). This could introduce confusion if we're using a role for an unexpected interaction (such as a button for a combobox). It's this reason that I think it makes sense to start with the most specific role that we can and adjust only if it introduces specific confusion or compatibility issues (we're noticing that, for example, specific combinations of Mac VoiceOver with Chrome can result in tree items completely misbehaving in the screen reader which could fundamentally change our approach for blocks and the workspace structure).

Would love to hear additional thoughts from you @microbit-robert or anyone else.

[microbit-robert]

I'm of the opinion that things like dropdowns and checkboxes might be fine with their associated combobox and checkbox roles because the user's actions and the expected results are going to be the same if not very similar, e.g., hit Enter, dropdown opens. It's certainly worth testing this with users and getting feedback as to whether the actions available vs the actions that are suggested to be available from the screen reader output match their expectations.

However, I don't think the role of textbox should be applied to an SVG <g> element when the user cannot edit text or type to insert characters. I think this will cause confusion. Currently, when you navigate to a field, you are told you can edit text, but you can't. Hit Enter on a field, you're then told you can edit text for a second time - this time you can type. I don't think this can be considered a good experience for the user. There is also an inconsistency with how fields and block comments work in this respect. With block comments, there's no hint that you can edit text until you are inside the text area.

[BenHenning]

I'm of the opinion that things like dropdowns and checkboxes might be fine with their associated combobox and checkbox roles because the user's actions and the expected results are going to be the same if not very similar, e.g., hit Enter, dropdown opens. It's certainly worth testing this with users and getting feedback as to whether the actions available vs the actions that are suggested to be available from the screen reader output match their expectations.

I completely agree. I think in those cases that there are inconsistencies we would probably try to fix the shortcuts before changing the role, but it will definitely depend on the feedback that we collect.

However, I don't think the role of textbox should be applied to an SVG <g> element when the user cannot edit text or type to insert characters. I think this will cause confusion. Currently, when you navigate to a field, you are told you can edit text, but you can't. Hit Enter on a field, you're then told you can edit text for a second time - this time you can type. I don't think this can be considered a good experience for the user. There is also an inconsistency with how fields and block comments work in this respect. With block comments, there's no hint that you can edit text until you are inside the text area.

I also agree with this and misunderstood this part in the main comment. I think addressing this will probably be sufficient to address this issue, then.