Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

properties for human-readable or custom roles on NVDAObjects #235

Closed
nvaccessAuto opened this issue Jan 1, 2010 · 7 comments
Closed

properties for human-readable or custom roles on NVDAObjects #235

nvaccessAuto opened this issue Jan 1, 2010 · 7 comments
Labels
enhancement

Comments

@nvaccessAuto
Copy link

Reported by mdcurran on 2008-11-24 11:31

Problem

  • NVDAObjects can not by themselves provide a human readable role. This this makes debugging complex, in that the role's label must be manually looked up.
  • Some APIs can provide custom roles, or type names for their objects. NVDA currently has no way of conveying this to the user.

    suggestion

NVDAObjects should contain a roleText property. By default, NVDAObject's should just look up the role's label and use that as the value. But for APIs that may have custom role strings, then it should provide that as the value instead.
However, care must be taken to make sure that the role string is localized.

  • If IAccessible2 objects have a localizedExtendedRole then use that, else use extendedRole, else let NVDA look up the label.
  • For IAccessible (MSAA) NVDA should just look up the name, unless the role is a string and its not known by NVDA.
  • For UI Automation, if it has a localizedControlType then use that, else let NVDA look up the label.
  • Java Access bridge: if the role_us role is not known by NVDA, perhaps the localized role should be used.

    Questions

  • How should braille use roleText? it may want to use shorter role labels, but NVDAObjects arn't to know if braille is asking or not. Unless of course _get_roleText took an optional argument to indicate that a shorter role is preferable.
@nvaccessAuto
Copy link
Author

Comment 1 by mdcurran on 2008-11-24 11:47
For UI Automation we should actually use itemType if that is available, if not, then if the controlType is custom, use either localizedControlType, or className (this is hard as localizedControlType probably just says custom in a particular language, but UIA spec states it can be overridden). If controlType is not custom, then let NVDA look up the label.

@nvaccessAuto
Copy link
Author

Comment 2 by mdcurran on 2008-11-25 02:10
It has been decided that the point about having a human readable role on NVDAObjects for debugging isn't as important as supporting custom roles. Therefore, rather than roleText, we should implement the following two properties:

  • customRole: provides the custom role preferably in a non-localized form, in order for programmatic use.
  • customRoleText: provides the custom role, preferably in a localized form, for use in speech and braille.
    Speech and braille will then continue to use the role property the way they normally would, except unless the customRoleText property contains something. If the customRoleText property contains something, then speech and braille must present this, rather than the normal NVDA role label.

@nvaccessAuto
Copy link
Author

Comment 3 by mdcurran on 2008-11-25 02:12
Changes:
Changed title from "NVDAObjects should have a roleText property" to "properties for human-readable or custom roles on NVDAObjects"

@nvaccessAuto
Copy link
Author

Comment 4 by jteh on 2009-06-23 06:13
Changes:
Milestone changed from 0.6 to None

@LeonarddeR
Copy link
Collaborator

Is there still demand for this?

@LeonarddeR LeonarddeR mentioned this issue Jun 7, 2017
Closed
@bhavyashah
Copy link

@LeonarddeR Given that the last comment didn't receive any response, it doesn't seem like there is much demand for this, I guess.

@LeonarddeR
Copy link
Collaborator

This issue has two parts:

  1. The ability to provide custom role text. This was done in UIA/Edge: no aria-roledscription and other properties are rendered in browse mode #8448
  2. Being able to find out what role an object has for debugging purposes. This can be done by getting the developer info, but Convert control types constants into enums #10732 will provide a much more elegant fix for that.

Closing this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@LeonarddeR @nvaccessAuto @bhavyashah