Question about how role="separator" is supposed to work in Menu widgets

[brooksienoodlesoup]

Hi,

I was checking the ARIA Landmarks Examples pages you all have put together, and I was particularly interesting in the way that your developer has implemented the "Skip to" dropdown menu, which is coded up as a Menu widget ala the ARIA Authoring Practices 1.1.

Specifically, I liked the way you used role="separator" on two of the <li> elements in the dropdown menu to visually distinguish groups of menuitems. I was excited to browse this dropdown menu with some UA/AT combos. I was disappointed that only 2 of the 6 UA/AT combos even announced the presence of a separator, and only one combination announced a separator and its label. Here are those results:

• E11+JAWS18 - No announcement of separator or separator label
• IE11+NVDA2017.4 - No announcement of separator or separator label
• FF56+JAWS18 - No announcement of separator or separator label
• FF56+NVDA2017.4 - Proper announcement of both separator and separator label (had to toggle Insert+Space to get the announcement to work)
• Chrome64+JAWS18 - No announcement of separator or separator label
• Chrome64+NVDA2017.4 - Proper announcement of separator, but no announcement of separator label (had to toggle Insert + Space to get the announcement to work)

So here's my question, is the role="separator" element supposed to be announced along with a label (if provided) by UA/AT, but just isn't yet supported by software manufacturers yet? It is very limiting to use this design pattern if we can't group menuitems into labeled groupings that are announced by AT. I guess I could just prepend the category name in sr-only text to the menuitem label as a hack, by that verbose option creates a less than stellar user experience for AT users.

I have included a screenshot of the dropdown menu under review with this issue.

Thanks for your feedback!

[css-meeting-bot]

The Working Group just discussed Purpose and intended effect of separators in menus.

The full IRC log of that discussion

<AnnAbbott> TOPIC: Purpose and intended effect of separators in menus
<jamesn> https://github.com//issues/614
<AnnAbbott> mck: Different level of support with AT/Browsers
<AnnAbbott> mck: should separators be labeled?
<jamesn> q+
<AnnAbbott> mck: may need to update example if label for separator is important
<AnnAbbott> mck: make it an accessible object?
<jamesn> q+ to suggest we don't worry about this in 1.1 and concentrate on it for 1.2
<jemma_ku> +1 Jame's suggestion
<AnnAbbott> bg: not focusable but works like a fieldset
<jamesn> ack me
<Zakim> jamesn, you wanted to suggest we don't worry about this in 1.1 and concentrate on it for 1.2
<AnnAbbott> jn: focus on this for 1.1.3
<AnnAbbott> mck: change needed in 1.2 spec?
<AnnAbbott> jn: see if anything from example implies change needed to spec
<jamesn> s/1.1.3/1.2/
<AnnAbbott> mck: not expected to be announced by Screen reader
<AnnAbbott> mck: do not prepend name as hack:?
<AnnAbbott> jn & mck: No
<AnnAbbott> mck: for #614: do not expect screen reader to announce and do not prepend name
<AnnAbbott> mck: coming in 1.2: use group role inside menues and label
<AnnAbbott> mck: APG 1.2 rework example to label separator
<jamesn> GitHub: https://github.com//issues/614
<AnnAbbott> mck: affect posinset or setsize?
<AnnAbbott> jn: can't affect them

[mcking65]

@brooksienoodlesoup, sorry for the long delay here. :(

Here are answers to your questions.

Is the role="separator" element supposed to be announced along with a label (if provided) by UA/AT, but just isn't yet supported by software manufacturers yet?

It would be announced only in a reading mode, bnot a forms or focus mode, because it is not a focusable element and is not designed to provide semantic separation of groups.

It is very limiting to use this design pattern if we can't group menuitems into labeled groupings that are announced by AT.

The way to do that is with the group role, which is going to be supported in ARIA 1.2. ARIA 1.2 is now a draft and is targetted to become a recommendation at the end of 2019. We will have examples of this in menus soon, perhaps for the next working draft of 1.2, later this year. It is very likely this will be supported by screen readers long before 1.2 becomes a recommendation.

I guess I could just prepend the category name in sr-only text to the menuitem label as a hack, by that verbose option creates a less than stellar user experience for AT users.

Right, that is not a great experience! Please do not do that!

For now, if a group really needs a label, the best way is to put a group of menuitemradios in its own submenu.

Closing this issue. Please re-open if you feel it is not adequatly addressed.