You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reported by mdcurranf on 2008-11-24 05:59
NVDAObjects currently have a 'value' property, which usually is used to communicate the value of a slider or progress bar, or perhaps a text field with no caret etc. However accessibility APIs such as Java Access Bridge, IAccessible2 and UI Automation can provide more info for the value, such as its minimum and maximum values (if its numeric).
Instead, NVDAObjects should have a valueInfo property, which is a dictionary containing values of:
current, min, max.
If min and max are provided, then current, min and max all need to be numeric. However if current exists by itself, then it can be an arbitrary string.
If an API supports both string values and numeric values, the string value should probably be used in preference.
The text was updated successfully, but these errors were encountered:
Comment 2 by mdcurran on 2010-01-21 05:43
A rather old ticket, which is sort of not needed anymore. UIA has been implemented, and we don't really seem to need this anymore.
Changes:
Changed title from "replace value property on NVDAObjects with a valueInfo property" to "replace value property on NVDAObjects with a valueInfo propertyf"
Added labels: wontfix
State: closed
Reported by mdcurranf on 2008-11-24 05:59
NVDAObjects currently have a 'value' property, which usually is used to communicate the value of a slider or progress bar, or perhaps a text field with no caret etc. However accessibility APIs such as Java Access Bridge, IAccessible2 and UI Automation can provide more info for the value, such as its minimum and maximum values (if its numeric).
Instead, NVDAObjects should have a valueInfo property, which is a dictionary containing values of:
current, min, max.
If min and max are provided, then current, min and max all need to be numeric. However if current exists by itself, then it can be an arbitrary string.
If an API supports both string values and numeric values, the string value should probably be used in preference.
The text was updated successfully, but these errors were encountered: