[Athen] Feedback for June: Questions about core controls in the ribbon/menus

[Alexandre Mooc]

Hi Anita,

Apologies for the late reply but see below for my feedback to June's
questions about the Ribbon experience. I have discussed these issues with
Hadi and we are both on the same page. Some of these fall under a grey area
with no clear answer and would be great topics of discussion.



> *Q1. Do you expect to be able to drop a menu from a control with the AT

> announcement “<label> button collapsed?”*



Yes, hearing “collapsed" gives the expectation that it is expandable.
However the drawback of this announcement is that you don’t communicate
what will be expanded upon activation. Are we expanding a section of text,
a tabpannel, a submenu? Hearing something akin to "<label> menu-button
collapsed" builds a better expectation of what will be expanded because the
user now know the nature of the element.

Once inside the gallery, users should expect arrow keys to navigate between
elements. Since the gallery is also a grid, it is important to announce to
screen reader users the nature of the element (a grid) and possible the
dimension of the grid/gallery.

There are 2 schools of thought for navigating within a preview gallery:

>

>    1. The first is to give keyboard users the same experience as mouse

>    users by making each preview gallery item focusable, and therefore

>    interactable via keyboard.

>

>

>    1. The second is to give keyboard users the most efficient experience

>    by only allowing focus on the preview gallery’s button that drops the Menu,

>    so a user must drop the menu before interacting with each gallery item.

>

> *Q2. Which do you expect/prefer?*




Option B seems like a much better option. As you stated, it is much more
efficient this way, especially considering the ribbon already contains many
tab stops. It would eliminates many unnecessary tab stops for
keyboard-users, and for screen reader users it eliminates a lot of noise
that they have to listen to as they navigate the ribbon. Additionally, a
Gallery is similar to a more visually rich menu. Going with option B would
most closely resemble the keyboard interaction for a menu.

*Q3. If each preview gallery item can receive keyboard focus, do you expect

> it to be marked up as a button or a list item?*





Since each preview gallery item is technically a button and part of a list,
ideally I would expect to hear both that it's a button and that it's in a
list.

*Q4. Do you expect to be able to tab to each part of a split button, or for

> the whole control be 1 tab stop?*



There are no set accessible specs that I know of for how split buttons
should behave. As a keyboard user I have grown accustomed to making the
split button a single tab stop and using alt-down to activate the dropdown,
so I would personally prefer to not re-invent the wheel with a new keyboard
interaction.

*Q7. After updating the state of a toggle button via space or enter, do you

> expect focus to stay on the control or for it to return to the canvas?*





I would expect the focus to remain on the toggle button and not move back
to the canvas. I would prefer to not be overly helpful and avoid unexpected
shifts in focus as opposed to saving a few keyboard strokes. If we were to
go with this design, I feel like it would make the ribbon interaction
inconsistent as some buttons would move focus back to the body, while some
others won't.

Consistency is key here.

*Q8. If you keep hitting ‘Arrow Right’ when focus is inside the menu, do

> you expect to eventually leave the combo box and into the next control to

> the right of the combo box (and vice versa)? If not, do you expect ‘Tab’ to

> take you to the next control when focus is inside a combo box?*





No, I would expect arrow right to operate like arrow down. Thinking from a
perspective of a visually impaired user, they would not be able to see if
the menu is vertical or horizontal. So arrow left/up should move to
previous item, and arrow right/down should move to next item. Tab should
close the menu and move focus to next adjacent control.

*Q9. Do you expect disabled controls to be focusable even though they are

> not executable, or do you expect to skip over disabled controls?*



I would personally prefer expect the disabled button to be focusable. As a
visual user, I can see that there is a button but it's disabled. Although
it is disabled, I can still see that it exists. However if we remove that
disabled button from the tab order, a non-visual user would not be relayed
the same information, as they would never reach the button and not even
know there is a disabled button in the first place.

However it could go either way. If there are many disabled buttons, it
might be better to skip over the disabled buttons.

*Q10. After executing a button in a menu via space or enter, do you expect

> (1) focus to stay on the control, (2) close the menu and put focus on the

> flyout anchor, or (3) close the menu and put to the canvas?*



I would expect (2), the focus should go back to the "flyout anchor". In the
web environment, pop-out buttons usually return the focus back on the
control when the user escapes out of the close menu. If the user activates
a menu item, then I also think focus should remain on the flyout anchor
(this goes back to my response to

*Q13. When you hit arrow down to the next menu item and land on a spinner,

> do you expect another arrow down to (1) update the value of the spinner or

> (2) take you to the next menu item?*



WAI-ARIA Authoring Practices
<https://www.w3.org/TR/wai-aria-practices-1.1/#spinbutton>standards states
that spin buttons should be incremented/decremented with arrow up/down. To
stay inline with accessibility standards I would prefer option 1 (update
value of spinner)

Although we commonly usually navigate between elements with tabs, unless
it's in a toolbar (where we navigate between controls with left/right
arrow Toolbar
spec <https://www.w3.org/TR/wai-aria-practices-1.1/#toolbar> )

*Q14. After updating the value of a spinner via typing in the textbox and

> hitting enter, do you expect (1) focus to stay on the control, (2) close

> the menu and put focus on the flyout anchor, or (3) close the menu and put

> to the canvas?*



I would expect it to stay on the control after pressing enter. Staying
consistent with my previous suggestions.

*Q15. After updating the state of a toggle button in a menu via space or

> enter, do you expect (1) focus to stay on the control, (2) close the menu

> and put focus on the flyout anchor, or (3) close the menu and put to the

> canvas?*



I would expect it to stay on the control after pressing enter. Staying
consistent with my previous suggestions.

 *Q16. Do you expect disabled controls to be focusable even though they are

> not executable, or do you expect to skip over disabled controls?*



See my answer for Q9

Thanks,
Alex


-- 

*Alex Mooc*

*UW-IT Accessible Technology Services Student AssistantHuman Centered
Design & Engineering Undergraduate*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman12.u.washington.edu/pipermail/athen-list/attachments/20180109/f7efbd1b/attachment.html>