ARIA role="form" on contextual menu buttons is unnecessarily verbose and misleading for screen readers

Thanks @rolivero_nfb for your first Drupal bug report!

This is one of the buttons provided by Contextual Links module. Every block in Drupal gets one of these buttons when the Contextual Links module is enabled, such as in the Standard install profile.

Moving this issue to the correct component.

@rolivero_nfb I've added some headings to the issue summary. We have an issue summary template which uses headings for things like proposed resolution, to make things easier to read.

This is really useful feedback to help us get a more aurally usable interface (AUI). Thanks again @rolivero_nfb for your participation. I look forward to working on issues with Core & Webform in the future.

This one is a no-brainer, we should just remove role="form".

The div doesn't actually contain anything that resembles a form. A drop-down menu button doesn't warrant the form role.

This will make a good first-time contribution, maybe during the upcoming Global Contribution Weekend 2019 later this month.

Would it be appropriate or useful to include the group role to group the menu button controls?

I'm not sure if it would be too verbose in NVDA.

I don't think the group role will be any use here either - one button doesn't amount to a group, any more than it amounts to a form. We should avoid using ARIA where it doesn't have a useful purpose.

We added a lot of ARIA to D8, at a time when ARIA support was patchy and inconsistent. Nowadays it's more widely supported, and the use cases and practices are better understood, so it's worth asking whether we have used ARIA well. There are a number of other places we can improve ARIA usage, so I've linked a parent issue for this.

It's been a long time since I rolled a patch, but I think this might be what we're looking for here.

I'm a bit worried about this comment (that I removed) in that it seems that this had a purpose:
- // Use aria-role form so that the number of items in the list is spoken.

That said, I'd like to see this get resolved quickly if we can. I don't want to rush this if it isn't ready, but it is worth noting that Rachel Olivero died this week. She added this issue at DrupalCon Baltimore in a Code Sprint. She came back to DrupalCon Nashville and participated in accessibility discussions there.

This is @andrewmacpherson's inspiration, but I just want to help nudge it along.

Adding before/after images via SimplyTest.me.

Thank you, @andrewmacpherson for the explanation. I was confused about the group role because I thought it also grouped the menu links.

I tested the patch on simplytest.me on Windows 10 NVDA 2018.4 (listening).

I logged in as admin, I first let the screen reader present to me the page content. I was presented with user account menu list with two items when the screen reader finished presenting the administration toolbar.

I also tried the steps in the issue summary by skipping to reading the heading levels using the "h" shortcut. It presented to me the user account heading level 2. I pressed the down arrow and it presented to me the configuration options as a button without mentioning the form. I pressed the down arrow again and it presented to me the list items (My account).

Next I used VoiceOver on MacOs Sierra in Safari (listening) to repeat the issue summary steps.

I logged in as admin, I pressed the VoiceOver keys (control + option) + Command + h to skip to the User account heading level 2. It presented me with the user account menu heading. I pressed down, and it presented me with reading individually the My Account heading text. I pressed down, and it presented me with the configuration options without mentioning the form. I pressed down, and it read the My account link.

The patch in #14 seems to be working as expected.

I do not have access to any other screen readers.

re #14:

// Use aria-role form so that the number of items in the list is spoken.

Yeah, I was curious about that too. It sounds rather unusual that the form role would affect how a list was announced.

The form role and that comment were added in comment patch #66 at #849926-66: links wrapped in .contextual-links-wrapper divs are not accessible at all via keyboard alone also problems with screen readers. Jessebeach gives an explanation for removing an aria-live behaviour, but doesn't explain the addition of the form role or the mysterious comment about the number of items in the list. (I went up a level in Git finding that! The JS files have moved around a lot since then.)

Meanwhile Rachel's bug report here only addresses the form role, and doesn't mention the list items at all.

The earlier issue that added the form role and comment was committed 6 years ago, and it seems to have been tested with VoiceOver only. I think it's worth testing this again with a variety of browser + AT combinations, in case we're missing a useful quirk. In any case, aria support itself has moved on a lot since then.

Fixing tags

Further to #14 and #17... the mysterious comment about the form role affecting the way lists are announced.

I've taken this for a drive in a good range of browser/screenreader combinations: IE/JAWS, IE/NVDA, Firefox/NVDA, Chrome/JAWS, Chrome/NVDA, macOS/Safari/VO, macOS/Chrome/VO.

I've used tabbing between controls, and browse mode. I can't see any difference to the way the list of links is announced before or after the patch.

I think the comment is either nonsense, or an out-of-date bug/quirk that has disappeared.

So I think we can safely go ahead and remove the unnecessary form role.

Thank you extensively for testing the accessibility implications of this change. I've confirmed that the role attribute has been removed by this change from the contextual links.

I had to recompile the JavaScript because of the patch #14 wasn't compiled correctly. Here's instructions to compiling JavaScript files.

Committed 253fc6f and pushed to 8.8.x. Thanks!