<div dir="ltr"><div>Hi Anita,</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><b style="font-family:Calibri,sans-serif;font-size:16px">Q1. Do you expect to be able to drop a menu from a control with the AT announcement “<label> button collapsed?”</b></blockquote><div> </div><span style="color:rgb(0,0,0);font-family:HelveticaNeue;font-size:12px">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. </span><div><font color="#000000" face="HelveticaNeue"><span style="font-size:12px"><br></span></font></div><div><font color="#000000" face="HelveticaNeue"><span style="font-size:12px">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. <br></span></font><span style="color:rgb(0,0,0);font-family:HelveticaNeue;font-size:12px"><br></span><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">There are 2 schools of thought for navigating within a preview gallery:<ol start="1" type="a" style="margin-bottom:0in;font-size:12.8px;margin-top:0in"><li class="gmail-m_6349373638934862844MsoNormalCxSpMiddle" style="margin-left:0.5in"><span style="font-size:12pt">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.</span></li></ol><ol start="1" type="a" style="margin-bottom:0in;font-size:12.8px;margin-top:0in"><li class="gmail-m_6349373638934862844MsoNormalCxSpLast" style="margin-left:0.5in"><span style="font-size:12pt">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.</span></li></ol><b>Q2. Which do you expect/prefer?</b></blockquote><div> </div><p class="MsoNormal" style="margin-left:0.5in;font-size:12.8px"><u></u></p><div><span style="color:rgb(0,0,0);font-family:HelveticaNeue;font-size:12px">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. </span></div><div><b style="font-family:Calibri,sans-serif;font-size:12pt"><br></b></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><b style="font-family:Calibri,sans-serif;font-size:12pt">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?</b></blockquote><div><ol start="3" type="1" style="margin-bottom:0in;font-size:12.8px;margin-top:0in"></ol></div><div><span style="color:rgb(0,0,0);font-family:HelveticaNeue;font-size:12px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:HelveticaNeue;font-size:12px">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. </span></div><div><span style="color:rgb(0,0,0);font-family:HelveticaNeue;font-size:12px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><b style="font-size:12.8px">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?</b></blockquote><div><span style="color:rgb(0,0,0);font-family:HelveticaNeue;font-size:12px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:HelveticaNeue;font-size:12px">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. </span></div><div><b style="font-size:12.8px"><br></b></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><b style="font-size:12.8px">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?</b></blockquote><div><ol start="5" type="1" style="margin-bottom:0in;font-size:12.8px;margin-top:0in"></ol></div><div><font color="#000000" face="HelveticaNeue"><span style="font-size:12px"><br></span></font></div><div><font color="#000000" face="HelveticaNeue"><span style="font-size:12px">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. </span></font></div><div><font color="#000000" face="HelveticaNeue"><span style="font-size:12px"><br></span></font></div><div><font color="#000000" face="HelveticaNeue"><span style="font-size:12px">Consistency is key here.</span></font></div><div><b style="font-family:Calibri,sans-serif;font-size:12pt"><br></b></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><b style="font-family:Calibri,sans-serif;font-size:12pt">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?</b></blockquote><div> </div><div><ol start="6" type="1" style="margin-bottom:0in;font-size:12.8px;margin-top:0in"></ol></div><div><span style="font-size:12px;color:rgb(0,0,0);font-family:HelveticaNeue">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. </span></div><div><b style="font-size:12.8px"><br></b></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><b style="font-size:12.8px">Q9. Do you expect disabled controls to be focusable even though they are not executable, or do you expect to skip over disabled controls?</b></blockquote><div><b><br></b></div><div>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. </div><div><br></div><div>However it could go either way. If there are many disabled buttons, it might be better to skip over the disabled buttons.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><b style="font-family:Calibri,sans-serif;font-size:16px">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?</b></blockquote><div><br></div><div>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</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><b style="font-family:Calibri,sans-serif;font-size:16px">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?</b></blockquote><div><br></div><div><a href="https://www.w3.org/TR/wai-aria-practices-1.1/#spinbutton">WAI-ARIA Authoring Practices </a>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)</div><div><br class="gmail-Apple-interchange-newline">Although we commonly usually navigate between elements with tabs, unless it's in a toolbar (where we navigate between controls with left/right arrow <a href="https://www.w3.org/TR/wai-aria-practices-1.1/#toolbar">Toolbar spec</a> )<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><b style="font-family:Calibri,sans-serif;font-size:16px">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?</b></blockquote><div><br></div><div>I would expect it to stay on the control after pressing enter. Staying consistent with my previous suggestions.  </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><b style="font-family:Calibri,sans-serif;font-size:16px">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?</b></blockquote><div><br></div><div>I would expect it to stay on the control after pressing enter. Staying consistent with my previous suggestions.  </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <b style="font-size:12.8px">Q16. Do you expect disabled controls to be focusable even though they are not executable, or do you expect to skip over disabled controls?</b></blockquote><div><br></div><div>See my answer for Q9</div><div><br></div><div>Thanks,</div><div>Alex </div><p class="MsoNormal" style="font-size:12.8px"><u></u> </p><div>-- </div><div><br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div><div><font size="4"><b>Alex Mooc</b></font><br></div></div><i>UW-IT Accessible Technology Services Student Assistant<br>Human Centered Design & Engineering Undergraduate</i> <br></div></div></div></div></div>
</div></div></div>