can we do some light reshaping of how controls in the Peak Watcher GUI are named to shore up UX across screen readers?

[ScottChesworth]

Navigating the "Hold level" grouping of Peak Watcher's GUI reports differently with NVDA, JAWS and VoiceOver. While absolute consistency probably isn't possible, I'm thinking perhaps there's a way to clarify the UX with some light reshaping of language and one role tweak. Jotting down notes here best I can with a limited technical understanding. If someone can point me at where these controls are named, I'd be happy to sit with the screen readers and twiddle until I get some sort of improvement.

These are the current issues I'm aware of:

1. The edit field that becomes navigable once our radiobutton in this group is set to "for (ms)" doesn't have an accName yet. This causes NVDA to just report "edit" (not a huge deal because what's expected there is only one control away), but with VO navigation that's less clear IMO, and JAWS decides to report "When level reaches" there which is just... er... wrong. Would adding an accName of "Hold for ms" solve this?
2. I think forward and backward navigation through the tab order would be clearer with these language tweaks:

• "Hold level" becomes "Hold level until:"
• "until reset" becomes "the user resets this watcher"
• "for (ms):" becomes "a given amount of time passes"

3. Could we also add an accelerator to the edit field where ms is specified? H seems logical if we go with the accName suggestion above.

Obviously these suggestions make reports longer, but IMO the increased clarity for newcomers is a worthy trade. Power users are familiar enough with this GUI by now that I'm pretty sure it won't slow them down.

Thoughts?

[jcsteh]

1. The reason the ms field is unlabelled is that it's effectively labelled by the radio button. It's also inside the Hold for: grouping. I can label it, but that also means we'll have a redundant label visually, since I can't assign non-visual labels in a cross-platform way. I guess that's better than the alternative though.
2. I originally considered labelling the group "Hold level until:". However, this means that for the Disabled option, you get "Hold level until disabled", suggesting that the level is held until the watcher is disabled, which is precisely the opposite of what it does.

[jcsteh]

Btw, I'm curious as to why the unlabelled field is less obvious with VO navigation, given that it's right next to the ms radio button?

[ScottChesworth]

I'm curious as to why the unlabelled field is less obvious with VO navigation, given that it's right next to the ms radio button?

It's not. Here's a chronological list of how VO reports controls in the dialog with settings at their default states, starting from where focus lands then moving with VO+RightArrow:

• Follow when last-touched track changes (check box)
• Level type (label)
• Level type (popup button)
• 1 (check box)
• 2 (check box)
• Notify automatically for channels (label)
• Disabled (reported as a radio button, but behaves different from expected, see list of gotchas later in comment)
• Hold level (label)
• Until reset (radio button selected by default)
• For: ms (radio button)
• When level reaches (label)
• 0.00 (contents selected, edit text)
• Dimmed (text, this being the field that becomes active when "for: ms" radio button is checked, in which case the "dimmed" disappears and we just hear "text").

Now let's go back to the default landing position and navigate the tab order instead, this is also slightly different on Mac:

• Follow when last-touched track changes (check box)
• Peak dB (popup button)
• 1 (check box)
• 2 (check box)
• Disabled (radio button)
• Until reset (radio button selected by default)
• For: ms (radio button)
• 0.00 (contents selected, edit text)
• Then straight on to Reset button, the edit field for ms doesn't appear in the tab order at all until the relevant radio button is selected (same behaviour as Windows, IE working as intended).

So here's what I'd perceive to be Mac specific gotchas, some worth poking at, some not:

1. Labeling isn't reported when navigating via the tab order. That's a VO thing, not our lookout. IMO tightening up VO navigation should be what we focus on if we're gonna put any time into refining this.
2. It's confusing that the "Level type" text label prepends the control, whereas all other labels come after controls with VO navigation. The prepended ordering as we have it on Windows and with "Level type" on Mac is a lot more intuitive. Is it possible for other labels to appear like that? To put it another way, can we ascertain why the controls don't show up in the same order as they do when navigating by object in Windows?
3. ON Windows, the "When level reaches" edit field appears before the group of radio buttons. On Mac, it's after with both navigation approaches, thus separating the ms field when that's visible/available to be populated.
4. With VO, although radio buttons are reported as radio buttons, they aren't navigable like in native dialogs. Our radio buttons appear as individual items in the tab order and aren't selectable with unodified arrows. Contrast this against how the radio buttons appear on the General tab of the Privacy and Security pane in System Prefs. Is this a Swell issue perhaps?
5. If the only hang up on adopting the language suggested in my prior comment is the "Disabled" radio button, would you be open to axing the Disabled setting? Seems like that could happen without losing functionality, a hold time of 0ms would do the same thing right?

I know this is long and I'm not expecting all of it to be possible, just figured it would be useful to have the current Mac UX thoroughly documented.

[jcsteh]

2. It's confusing that the "Level type" text label prepends the control, whereas all other labels come after controls with VO navigation. The prepended ordering as we have it on Windows and with "Level type" on Mac is a lot more intuitive. Is it possible for other labels to appear like that? To put it another way, can we ascertain why the controls don't show up in the same order as they do when navigating by object in Windows?

I have no idea. The order in Windows is the order in which they're specified in the code. SWELL (or Mac or VoiceOver) must be reordering them, but I don't know why. That's really screwed up.

4. With VO, although radio buttons are reported as radio buttons, they aren't navigable like in native dialogs. Our radio buttons appear as individual items in the tab order and aren't selectable with unodified arrows. Contrast this against how the radio buttons appear on the General tab of the Privacy and Security pane in System Prefs. Is this a Swell issue perhaps?

I'd say so. I certainly can't control it with what's available to me.

5. If the only hang up on adopting the language suggested in my prior comment is the "Disabled" radio button, would you be open to axing the Disabled setting?

That's how things originally were, but the decision to have these radio buttons (including Disabled) was made very intentionally due to user feedback. See #63. So, I don't think I'm open to this unless you can convince me that the arguments in #63 no longer hold. :)

[ScottChesworth]

I forgot the move to radio buttons was motivated by user confusion. Neither of us want more of that, so I guess we're keeping the Disabled option.
Hmm, maybe I have another idea. What does Disabled do exactly? Does it fall back on one of REAPER's metering related settings in the Track Control Panels category of Prefs, or does it opperate independently and really not hold peaks at all?

[jcsteh]

OSARA implements holding levels itself using a timer. Disabled... disables that. :) REAPER metering isn't involved here (beyond being a source of raw data).

[ScottChesworth]

Gotcha. I think the label ordering is probably a bigger UX issue than the language, do you agree? If so, maybe it's worth getting Justin to have a look at whether anything SWELL is doing can be tightened up. I could send him short reproduction steps to illustrate the differences. If he wants to see code, where should I link to?

[jcsteh]

The fact that the unlabelled ms field causes problems for JAWS isn't great, and it seems it isn't great for VO either. So, I do think we should probably fix that.

As for the ordering, it's probably worth asking Cockos if they can tighten that up, yeah. Here's the code in question.

Before you do that, though, it'd be worth double checking with a custom Mac build whether our translation code is interfering somehow. To do that, just comment out the single call to translateDialog in peakWatcher.cpp and rebuild. It really shouldn't interfere, but that code is a bit obscure, so I want to be sure.

[ScottChesworth]

Oki doke. I don't have a local Mac environment here at the moment, will have to comment that line and send it as a PR for AppVeyor to build.

[ScottChesworth]

Holy lack of standardization Batman. I've been experimenting now I know where to find the code (muhahahaha).

1. JAWS ignores our GROUPBOX labels in the tab order and doesn't read the title bar when a watcher dialog is open. It also super helpfully steps in to change initial selection in the Peak Watcher context menu, because convenience is King (unless you find it convenient to hear some context in your tab orders, that is).
2. Narrator ignores GROUPBOX labels entirely, no matter whether you're tabbing or navigating objects. It manages to read the title bar though. Gee, thanks Narrator.

So that's 4 screen readers, 4 ridiculously different takes on the same code. Who programs these tools, and what do they have against consistent UX? I'd install Supernova and ZDSR to try those, but I'm not due a full mental breakdown until the weekend.