python.microbit.org/v/beta: Keyboard focus navigation doesn't work well

[martinwork]

Tested in IE10, Chrome, Safari

Keyboard focus navigation of the toolbar works, but it's not always obvious where the focus is (tested on IE10)

In the "WebUSB" modal, I can't navigate to the Close X. Esc works.

In the Load/Save modal, Tab goes to hidden "Save" and "Add file", after "Show Files",
and Shift-Tab from "Or browse for a file" traps the focus in the code behind.

Safari with voiceover on doesn't seem to helpfully run through the toolbar buttons.
Arrow keys step through each letter of toolbar button names.
Lots of "link newline"s, e.g. after Connect
Load/Save dialog moves to invisible buttons, like IE10 and Chrome.

[microbit-carlos]

In the "WebUSB" modal, I can't navigate to the Close X. Esc works.

Sounds like it should be something reachable via keyboard, but I'm not sure.
@microbit-mark do you know if the close button is meant to be reached via keyboard? The escape key works, but maybe we need to make the cross reachable as well?

[microbit-carlos]

In the Load/Save modal, Tab goes to hidden "Save" and "Add file", after "Show Files",
and Shift-Tab from "Or browse for a file" traps the focus in the code behind.

Not sure I fully understood that, is the issue that this is not visually highlighted, but it is captured selectable via keyboard?

[microbit-carlos]

Safari with voiceover on doesn't seem to helpfully run through the toolbar buttons.
Arrow keys step through each letter of toolbar button names.
Lots of "link newline"s, e.g. after Connect
Load/Save dialog moves to invisible buttons, like IE10 and Chrome.

@microbit-mark has run this tests in the past, are these known issues? Or have we introduced any regressions?

[martinwork]

In the Load/Save modal, Tab goes to hidden "Save" and "Add file", after "Show Files",

Navigation with Tab steps to the Save and Add file buttons that are inside Show Files, even when they are not visible.

and Shift-Tab from "Or browse for a file" traps the focus in the code behind.

As a second issue, when "Or browse for a file" has the focus, hitting Shift-Tab (i.e navigate previous) moves the focus into the code text window behind the modal. Once that has happened, the focus cannot be moved.

[microbit-carlos]

In the Load/Save modal, Tab goes to hidden "Save" and "Add file", after "Show Files",

Navigation with Tab steps to the Save and Add file buttons that are inside Show Files, even when they are not visible.

@microbit-mark do you know if this is okay? Assuming visually impaired users might not know if something is shown or hidden this could be good? Not sure.

and Shift-Tab from "Or browse for a file" traps the focus in the code behind.

As a second issue, when "Or browse for a file" has the focus, hitting Shift-Tab (i.e navigate previous) moves the focus into the code text window behind the modal. Once that has happened, the focus cannot be moved.

Thanks for the clarification, I've opened #354 for this.

[microbit-mark]

In the "WebUSB" modal, I can't navigate to the Close X. Esc works.

Sounds like it should be something reachable via keyboard, but I'm not sure.
@microbit-mark do you know if the close button is meant to be reached via keyboard? The escape key works, but maybe we need to make the cross reachable as well?

This is an accessibility issue with the vex modal I think. The X is a div and not a button. It has been addressed here HubSpot/vex#134 but not integrated and I think if this is the vex that we are using, it hasn't been updated in some time.

Our workaround to make it at least closeable was to make ESC close the error modals #310

But ideally, it should work as expected.

In the Load/Save modal, Tab goes to hidden "Save" and "Add file", after "Show Files",

Navigation with Tab steps to the Save and Add file buttons that are inside Show Files, even when they are not visible.

@microbit-mark do you know if this is okay? Assuming visually impaired users might not know if something is shown or hidden this could be good? Not sure.

We use the aria-expanded attribute to notify to a screenreader whether the status is expanded or not

PythonEditor/editor.html

Line 109 in fa1f994

<button aria-labelledby="show-files" aria-expanded="false" type="button" class="action save-button show" id="show-files" title="{{ show-files }}">{{ show-files }} &nbsp;<i class="fa fa-caret-down"></i></button>

I think this is okay as long as the user can still focus on the elements even if they are not shown on screen. The status can be switched on Enter, which I think is fine.

[microbit-carlos]

Okay, I've opened #355 for the "x" button issue.

[microbit-mark]

Safari with voiceover on doesn't seem to helpfully run through the toolbar buttons.
Arrow keys step through each letter of toolbar button names.
Lots of "link newline"s, e.g. after Connect
Load/Save dialog moves to invisible buttons, like IE10 and Chrome.

@microbit-mark has run this tests in the past, are these known issues? Or have we introduced any regressions?

The screenreader should read the aria-label for the menu items. I think ideally these should be buttons rather than anchors as the buttons are accessible.

Safari and Mac (I think) disable A11y options by default, so you have to enable it to run the test in Safari.

You have to enable tab to highlight each item

Can you try with voiceover and that setting enabled @martinwork

[martinwork]

Selecting this option makes the Tab key work. The arrow keys still produce the behaviour that seemed confusing. The left/right arrow keys seem to be independent of the tab order. They read out the text in a button one letter at a time. After the last letter, it says things like "link, newline" and draws boxes round areas of the toolbar that make no sense to me.

[microbit-carlos]

Okay, I think we can consider this part of the accessibility changes we have in the backlog, including moving those

and elements into more semantic that we can style the same and should work much better with these accessibility tools.

Thanks for all the testing Martin!