Improve accessibility of some controls used in nvda

[feerrenrut]

Implement an accessibility modification module that allows controls to have various accessibility properties overridden to try to resolve issues such as:

• #6417 To report as a spin control rather than a text field
• #6345 Length of some options, particularly that of the "Use currently saved settings on the logon and other secure screens..." button
• #6344 Wording of options. Somewhat related, being able to provide separate hints that are still associated might give more wording options.

This change should allow us to change how a type of control is reported, as well as associate more than one label with a control.

[jcsteh]

A minor clarification: in accessibility terms, we can't associate more than one "label" with a control. We would associate a label (accName) and a description (accDescription).

Another thing this could be used for is making checkable list boxes.

• The way to achieve this is to use MSAA direct annotation.
• In short, we get the HWND from the control (the .Handle property on wx controls) and then use IAccPropServices::SetHwndProp (or SetHwndPropStr) to set accessibility properties for that control. The object id will always be OBJID_CLIENT. For most controls, the child id will be CHILDID_SELF. The only exception is individual list and tree items, where the child id identifies the child.
• NVDA already has an instance of IAccPropServices as IAccessibleHandler.accPropServices.
• So, to add a description to a button, you might do:
  • PROPID_ACC_DESCRIPTION = comtypes.GUID("{4d48dfe4-bd3f-491f-a648-492d6f20c588}") # Get these constants from oleacc.idl
  • IAccessibleHandler.accPropServices.SetHwndPropStr(button.Handle, winUser.OBJID_CLIENT, winUser.CHILDID_SELF, PROPID_ACC_DESCRIPTION, u"Some description")
• To make something get exposed as a spin button, you would change its accRole.

We'd want to come up with a nice abstraction for this. We could either have them pass the PROPID constant:

gui.accUtils.setAccProps(button, gui.accUtils.PROPID_ACC_DESCRIPTION, u"Some description")

or use keyword arguments to make it friendlier:

gui.accUtils.setAccProps(button, description=u"Some description")

I personally prefer the latter (and it should be easy enough to do with a dict), but happy to discuss. I think we only need to support description and role initially, but states might be useful later.

It should probably also accept a child id eventually to support list box items, etc., but maybe we could skip that for the initial implementation.

[feerrenrut]

Due to the low impact of this issue, relative to existing p2's this is a p3 issue. However it can be considered a high p3 since its probably only 1-2 days work to resolve 3 issues.

[LeonarddeR]

To clarify the spin control case (#6417), there is already a spin button in the spin control, however it has its own window. The current spin control consists of a label object, a properly labeled edit box, and an unlabeled spin button. There is no need to change an accRole here, I think.

[jcsteh]

Oh. IN that case, there's no way for us to notify the user that they're entering a spin button for those controls, since there's no common parent we can put the spin button role on. That really shouldn't be a sibling. Ug.

[LeonarddeR]

I think we only need to support description and role initially, but states might be useful later.

States are required for #7325.

[derekriemer]

I vote to take the direct annotation off the checkable list. After doing the work to make one for NVDA, I'll submit the code later), I realized that to properly do direct annotation for it, we need to override all items, such as InsertItem, Append, AppendItem, ... so the role and state is changed when each new item is added. This gets ugly rather fast. I ended up settling on server annotation for this reason, because it ended up being less code paths to override, and thus is more clear and future proof. I'm not sure whether the whole framework should be direct annotation, or server annotation. It sure seems like the checkable list is a special case of sorts.

[Adriani90]

Now that the checable list PR is merged, which are the next steps regarding this issue? I guess most accessibility properties are now in place and specific cases must be treated one by one. Or are there any additional properties to be added? cc: @leonardder

[Adriani90]

@seanbudd, @SaschaCowley could you please triage this one? Is there something else NV Access would like to have addressed from this issue?

[seanbudd]

@Adriani90 - it is unclear what the work remaining here is. I'd encourage a new issue with more thorough and up-to-date information

[Adriani90]

I think @SaschaCowley already tackled much of this in his implementation of the new dialog API in #17582, otherwise I am not sure what is still open since I was not involved in this discussion. @jcsteh do you think we can close this now? Only #6345 is still open.