(In reply to comment #0)

Are you sure about the order? Seems like it should be after " Select On". And instead of " Sync Locked" be " Sync-Lock On" to be consistent with the others?

(In reply to comment #1)
> instead of " Sync Locked" be " Sync-Lock On" to be consistent with the others
+1 It sounds rather like "Sync Locked Select On" otherwise.

Created attachment 330 [details]
patch

(In reply to comment #1)
> (In reply to comment #0)
> 
> Are you sure about the order? Seems like it should be after " Select On". And
> instead of " Sync Locked" be " Sync-Lock On" to be consistent with the others?

No, I wasn't sure about the order. I've asked for views on the order and the wording on the Audacity4blind mailing list - in particular from the person who requested the feature.
The preference is for it to come after Select On, and for it to be called
"Sync Locked".

I've updated the patch, primarily to include a comment about the absence of a dash.

(In reply to comment #4)

>> Are you sure about the order? Seems like it should be after " Select On". And
>> instead of " Sync Locked" be " Sync-Lock On" to be consistent with the others?
> 
> No, I wasn't sure about the order. I've asked for views on the order and the
> wording on the Audacity4blind mailing list - in particular from the person who
> requested the feature.
> The preference is for it to come after Select On, and for it to be called
> "Sync Locked".
> 
> I've updated the patch, primarily to include a comment about the absence of a
> dash.
> 

Thanks, David. Something as small as this, you needn't bother updating the patch. 

I feel strongly that it's important for it to be consistent with the others, so I've committed " Sync Lock On" instead. Thanks for doing a survey, but you've probably heard me rail against design-by-vote, especially just a few votes. 

Regarding the dash, doesn't that mean it should also be removed from the button in EditToolBar::Populate() and EditToolBar::RegenerateTooltips()?

(In reply to comment #5)
> I feel strongly that it's important for it to be consistent with the others, 
> so I've committed " Sync Lock On" instead.
FWIW, I too finally decided as result of that discussion that "Sync Locked" was probably better than "Sync Lock On", providing it was the last item. The reason is that "IsSyncLockSelected" is not a state indicator for when Tracks > Sync-Lock Tracks is checked, but wording it as "Sync Lock On" quite strongly implies that it is.

Personally I think "Sync Locked" also implies to some extent that the icon is a state indicator for Tracks > Sync Lock Tracks, and I prefer "On" in the phrase for the reasons you do... 

Is "Sync Select On" viable? I can't think of anything else that isn't potentially misleading, but of course if people would read the Manual, it wouldn't matter.

(In reply to comment #6)

Thanks. Changed to " Sync Lock Selected", which is what it actually indicates for the particular track.

(In reply to comment #7)
> (In reply to comment #6)
> 
> Thanks. Changed to " Sync Lock Selected", which is what it actually indicates
> for the particular track.

I think this is too verbose, and confusing having more than one "selected" read out after a track name.
In particular, using NVDA if sync lock tracks is on, and a track is not selected, but one or more tracks in the group are selected, then for that track nvda reads:
"track name sync lock selected row not selected".
I don't think this is usable.

(In reply to comment #5)
> (In reply to comment #4)
> 
> >> Are you sure about the order? Seems like it should be after " Select On". And
> >> instead of " Sync Locked" be " Sync-Lock On" to be consistent with the others?
> > 
> > No, I wasn't sure about the order. I've asked for views on the order and the
> > wording on the Audacity4blind mailing list - in particular from the person who
> > requested the feature.
> > The preference is for it to come after Select On, and for it to be called
> > "Sync Locked".
> > 
> > I've updated the patch, primarily to include a comment about the absence of a
> > dash.
> > 
> 
> Thanks, David. Something as small as this, you needn't bother updating the
> patch. 
> 
> I feel strongly that it's important for it to be consistent with the others, so
> I've committed " Sync Lock On" instead. Thanks for doing a survey, but you've
> probably heard me rail against design-by-vote, especially just a few votes.

But they are some of the users who will be affected by your decisions.

> 
> Regarding the dash, doesn't that mean it should also be removed from the button
> in EditToolBar::Populate() and EditToolBar::RegenerateTooltips()?

I don't think it's a big issue in these cases. I didn't want the dash in text following the track name because it gets read out many times and would become irritating.
By default Jaws doesn't read out tool-tips, and I suspect few users turn them on, because it becomes too noisy.
Users of screen readers will probably use the tracks menu for the sync-lock tracks setting, but again, I don't think this is a big issue.

(In reply to comment #8)
>> Thanks. Changed to " Sync Lock Selected", which is what it actually indicates
>> for the particular track.
> I think this is too verbose, and confusing having more than one "selected" 
> read out after a track name.
I did not suggest "Sync Lock Selected" mainly because of verbosity. 

> In particular, using NVDA if sync lock tracks is on, and a track is not
> selected, but one or more tracks in the group are selected, then for that
> track nvda reads:
> "track name sync lock selected row not selected".
> I don't think this is usable.
In pure meaning, it makes clear that track will be affected by an edit in a selected track in that group. But the way it is read out and parsed by the user will vary. 

If we want to, lets compare (NVDA):

David's idea:
"track name select on sync locked row" 
"track name sync locked row not selected".

My suggestion: 
"track name select on sync select on row" 
"track name sync select on row not selected".

Current:
"track name select on sync lock selected row"
"track name sync lock selected row not selected".
 
All have pluses and minuses - the possible confusion with mine is two "select on"'s for the selected case. If it was "Sync On" or "Syncing On", it may be too much like the rejected "Sync Lock On". 

I think the current is the worst of the three due to the verbosity. I think David's may be the best we can do.

(In reply to comment #9)
> Regarding the dash, doesn't that mean it should also be removed from the
> button in EditToolBar::Populate() and EditToolBar::RegenerateTooltips()?
I would think the dash is important for meaning, and FWIW, NVDA does not read the dash in the button name or tooltip.

(In reply to comment #10)

>>> Thanks. Changed to " Sync Lock Selected", which is what it actually indicates
>>> for the particular track.
>> I think this is too verbose, and confusing having more than one "selected" 
>> read out after a track name.
> I did not suggest "Sync Lock Selected" mainly because of verbosity. 

It's the same number of words as yours, one more than David's. "Verbose" is defined by Webster's as "containing more words than necessary", not more characters. 

If character count is your actual complaint, it's only 4 more than yours, 7 more than David's. Given the examples below, that's not verbose, or excessive on character count. 

I think yours, "sync select on", lacking the "lock", is confusing and inaccurate. There's no such thing as "sync select". And "on" is incorrect because it's not a flag on the track like the others, it's the track's status among other tracks. 


In fact, for the GetSelected() result, I think it should be "Selected", or "Is Selected", not "Select On".

I've never seen a GUI element referred to as being "select on" or "select off" -- the terminology is that it's "selected" or not.


> 
>> In particular, using NVDA if sync lock tracks is on, and a track is not
>> selected, but one or more tracks in the group are selected, then for that
>> track nvda reads:
>> "track name sync lock selected row not selected".
>> I don't think this is usable.
> In pure meaning, it makes clear that track will be affected by an edit in a
> selected track in that group. But the way it is read out and parsed by the user
> will vary. 
> 
> If we want to, lets compare (NVDA):
> 
> David's idea:
> "track name select on sync locked row" 
> "track name sync locked row not selected".

I agree with your previous point that "sync locked" is not accurate to what this means, which is IsSyncLockSelected().


> 
> My suggestion: 
> "track name select on sync select on row" 
> "track name sync select on row not selected".
> 
> Current:
> "track name select on sync lock selected row"
> "track name sync lock selected row not selected".

But we could also have a situation like: 

"track <name> mute on solo on select on sync lock selected row not selected" 

-- so to me the real issue is run-on without pause or conjunction, not the shear number of words. How about putting in "and", so it would be 

"Track <name> has mute on and has solo on and is selected and is sync lock selected and row not selected"

...? That's far more comprehensible. 


"row not selected" is generated from NVDA, it's not our code. What "row" are they talking about anyway? And why is is just "row" rather than "row selected"?

(In reply to comment #12)

> [...]
> But we could also have a situation like: 
> 
> "track <name> mute on solo on select on sync lock selected row not selected" 
> 
> -- so to me the real issue is run-on without pause or conjunction, not the
> shear number of words. How about putting in "and", so it would be 
> 
> "Track <name> has mute on and has solo on and is selected and is sync lock
> selected and row not selected"
> 
> ...? That's far more comprehensible. 

...or even: 

"Track <name> is muted, soloed, selected, and sync lock selected. Row not selected."

That cuts verbosity, makes a comprehensible sentence, and separates the "row" wordings we cannot control.

Thanks for the ideas, Vaughan.

>> I did not suggest "Sync Lock Selected" mainly because of verbosity. 
> It's the same number of words as yours, one more than David's. "Verbose" is
> defined by Webster's as "containing more words than necessary", not more
> characters. 
David knows more about screen readers than I do, but I suspect characters, or more likely syllables are what makes readers verbose. David's idea "sync-locked" has two syllables, mine has four and yours has five. We need to remember that VI users will go up and down each track dozens of times and be read out to each time.   


> There's no such thing as "sync select". 
Al frequently used the term "sync-selected" as a contraction for "Sync-Lock Selected" ( http://tinyurl.com/8txgnx9 ) ; that's what I was driving at. 


> And "on" is incorrect because it's not a flag on the track like the others,
> it's the track's status among other tracks. 
> 
> In fact, for the GetSelected() result, I think it should be "Selected", or
> "Is Selected", not "Select On".
> 
> I've never seen a GUI element referred to as being "select on" or "select off"
> -- the terminology is that it's "selected" or not.
I thought you liked "On", and that "Select on" was correct for screen readers. Personally I would rather hear "selected", especially as in NVDA I hear "not selected" for the opposite case. 

Are there any official accessibility guidelines we should follow for what text to give to screen readers? Should we specify text for the unselected case (see below about Narrator). 


> But we could also have a situation like: 
>
> "track <name> mute on solo on select on sync lock selected row not selected" 
> 
> -- so to me the real issue is run-on without pause or conjunction, not the
> shear number of words. How about putting in "and", so it would be 
>
> "Track <name> has mute on and has solo on and is selected and is sync lock
> selected and row not selected"
> 
> ...? That's far more comprehensible. 
>
>...or even: 
>
> "Track <name> is muted, soloed, selected, and sync lock selected. Row not
> selected."
> 
> That cuts verbosity, makes a comprehensible sentence, and separates the "row"
> wordings we cannot control.
I suspect the example with "has" and "and" has far too many syllables. 

Just from my experience with NVDA and Narrator with different speech settings, syllables and spaces are run together or drawn out rather arbitrarily. For example "Sync Lock Selected" on my copy of NVDA sounds like "Sync <pause> Lock Selected", but I don't in Narrator the pause is after "Lock". So I'd like David's views on how helpful trying to construct a comprehensible sentence would be in practice.      


> "row not selected" is generated from NVDA, it's not our code.
This may be the problem - every screen reader is going to do its own thing. Will we ever be able to give all readers a comprehensible sentence they will read in the same way? 

* NVDA - although we have "Select On" above "Sync Lock Selected" in TrackPanelAx.cpp, NVDA sticks "row not selected" at the end, *after* "Sync Lock Selected". 

* Narrator - for a second track (but not a first track) "is" is added (but not if Solo is on).
** So, an unselected second track that is Sync-Lock Selected (without Solo on) is read "is Sync Lock Selected" (but no mention of "not selected", "Select Off" or any other phrase about selected state). 
** A selected second track that is also Sync-Lock Selected (without Solo on) is read (sounds like) "is Select On Sync Lock <pause> Selected". 
** For any audio track, Narrator says "Zero Rows" and "Zero Columns".

(In reply to comment #14)

> Thanks for the ideas, Vaughan.

Just trying to help. I don't know about screen readers. 


> 
>>> I did not suggest "Sync Lock Selected" mainly because of verbosity. 
>> It's the same number of words as yours, one more than David's. "Verbose" is
>> defined by Webster's as "containing more words than necessary", not more
>> characters. 
> David knows more about screen readers than I do, but I suspect characters, or
> more likely syllables are what makes readers verbose. 

It's still not "verbose". "Syllablose"? :-)

Anyway, that's for David to comment on before we consider it a criterion. 


>David's idea
> "sync-locked" has two syllables, mine has four and yours has five. 

Okay, so mine is only slightly different from yours on that measure, and more accurate than both. If you add "lock" to yours, the syllable count is the same.



>We need to
> remember that VI users will go up and down each track dozens of times and be
> read out to each time.   

Can't they cut the readout short by just moving up and down? They don't have to listen to the whole thing each time, do they? 

If I'm right, they probably just want to bounce around the name readouts until they find the track for which they want to hear the whole thing. 


> 
> 
>> There's no such thing as "sync select". 
> Al frequently used the term "sync-selected" as a contraction for "Sync-Lock
> Selected" ( http://tinyurl.com/8txgnx9 ) ; that's what I was driving at. 

Yeah, well Al referred to that one feature by half a dozen or so different names, inconsistently, in different places. (That thread link is 2.5 years old.)

That's why, after he left Audacity, as part of my effort to fix the bugs it still had, I lobbied for one term for that one feature. And why, after we all agreed on that, we did all those changes to code and docs. You know that history, right? Let's not regress to that terminological sloppiness and confusion. 


> 
> 
>> And "on" is incorrect because it's not a flag on the track like the others,
>> it's the track's status among other tracks. 
>>
>> In fact, for the GetSelected() result, I think it should be "Selected", or
>> "Is Selected", not "Select On".
>>
>> I've never seen a GUI element referred to as being "select on" or "select off"
>> -- the terminology is that it's "selected" or not.
> I thought you liked "On", 

Do you mean Comment 1? At that time, I was just starting to look at this, and was just saying it should be consistent with the existing. Having thought about it further and looked at it more broadly, I think "selected" is better for both of them. And the "-ed" form (e.g., "muted") for all of them. 


> and that "Select on" was correct for screen readers.
> Personally I would rather hear "selected", especially as in NVDA I hear "not
> selected" for the opposite case. 

I have no idea about screen reader standard wordings, but it seems you agree with me, and at least NVDA does, too. :-)


> [...]
> 
>> But we could also have a situation like: 
>>
>> "track <name> mute on solo on select on sync lock selected row not selected" 
>>
>> -- so to me the real issue is run-on without pause or conjunction, not the
>> shear number of words. How about putting in "and", so it would be 
>>
>> "Track <name> has mute on and has solo on and is selected and is sync lock
>> selected and row not selected"
>>
>> ...? That's far more comprehensible. 
>>
>> ...or even: 
>>
>> "Track <name> is muted, soloed, selected, and sync lock selected. Row not
>> selected."
>>
>> That cuts verbosity, makes a comprehensible sentence, and separates the "row"
>> wordings we cannot control.
> I suspect the example with "has" and "and" has far too many syllables. 
> 
> Just from my experience with NVDA and Narrator with different speech settings,
> syllables and spaces are run together or drawn out rather arbitrarily. 

If that's just bad precedent (and I don't see how "arbitrarily" is any kind of precedent), we need not follow it, we should do better than that. If it's screen reader inability to do natural phrasing, we can't do anything about it, but my suggestions should help, because they make it more easily parsed grammatically, despite phrasing. 


>For
> example "Sync Lock Selected" on my copy of NVDA sounds like "Sync <pause> Lock
> Selected", but I don't in Narrator the pause is after "Lock". So I'd like
> David's views on how helpful trying to construct a comprehensible sentence
> would be in practice.

Yes, of course, David's input is crucial. 


> 
> 
>> "row not selected" is generated from NVDA, it's not our code.
> This may be the problem - every screen reader is going to do its own thing.
> Will we ever be able to give all readers a comprehensible sentence they will
> read in the same way? 

But we should do the best we can with what we control. Not currently the case, imo. 

I'm still curious what "row" it's referring to, or why it's "row not selected" vs "row" (instead of "row selected"). 


> 
> * NVDA - although we have "Select On" above "Sync Lock Selected" in
> TrackPanelAx.cpp, NVDA sticks "row not selected" at the end, *after* "Sync Lock
> Selected". 

? 

Yes, of course. The "row" stuff is generated after TrackPanelAx::GetName(). As I wrote, we cannot control that. 



> 
> * Narrator - for a second track (but not a first track) "is" is added (but not
> if Solo is on).

That's Narrator, or at least it's not from TrackPanelAx::GetName(). Again, something I think we cannot control. But it shows there's some precedent for making the readouts be sentential.


> ** So, an unselected second track that is Sync-Lock Selected (without Solo on)
> is read "is Sync Lock Selected" (but no mention of "not selected", "Select Off"
> or any other phrase about selected state). 

Yeah, the existing code in TrackPanelAx::GetName() added only the "on" states. We can easily make it do the "off" states. 

That's separate from the mysterious Narrator second-track "is" you've added to the discussion.


> ** A selected second track that is also Sync-Lock Selected (without Solo on) is
> read (sounds like) "is Select On Sync Lock <pause> Selected". 

I have no idea why the pause is there. Processing? In the code, it's a single space, as are the others, so I don't think we can control that. 


> ** For any audio track, Narrator says "Zero Rows" and "Zero Columns".
> 

Okay, but I still don't know what either of those is referring to.

>> David's idea "sync-locked" has two syllables, mine has four and yours 
>> has five. 
> Okay, so mine is only slightly different from yours on that measure, and 
> more accurate than both. If you add "lock" to yours, the syllable count is 
> the same.
If we accept five syllables, we may just as well have "Sync Lock Selected" which is what it is. I like that, but I doubt it is practical for screen readers (unless we can exert a lot of control), hence I accepted David's view.  

> If I'm right, they probably just want to bounce around the name readouts until
> they find the track for which they want to hear the whole thing. 
To some extent, that's quite correct. You can move the focus to the next track and the screen reader stops reading the last track and starts reading the next. But the user will still be landing on the destination track to be worked on many times. User must listen to each track carefully to be aware if it's selected (and/or Sync-Lock Selected) or not. Unless user has a great memory they will probably need to do that several times, and may well repeat the navigation through all the tracks if they change which tracks are selected. 


> At that time, I was just starting to look at this, and was just saying it 
> should be consistent with the existing. Having thought about it further and 
> looked at it more broadly, I think "selected" is better for both
> of them. And the "-ed" form (e.g., "muted") for all of them. 
Certainly "-ed" for the muted and solo buttons is consistent. Maybe not practical in all cases. NVDA reads "soloed" as "sollowed" (to rhyme with "followed"). Plus, I would want to know if there is any accessibility guideline that suggests a state button should be read as "On" when down. (If so, the "Sync-Lock" button in Edit Toolbar is not compliant). 


> David's input is crucial. 
We can agree on that. David? 


>> ** So, an unselected second track that is Sync-Lock Selected (without Solo 
>> on) is read "is Sync Lock Selected" (but no mention of "not selected", 
>> "Select Off" or any other phrase about selected state). 
> Yeah, the existing code in TrackPanelAx::GetName() added only the "on" states.
> We can easily make it do the "off" states. 
Again, I think we need David's input e.g. on JAWS which is a major player. If most readers don't mention a state when it's off (VoiceOver on Mac is another that doesn't say if not selected) then there could be an objection to adding words which are taken for granted (by users of that reader).   

----

Just to note, VoiceOver does not read "Sync Lock Selected" when the icon is in the Track Control Panel (whether the track is selected or not).

@David:  is this very old bug still valid?

(In reply to Peter Sampson from comment #17)
> @David:  is this very old bug still valid?

No.