developpeurweb
commented
3 years ago This might be a dupe of #10172, but this one is newer and has a better, more visual explanation.
Open developpeurweb opened 3 years ago
developpeurweb
commented
3 years ago This might be a dupe of #10172, but this one is newer and has a better, more visual explanation.
Exemplified with the Units section, but Accessible Pattern needs to work in ALL similar scenarios in My Company,
Other issues found on video: https://video.sap.com/media/t/1_o07yiw6z See minute 1:14. Back tabbing will get focus on the pagination section. The expectation is for the focus to go back to the opening title (row).
This is still an issue as of March 29th, 2021. There have been other attempts to fix this, like in GH-9531, but the scope of the fix was limited to specific sections and keyboard flow is incomplete.
IMHO, this needs some reflection and to be reapproached from a different angle, since this will become a major issue for Screen Readers if not fully addressed. Sorry in advance for the long writing, but it's needed for context.
As I browse the UI, either with mouse or keyboard, I'm trying to find a design pattern correspondence for the current My Company layout arrangement... so, in an effort to describe it to a screen reader user, I ask myself what would I say this arrangement is?
For a mouse user, it's clear this is a table with collapsible rows; both horizontally and vertically.
Keyboard-only navigation sets the foundation for Screen Readers (SR), but considerations work the other way around too. The existence of well-defined and standard design patterns that the SR will pick up automatically suggests that looking at this issue from the SR perspective might help us find an optimal keyboard flow.
Now, our layout currently has an uncommon accessible pattern, but again IMHO, rather than a table, this can be presented to the SR user as a tab group or
role="tablist"of vertical tabs, being the Unit Names, and the panels being the Unit Details side. Then followed by collapsible menu buttons (the carets).If we ride along with the tab group idea, its corresponding keyboard interaction would be: First TAB keypress gets the user into the tab group, focus lands on the first tab title (Rustic), this opens the corresponding panel automatically (only when using the keyboard), SR announces: "Rustic Active, selected, tab, 1 of 3, All Units, tab group". Now aware this is a tab group, the SR user could TAB again and go into the panel, or could use the DOWN ARROW to go to the next item: the caret button. The SR then says: "Rustic Menu, menu pop up expanded, button", the user continues to use DOWN ARROW to reach the next tab since it’s already expanded, then the SR says: "Rustic Retail Active, selected, tab, 2 of 3", the user wants to check the details here, therefore presses ENTER or SPACEBAR to open the corresponding right panel, then hits TAB to go into such panel, and keeps hitting TAB to explore focusable items inside the panel. When done exploring, the user presses SHIFT+TAB to go back until reaching the tab title, refocusing on the list of tabs again, from there, uses ARROWS to continue up or down to other tabs.
In so many words, and by removing what the "SR says", the result is the Accessible Pattern with its Keyboard flow.
A couple of Accessible Pattern examples here below, with their corresponding SR vocalizations.