389851 - ARIA progressbars and sliders not implementing IValue

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Scott Haeger]

None of the progressbars or sliders linked from http://developer.mozilla.org/en/docs/Accessible_DHTML are implementing IValue.  I would expect a property_change:value event during value change events for both these ARIA widgets.

Comment 1

[alexander :surkov (:asurkov)]

Sorry what is IValue. If it's something like nsIAccessibleValue then what's ARIA properties must be setted to provide this interface? Is it valuenow enough for this?

Comment 2

[Aaron Leventhal]

He means the Value interface in it's various forms -- nsIAccessibleValue/AtkValue, AccesibleValue.

Comment 3

[Scott Haeger]

Alexander,

Sorry for the terminology difference.  I don't come from a Mozilla codebase
world.  IValue is the at-spi value interface and I assume it is the equivalent
of nsIAccessibleValue.  Certainly valuenow must be set, but valuemin and
valuemax are also set on the slider examples.  This link briefly mentions the
aaa:valuenow change.
http://developer.mozilla.org/en/docs/ARIA_to_API_mapping#Events

Comment 4

[Aaron Leventhal]

Surkov, one note: to be consistent with our solution in bug 386235 we should make sure the value interface stays implemented even if aaa:valuenow isn't set. Let's make sure for objects could potentially support valuenow that nsIAccessibleValue is always supported.

Comment 5

[alexander :surkov (:asurkov)]

(In reply to comment #4)
> Surkov, one note: to be consistent with our solution in bug 386235 we should
> make sure the value interface stays implemented even if aaa:valuenow isn't set.
> Let's make sure for objects could potentially support valuenow that
> nsIAccessibleValue is always supported.
> 

Ok. Then every accessible that is created for DOM element must implement nsIAccessibleValue, i.e. almost all accessibles. It means almost every accessible should implement nsIAccessibleTable too (@posinset and so on) and probably another interfaces as well. Not sure it's a good idea.

Let look on another hand. DOM3 allows to rename node (though iirc it's not implemented yet) and XBL binding can be changed during lifetime of DOM node then we need to recreate an accessible. We need to do it because our architecture doesn't allow to provide new interfaces and save our object in this case. But architecture allows us to do this if we deal with ARIA properties. Therefore we have a question: should we recreate object or not? Note if we change a role object then we recreate an accessible. Why? because it looks much like in the case of @valuenow. Why we don't want to provide all interfaces for all roles for the every accessible?

All I want to say where is a line when we should decide whether should recreate object or implement all valueable interfaces?

Comment 6

[Aaron Leventhal]

I think nsAccessible::QueryInterface only needs to implement nsIAccessibleValue when the role is appropriate (supports valuenow), otherwise it's implemented in the QI for the given a11y impl class.

Whenever the role or element changes, we already destroy the accessible and create a new one. I think that's fine, because it's not just a property that's changing. It's the class of object that is fundamentally changing, and in those cases we *should* recreate the accessible.

So I don't see a problem.

Comment 7

[Aaron Leventhal]

Also, for a progressbar with an indeterminate value, we should still support the value interface but just return some kind of error for GetValue

Comment 8

[alexander :surkov (:asurkov)]

(In reply to comment #0)
> None of the progressbars or sliders linked from
> http://developer.mozilla.org/en/docs/Accessible_DHTML are implementing IValue. 
> I would expect a property_change:value event during value change events for
> both these ARIA widgets.
> 

Can you show me example? I just dont understand why there is no nsIAccessibleValue interface implementation and there are no events.

Comment 9

[Scott Haeger]

Inspect the slider on http://www.mozilla.org/access/dhtml/pretty-slider.htm with Accerciser and you will see that it does not implement the Value interface.

Comment 10

[Aaron Leventhal]

What about this one?
http://www.mozilla.org/access/dhtml/class/slider

Comment 11

[Scott Haeger]

Nope.  IValue is not implemented for that one either.

Comment 12

[Aaron Leventhal]

Attachment: Forgotten return statements in QueryInterface!

Comment 13

[Scott Haeger]

Comment on attachment 276649 [details] [diff] [review]
Forgotten return statements in QueryInterface!

Looks good to me.

Comment 14

[Scott Haeger]

Dojo Sliders:
Test case http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_Slider.html

First slider is not triggering value changed events.  IValue.currentValue seems to be correct for all.  Horrible accessible hierarchy for all.

Dojo Progressbars:
Test case http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_ProgressBar.html

All progressbars seem to trigger value changed events.  IValue.currentValue is always 0.  Good accessible hierarchy.

Other test cases:
All Mozilla and UIUC example sliders and progressbars look good.

Comment 15

[Aaron Leventhal]

If the Mozilla and UIUC ones work, this is fixed. Can you file bugs on Dojo for their issues?