Inconsistent reporting of checkable list items

[dkager]

Can be reproduced in many lists with checkable items in Windows 10, e.g. the disk clean-up utility.
Uncecked items are brailled as Foo sel ( ) chk, checked ones as Foo (x) sel chk.

[dkager]

According to @LeonarddeR the cause of this inconsistency is that positive states (checked, selected) are brailled before negative states (unchecked). This makes it non-trivial to correct. The priority isn't very high, since all information is still shown, just not in a consistent order.

[LeonarddeR]

Note that this issue isn't braille only, it is reproducible in speech as well.
@dkager, could you change the issue title accordingly?

I think we should consider to discard the selected state for these...

[jcsteh]

Giving this p4, as I think the impact of fixing this is relatively low and the cost to fix is quite high. I think it'd also be quite difficult to come up with good rules here for all possible cases.

[LeonarddeR]

@jcsteh: I looked at the code which should be responsible for this if I get it correctly, and I'm probably missing something, because it seems quite easy to me.

Example: In speech.getSpeechTextForProperties, create a new set.

allStates=positiveStates | negativeStates
for st in allStates:
if st in positiveStates:
stateLabels.append(controlTypes.stateLabels[st])
elif st in negativeStates:
stateLabels.append(controlTypes.negativeStateLabels.get(st, _("not %s")%controlTypes.stateLabels[st]))

[jcsteh]

That definitely solves part of the problem; I didn't think of that. Nice thinking. However, you still need to decide on an order for the states. A set is unordered; you can't rely on the order in any way. I guess you could sort allStates numerically just so the order is determinate.

I was originally wondering whether we need some kind of defined priority order for states; i.e. whether some states (regardless of positive or negative) are more relevant than others. However, we don't have that right now anyway (all positive come before negative), so that could be a future piece of work if needed.

[LeonarddeR]

A set is unordered; you can't rely on the order in any way.

Ah, so that's where I made an incorrect assumption, I thought that a set was always same order based on hash, regardless of the order you'd put them in the set.

So we can do at least two things here:

1. Just implement it like Inconsistent reporting of checkable list items #7076 (comment). I tested this and this fixes the example brought in by @dkager in Inconsistent reporting of checkable list items #7076 (comment)

   Checked: Foo (x) sel chk
   Not checked: Foo ( ) sel chk

2. Do a numerical sort. This way, Output will always be the same, but for the example, it will change order

   Checked: Foo sel (x) chk
   Not checked: Foo sel ( ) chk

[LeonarddeR]

@jcsteh: Having thought some more about this, I think it will be ok if we'd just do a numerical sort of the merged positive and negative states. This might change the order of presentation people are accustomed to in some situations. However, given how python sets work, the consistence of the current behaviour is unreliable anyway.

I'd also like to have your opinion about discarding the selected state for ROLE_CHECKBOX, i.e. does this state make sense in case of check boxes, even when they are part of a list control?

In order to test things, I've enabled showing check boxes in the windows 10 explorer (ribbonn>view tab). I don't belief it is possible to have something selected which is not checked, or something checked which is not selected.

[dkager]

@LeonarddeR Do you mean that you see either "Foo not selected 1 of 10" or "Foo 1of 10", depending on if it is selected? That is, you never see "Foo selected 1 of 10". And you're saying that with a checkable list item that behavior should be the same?

[LeonarddeR]

@LeonarddeR Do you mean that you see either "Foo not selected 1 of 10" or "Foo 1of 10", depending on if it is selected? That is, you never see "Foo selected 1 of 10". And you're saying that with a checkable list item that behavior should be the same?

Here is a more detailed str:

1. In Windows Explorer, press alt+v,h, t to enable item check boxes
2. Go to the desktop
3. When arrowing around the desktop, NVDA will say "Checkbox checked selected" for every item
4. When using object navigation, NVDA will say "check box not checked" for unselected items
5. Holt ctrl and press space multiple times. You Toggle between "checked selected" and "not checked"
6. Open a folder in Explorer.
7. When arrowing around, NVDA will say "Checkbox checked" for every item
8. When using object navigation, NVDA will say "not checked not selected" for unselected items
9. Holt ctrl and press space multiple times. You Toggle between "checked selected" and "not checked not selected"

In both situations above, I think that the selected state can be discarded.

[dkager]

[...]
When arrowing around the desktop, NVDA will say "Checkbox checked selected" for every item

Interesting: it doesn't say that if you have the checkbox display disabled. That's why I thought you only wanted to remove the "selected" state but keep the "not selected" one.

In both situations above, I think that the selected state can be discarded.

I agree, but I am not sure that it can be generalized. In this case it only holds because the definition of the setting is that you can select using checkboxes. But in other programs like Disk Clean-up you could have a list item that is not selected while it is checked. I guess Disk Clean-up is a bad example. In any case, maybe your suggestion can be applied to the Explorer app module?

[jcsteh]

I don't think you can generalise that a check box list item can never be selected. I can't think of usage in the wild, but an example might be a list of things you can enable or disable wherein you can select multiple items and perform a command to "Enable selected" or "Disable selected".

Note that we don't report selected for items which have the selectable state because selected is usually the default from a user perspective. Instead, we report not selected when appropriate.

I haven't tested this, but I'm guessing that when you turn on the Explorer check box selection thingy, items lose the selectable state. That would explain why you hear "selected" in that case.

I agree reporting both doesn't make sense in this Explorer case, but I think that's Explorer specific.

[LeonarddeR]

@jcsteh: Before I ask you to review #7279, may be you can give some hints about where to start to provide unit tests for this? Do you want a unit test only for states, or do you want to have it on a broader scale (e.g. for consistent output of speech.getSpeechTextForProperties)?

[LeonarddeR]

@jcsteh commented:

I was originally wondering whether we need some kind of defined priority order for states; i.e. whether some states (regardless of positive or negative) are more relevant than others.

This is actually very easy to do, and I wonder whether we really should postpone this. For example, I think the invalid entry state has more priority than the required state.

[jcsteh]

@leonardder commented on 24 Jun 2017, 03:15 GMT+10:

@jcsteh: Before I ask you to review #7279, may be you can give some hints about where to start to provide unit tests for this? Do you want a unit test only for states, or do you want to have it on a broader scale (e.g. for consistent output of speech.getSpeechTextForProperties)?

The more unit tests, the better, but for this PR, I'm happy for you to just do unit tests for states. At a minimum, you want to verify that you're achieving what you set out to achieve; e.g. test selected + checked and selected + unchecked.

[LeonarddeR]

Thanks @jcsteh: tests are in b869827

[derekriemer]

@LeonarddeR now that I'm mostly done with an accessible checkable list, is there likelyhood of this being done?

[LeonarddeR]

I belief this is ready for another review. I provided tests as @jcsteh requested. Honestly, this would be a nice to have for #588 as well.