The only side affect to this is that the states are announced right at the very end. And this can be very annoying when having to work out if one of them is checked.
Perhaps we could consider having the first column exposed in the name as it currently is, but the rest of the columns exposed in the value?
Or, we could again consider moving states before name for all controls. We used to have a config option for this, but I think its gone now.

Perhaps we could consider having the first column exposed in the name as it currently is, but the rest of the columns exposed in the value?

In my opinion, this makes much sense. We could go for this as part of this pr?

Or, we could again consider moving states before name for all controls. We used to have a config option for this, but I think its gone now.

That's a bit rigorous, though I agree it certainly should be configurable.

Perhaps we could consider having the first column exposed in the name as it currently is, but the rest of the columns exposed in the value?

In my opinion, this makes much sense. We could go for this as part of this pr?

Mmmm. The value is not spoken for checkable list items it seems. I can't find out why not, though.

The value for checkboxes is suppressed, as ROLE_CHECKBOX is in controlTypes.silentValuesForRoles. Even when I remove CHECKBOX from there, the order of speech is "name check box value not checked", which is certainly not the intention here.

Perhaps we could consider having the first column exposed in the name as it currently is, but the rest of the columns exposed in the value?

@michaelDCurran: What do you think about exposing the rest of the columns in the description? It will make the columns silent if one disables reporting of descriptions, but I guess that's an acceptable drawback.

@michaelDCurran In #8858 (comment), I suggested having the first column in the name and the rest in the description. I'm not sure whether I still agree with this suggestion, though. We couldn't make sure that the first column is of more importance than the other columns. In some list view controls, the first column is either empty or an identifier.

It is a bit unclear where this pr is heading to. Any suggestions to bring this forward @josephsl or @feerrenrut?

Would it be possible to special case checkable lists to report role and the state first. This is not ideal, but we have done something similar for reporting selection i.e. selected is reported before selection when gaining focus, but after in all other cases

Would it be possible to special case checkable lists to report role and the state first.

It should be possible, yes. However, not without a whole bunch of refactoring. Currently it isn't quite trivial to swap properties speech.

@LeonarddeR I've tested your code and it is awesome! In addition to the fixes listed in the PR description this also causes proper position info to be reported for these controls, and makes reporting of their full content working regardless of the reporting of description being enabled or not. If the only downside to this is the fact that states are reported at the end I personally would consider it to be a non-issue - the same happens for regular checkboxes and while having it configurable would be nice it should not block this work IMO.

@LeonarddeR Can you update the description please? It currently says:

are presented differently from regular list items.

Can you explain how, with examples? This makes it so much quicker to understand the intent of a PR.

@feerrenrut done. Let me know if you need additional details.

@LeonarddeR could you please add some lines to the user guide about table navigation commands working also in some list views? This would also close issue #3193. Thanks.

I have decided that the disadvantage of the states now being announced later is not a large enough problem to refuse the other benefits of this pr. The order and way we handle states in general does need to be rethought, but I'm happy to merge this pr as is.

That's a good point to have this PR merged to allow table navigation in this type of list. Also this fixes the issue in the file list of Tortoise SVN commit window where hidden column content were read.

However, I think that the "checked" / "unchecked" information should be available earlier; the user should not be forced to wait until NVDA has read the whole line to have this information.
In the "Disk clean-up" window, this is not so much a problem since there are only 2 columns and the second column contains information that is read quickly.
Regarding add-on updater's list, the user has to wait a bit more (3 columns).
And regarding Tortoise the file list in Tortoise SVN commit window, it is still worse (4 columns).

In practice, in tortoise SVN, I will need to press 2 times the space bar to uncheck/check the current item; it is faster than waiting for NVDA to read the whole line.

@michaelDCurran do you agree that these points still need to be discussed, even if we do not reverse this PR. May I open a new issue for this?

Here are also my thoughts regarding the discussion in this PR:

@LeonarddeR wrote:

@michaelDCurran In #8858 (comment), I suggested having the first column in the name and the rest in the description. I'm not sure whether I still agree with this suggestion, though. We couldn't make sure that the first column is of more importance than the other columns. In some list view controls, the first column is either empty or an identifier.

It seems that IAccessible uses the first column as object's name and the remaining columns as object's description. This let me think that the first column has a specific role.
At least in the 3 examples I have provided ("Disc clean-up" window, add-on updater and Tortoise SVN commit window) the most important information actually resides in the first column.
@LeonarddeR could you provide some other example where this would not be the case and where the most important information is in another column?

@lukaszgo1 wrote:

If the only downside to this is the fact that states are reported at the end I personally would consider it to be a non-issue - the same happens for regular checkboxes and while having it configurable would be nice it should not block this work IMO.

I partially disagree here since a checkable list item contains generally more information than a single checkbox especially when there are more columns.