Re: UAIG Menu events

Comments inline:

On Thu, Oct 31, 2013 at 3:59 PM, Joseph Scheuhammer <clown@alum.mit.edu> wrote:
> Comments inline:
>
>
> On 2013-10-31 3:11 PM, Alexander Surkov wrote:
>
> Hi, Rich. Few notes:
>
> Row1. Phrase: "Menubar must a DOM parent of the menuitems or one defined by
> aria-owns" not sound are part of specific scenario. It relates to all
> scenarios so probably it makes sense to move it out of table.
>
>
> Yes and no.  There are situations that involve menus without a menubar.  Two
> examples are a menu that is invoked from a toolbar button, and a context
> menu that is triggered from "white space".
> - Rows 1, 2, and 5 describe a scenario involving a menubar.
> - Toolbar button and context menu popup/dismiss are handled by rows 3 and 4.
> - Rows 3 and 4 also handle a menu associated with a menubar.
> - Row 2 currently only speaks about focus on a menuitem in a menubar, but
> the same occurs when focus is on a on a menuitem within a menu.  The text
> could be modified to reflect both scenarios.
>
> That said, the idea of moving the statement regarding the parent/child
> relationship with menubar/menuitems is okay with me.  Here is the suggested
> text:
>
> "Frequently, a menubar is used organize a hierarchy of menus.  In those
> cases, the menubar MUST be a DOM parent of the associated menuitems, or one
> defined by aria-owns.  In other cases, no menubar is involved as the menu
> may be associated with a toolbar button, or may be a context menu triggered
> from white space. Nonetheless relevant menu events are fired as described in
> the following table".

Good

> Row3. "Should only be fired once until the menu is closed and opened again"
> sounds excess because a menu can't be open twice without closing.
>
>
> Sigh.  Sometimes readers complain that the spec. language isn't complete and
> leaves too much for the reader to decide what it's saying.  Other readers
> complain that the language is "too excessive".  IMO, if the excess
> reinforces the point, I'm for keeping it as leaves less room for
> (mis)intrepretation.
>
>
> Row4. "EVENT_SYSTEM_MENUPOPUPEND once only for accessible menu object and
> only if EVENT_SYSTEM_MENUPOPUPSTART was fired for it. Second part sounds
> unnecessary because menupopup can't be hidden without being opening.
>
>
> See my previous comment.

I'd agree if I had an example how these words can be read ambiguously.
Anyway, if theoretically I've got an open menu that never received a
menupopup_start event then why would AT care it must not receive
menupopup_end on its close?

> Row5. "All menus closed, and user moves focus away from menubar; menubar is
> deactivated." What is propose of "all menus closed"? What if menus were
> never be open?
>
>
> Maybe that's why there was both a row 5 and row 6 in the previous version?
> There are two possibilities:
> 1.  User navigates to a menubar, navigates among its menuitems never opening
> a menu, and finally navigates away from the menubar.
> 2.  User navigates to a menubar, navigates among its menuitems, opens at
> least one menu, and possibly more than one, and finally navigates away from
> the menubar.
>
> I believe the events are the same for these two scenarios in terms of what
> events are fired when the user finally navigates away from the menubar.  I
> could modify the text describing the scenario such that is covers these two
> cases.

I think the key point here is menubar is deactivated, i.e. focus moves
out of menubar tree and it doesn't really matter how the user achieved
that. Having said that I think it might be good to cite those two
examples as clarification.

>
>
> Thank you.
> Alex.
>
>
> Thank you.
>
>
> --
> ;;;;joseph.
>
>
> 'A: After all, it isn't rocket science.'
> 'K: Right. It's merely computer science.'
>              - J. D. Klaun -

Received on Thursday, 31 October 2013 20:19:32 UTC