search

w3c / aria-at

Assistive Technology ARIA Experience Assessment
https://aria-at.netlify.app
Other
153 stars 28 forks source link

Feedback: "Navigate backwards to a menu button" (Action Menu Button Example Using aria-activedescendant, Test 6, V22.03.17) #1057

Open cookiecrook opened 4 months ago

cookiecrook commented 4 months ago

Description of Behavior

For the following test, I see Failures reported as:

Shift+Control+Option+Command+J Results: 2 passed, 2 failed VoiceOver for macOS Response: Run Test Setup dimmed button You are currently on a button. This item is dimmed."

But I get passing results.

"First form element, Actions, menu pop up button"

Perhaps a version difference.

Test Setup

cookiecrook commented 4 months ago

Two results in that test should be updated to Passed:

MUST Role 'menu button' is conveyed Failed MUST Name 'Actions' is conveyed Failed

mcking65 commented 4 months ago

@cookiecrook

We are currently refactoring and re-running this test plan. We should have current data in a few weeks.

However, we have observed this same behavior in some other test plans. It would be very helpful if you could review V24.03.12 of Command Button Example Test Plan. We advanced this new version of the command button plan to candidate review on April 16. Two testers found the same kind of failure in test 2 when navigating backward to a button with shift+J. They both tested with VoiceOver for macOS 14.4 and Safari 17.4.0 .

It seems that if focus is set programmatically just before the shift+j command is performed, the command does not behave as expected. All other commands do behave as expected. Note: the 'Run Test Setup' button sets focus on a link that is after the button in the DOM order so that testers can then navigate backward to the button.

cookiecrook commented 4 months ago

That Test Plan link results in "Whoops! Unable to complete request."

cookiecrook commented 4 months ago

@mcking65 wrote:

It seems that if focus is set programmatically just before the shift+j command is performed, the command does not behave as expected.

Going on the one linked in the main Reports page, if you are talking about VoiceOver reading through the contents of the new Window instead of remaining on the script-focused button, you'd need to change the VO Utility default setting in:

I believe the test plan needs an update... After all, what this is intended testing is "Does VO+Shift+J or QN Shift+J work? (a.k.a., 'jump to previous form control')", and it clearly does work. The failure listed in this scenario appears to be an invalid assumption in the test case, or else you're seeing entirely different results than I am.