Feedback: "Navigate backwards to an expanded disclosure button" (Disclosure Navigation Menu Example, Test 12)

[jha11y]

Description of Behavior

When testing the 'Shift+Control+Option+Command+J' combination, it does not seem to be working correctly. It takes 4 keypresses to get to the about control. I am unsure if this is an issue with the Example or VoiceOver.

MacOS 11.6.2 Safari 15.2

Experienced the same issue on a brand new MacBook. Attaching screen recording

Test Setup

• Test File at Exact Commit: test-12-navigate-backwards-to-expanded-disclosure-button-interaction-voiceover_macos.collected.html
• AT: VoiceOver for macOS (version Latest)
• Browser: Safari (version Latest)

Review Conflicts for "Navigate backwards to an expanded disclosure button"

1. Unexpected Behaviors for "Shift+Control+Option+Command+J" Command

   • Tester jha11y recorded output "Run Test Setup, dimmed button Academics, collapsed, button Admissions, collapsed, button About, Expanded, button" and noted "required 4 keypresses".
   • Tester jongund recorded output "academics, collapsed, button" and noted no unexpected behavior.

2. Assertion Results for "Shift+Control+Option+Command+J" Command and "Name 'About' is conveyed" Assertion

   • Tester jha11y recorded output "Run Test Setup, dimmed button Academics, collapsed, button Admissions, collapsed, button About, Expanded, button" and marked assertion as passing.
   • Tester jongund recorded output "academics, collapsed, button" and marked assertion as failing with incorrect output.

3. Assertion Results for "Shift+Control+Option+Command+J" Command and "State of the button (expanded) is conveyed" Assertion

   • Tester jha11y recorded output "Run Test Setup, dimmed button Academics, collapsed, button Admissions, collapsed, button About, Expanded, button" and marked assertion as passing.
   • Tester jongund recorded output "academics, collapsed, button" and marked assertion as failing with incorrect output.

[jha11y]

https://app.box.com/s/brjrfrvo3493oj3b969hc0exygw73sza

*Need to upload version with sound, apologies

[jha11y]

New version uploaded with same name. Apologies for any background noise.

[jscholes]

@jha11y In my testing, the example seems to be working as expected. However, the video you uploaded doesn't make it obvious (to me as a screen reader user at least) if/when you're pressing the setup button, and what the impact of that is. Could you explain that in more detail please?

For reference, the process should go as follows:

1. The example test case loads, and focus is placed on the setup button.
2. You press the setup button.
3. Focus moves to the "Overview" link.
4. You press the command in the test instructions.

At that point, as your focus is placed on "Overview", and the closest previous control is "About", you should move to "About". I can't be 100% certain, but it seems like you're instead being placed on the setup button again, which is now disabled/dimmed?

If that is the case, and can be reproduced by other people, then WebKit and/or VoiceOver is simply failing the test. I've only tested the example just now on Windows; I will also test on macOS and leave an update here shortly.

[jscholes]

Update: I just tested in Safari latest plus macOS 11, and can reproduce the results you're seeing. Instead of the expected process I outlined in my previous comment:

1. The test case example opens, and focus is automatically placed on the setup button.
2. The setup button is pressed, and focus moves to the "Overview" link.
3. I press VO+Cmd+Shift+J, and focus moves to the disabled/dimmed setup button again, instead of to "About".

Please mark this as a failure.

[jha11y]

Apologies, @jscholes, you are right that I did not provide steps to reproduce. The steps you provided are accurate for what I did. I will ensure I provide text-based steps to reproduce for any further issues.

and yes as you experiences, after pressing the command in step 4, focus goes to the disabled/dimmed setup button.

Curious @jscholes in what Safari MacOS combination did it work correctly?

[jscholes]

@jha11y, you asked:

in what Safari MacOS combination did it work correctly?

The presence and composition of a test within an ARIA-AT test plan does not necessarily indicate anything about the past or present behaviour of screen readers and/or browsers, nor guarantee future behavioural changes. That is, this test was not included because macOS VoiceOver and Safari passed its assertions at some previous point. Rather, the test is included because the asserted behaviour is felt to be a reasonable response to the testing commands and instructions. Conversely, the behaviour that you and I have produced, that fails to meet the assertions included in the test, is not.