Repository navigation
python.microbit.org/v/beta: Keyboard focus navigation doesn't work well #347
Description
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.
Metadata
Metadata
Assignees
Labels
No labels
Activity
microbit-carlos commentedon Nov 13, 2020
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 commentedon Nov 13, 2020
Not sure I fully understood that, is the issue that this is not visually highlighted, but it is captured selectable via keyboard?
microbit-carlos commentedon Nov 13, 2020
@microbit-mark has run this tests in the past, are these known issues? Or have we introduced any regressions?
martinwork commentedon Nov 13, 2020
Navigation with Tab steps to the Save and Add file buttons that are inside Show Files, even when they are not visible.
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 commentedon Nov 17, 2020
@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.
Thanks for the clarification, I've opened #354 for this.
microbit-mark commentedon Nov 17, 2020
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.
We use the
aria-expandedattribute to notify to a screenreader whether the status is expanded or notPythonEditor/editor.html
Line 109 in fa1f994
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 commentedon Nov 17, 2020
Okay, I've opened #355 for the "x" button issue.
microbit-mark commentedon Nov 17, 2020
The screenreader should read the
aria-labelfor 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 commentedon Nov 23, 2020
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 commentedon Nov 25, 2020
Okay, I think we can consider this part of the accessibility changes we have in the backlog, including moving those
Thanks for all the testing Martin!