E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 7 (In chronological order)

From: glen walker
Date: Sat, Mar 06 2021 8:58AM
Subject: aria-expanded menu or dialog?
No previous message | Next message →

I have a "menu" that is a list of links and is implemented well with
aria-expanded on the parent. It basically follows the disclosure widget
pattern. However, they have decided that the list of links that displays
should now cover the entire page. Visually, it kind of makes sense. But
when it covers the page, it's more like a dialog now, sort of.

As a simple aria-expanded menu (without covering the page), you don't have
to constrain the keyboard focus or screen reader focus to the menu. It can
dismiss if you tab off the menu (or press escape) and it can let you
traverse the DOM/AOM of the rest of the page using the arrow keys even if
the menu is displayed.

But if the menu covers the page and sort of looks/acts like a dialog, it's
a lot more work to constrain the keyboard focus and the screen reader
focus. The only real difference is the visual appearance of the menu. It
used to be a simple dropdown but now covers the page. The behavior of the
menu is the same.

I'm struggling with keeping the behavior as if it was a simple menu and
allow the menu (which now kind of looks like a dialog) to dismiss if you
tab off the end of the menu. That's weird behavior for a dialog - a dialog
shouldn't dismiss by tabbing through it. But it's normal behavior for a
menu.

I like to keep the interface as simple as possible. So is this a menu or a
dialog? Or is it a lose-lose situation where no matter which pattern I
use, it's going to be weird for some users?

From: Birkir R. Gunnarsson
Date: Sat, Mar 06 2021 1:15PM
Subject: Re: aria-expanded menu or dialog?
← Previous message | Next message →

What happens when you tab away from the last link in the menu?
Does focus go to the next focusable item on the page or does it go
somewhere else?
I'd say if focus goes to the next focusable item on the page, this can
be presented as a menu. If the menu automatically closes, it's ok (as
long as the aria-expanded attribute of the menu trigger is set
appropriately).
If entering the menu messes with the natural focus order on the page
it's more likely to be some sort of a dialog.


On 3/6/21, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> I have a "menu" that is a list of links and is implemented well with
> aria-expanded on the parent. It basically follows the disclosure widget
> pattern. However, they have decided that the list of links that displays
> should now cover the entire page. Visually, it kind of makes sense. But
> when it covers the page, it's more like a dialog now, sort of.
>
> As a simple aria-expanded menu (without covering the page), you don't have
> to constrain the keyboard focus or screen reader focus to the menu. It can
> dismiss if you tab off the menu (or press escape) and it can let you
> traverse the DOM/AOM of the rest of the page using the arrow keys even if
> the menu is displayed.
>
> But if the menu covers the page and sort of looks/acts like a dialog, it's
> a lot more work to constrain the keyboard focus and the screen reader
> focus. The only real difference is the visual appearance of the menu. It
> used to be a simple dropdown but now covers the page. The behavior of the
> menu is the same.
>
> I'm struggling with keeping the behavior as if it was a simple menu and
> allow the menu (which now kind of looks like a dialog) to dismiss if you
> tab off the end of the menu. That's weird behavior for a dialog - a dialog
> shouldn't dismiss by tabbing through it. But it's normal behavior for a
> menu.
>
> I like to keep the interface as simple as possible. So is this a menu or a
> dialog? Or is it a lose-lose situation where no matter which pattern I
> use, it's going to be weird for some users?
> > > > >


--
Work hard. Have fun. Make history.

From: glen walker
Date: Sat, Mar 06 2021 2:04PM
Subject: Re: aria-expanded menu or dialog?
← Previous message | Next message →

That's why this one is bugging me. It acts like a regular list of links
like a navigation submenu so that's how I'd like it coded, but when they
changed it to cover the entire page, it kind of became a dialog.

My gut feeling is leave the menu behavior and when you tab off the last
item in the menu, have it dismiss and move to the next focusable element on
the page. That's what it did before the change.

And yes, aria-expanded is updated appropriately.


On Sat, Mar 6, 2021 at 1:16 PM Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> What happens when you tab away from the last link in the menu?
> Does focus go to the next focusable item on the page or does it go
> somewhere else?
> I'd say if focus goes to the next focusable item on the page, this can
> be presented as a menu. If the menu automatically closes, it's ok (as
> long as the aria-expanded attribute of the menu trigger is set
> appropriately).
> If entering the menu messes with the natural focus order on the page
> it's more likely to be some sort of a dialog.
>
>
>

From: Birkir R. Gunnarsson
Date: Sat, Mar 06 2021 7:43PM
Subject: Re: aria-expanded menu or dialog?
← Previous message | Next message →

That sounds reasonable to me then. The trick is making sure the focus
order behaves like that of a regular navigation menu, even if the
visual presentation is changed.
If the overlay approach messes with the focus order then, yes, you
have to code it as a dialog.

On 3/6/21, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> That's why this one is bugging me. It acts like a regular list of links
> like a navigation submenu so that's how I'd like it coded, but when they
> changed it to cover the entire page, it kind of became a dialog.
>
> My gut feeling is leave the menu behavior and when you tab off the last
> item in the menu, have it dismiss and move to the next focusable element on
> the page. That's what it did before the change.
>
> And yes, aria-expanded is updated appropriately.
>
>
> On Sat, Mar 6, 2021 at 1:16 PM Birkir R. Gunnarsson <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> What happens when you tab away from the last link in the menu?
>> Does focus go to the next focusable item on the page or does it go
>> somewhere else?
>> I'd say if focus goes to the next focusable item on the page, this can
>> be presented as a menu. If the menu automatically closes, it's ok (as
>> long as the aria-expanded attribute of the menu trigger is set
>> appropriately).
>> If entering the menu messes with the natural focus order on the page
>> it's more likely to be some sort of a dialog.
>>
>>
>>
> > > > >


--
Work hard. Have fun. Make history.

From: Mark Magennis
Date: Mon, Mar 08 2021 2:54AM
Subject: Re: [EXTERNAL] aria-expanded menu or dialog?
← Previous message | Next message →

The way you describe it Glen, it does sound like a bit of this and a bit of that. Obviously it's not a menu in the sense of an ARIA menu because you don't want users to arrow through the links, so you can't use role="menu" because that would set the wrong expectation. It's not a dialog in the usual sense because it's not modal and dialogs are usually expected to be modal. Neither are they expected to contain just navigation links. It's more like a show/hide panel (aka disclosure), but not quite because you want it to disappear automatically when the user leaves it. This is not necessarily a problem as long as you can set that expectation and/or inform the user when it happens so there is no misunderstanding.

But there's one thing that worries me about your desired behaviour which is that you want it to disappear if you Tab out of it but not if you arrow out of it. This makes sense if you're in a widget such as a menu which explicitly uses arrowing for moving within it, but not if you're in a panel of what appears to be standard web content. I can't see that this logic would be predictable and understandable for users because essentially what happens when you leave it depends on how you leave it. Is there any other type of control that works this way? Also, it visually covers everything else on the page. So why would it be left open at all when you are not in it?

Personally, I would make it more like a modal dialog but not an actual dialog with role="dialog" because it's navigation and dialogs aren't usually navigation. I would present it as a pop-up navigation panel by using a <nav> with a descriptive aria-label and aria-hidden. But I would make it completely modal so you cannot Tab or arrow out of it and I would add a close button with a name that explicitly references the panel's name. So it's functionally a dialog but it's announced as navigation and it's clear that to get out of it you have to close it.

An alternative approach would be to use the behaviour you want but provide a name and/or description that informs the user what to expect and how it works. But I often think that if you have to explain how something works then it's too complicated.

Mark

From: Jeremy Echols
Date: Mon, Mar 08 2021 8:12AM
Subject: Re: [EXTERNAL] aria-expanded menu or dialog?
← Previous message | Next message →

I'd strongly advise against having a dialog's behaviors without just calling it a dialog. The screen-reader user has to pay close attention because their focus is suddenly trapped inside a nav element with behaviors that aren't typically used in a nav. I think if it's going to look like a dialog and act like a dialog, it should just be given the role of dialog, even if it is just a set of links.

Personally I think a full-screen list of links in a menu/disclosure is fine anyway, and there's no need to change it to act like a dialog. I don't feel like it matters how much space the thing takes up so long as it's not totally defying all expectations (like a tooltip taking up the full screen, that would be weird). But a list of links that appears when activating something menu-like? That's just a menu (or disclosure), even if it's a huge one.

From: Mark Magennis
Date: Mon, Mar 08 2021 9:37AM
Subject: Re: [EXTERNAL] aria-expanded menu or dialog?
← Previous message | No next message

I get your point Jeremy that my nav element has possibly unexpected behaviour of being modal and requiring the user to specifically close it if they decide not to follow any of the links. But the problem with making it a dialog is that it's not going to look or behave at all like a dialog. Dialogs traditionally have contained a statement or question, possibly some input fields, and one or more choice buttons. I know things have changed and dialogs are often now used for much more functional panels, but still the concept is of a temporary place where you do stuff before returning to where you were on the page. The whole point of navigation is *not* to return to where you were, but to go somewhere else. So I would imagine that closing the panel as you would close a dialog would be an infrequent edge case.