progressbars always report 0.0 when updating. (ATK)

RESOLVED INVALID

Status

()

Core
Disability Access APIs
RESOLVED INVALID
10 years ago
10 years ago

People

(Reporter: Scott Haeger, Assigned: Aaron Leventhal)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
Under ATK, the dojo progressbar seen here http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_ProgressBar.html always reports 0.0 for currentValue.  Look at the 4th test case activated by the 'start timer' button.  Here is what is known about these widgets:

1) The AT-SPI role=progressbar.
2) They have the object attribute xml-roles=progressbar set.
3) They implement the value interface.
4) As viewed through the DOM inspector, they have both wairole=progressbar and role=progressbar set.
5) All value interface properties report 0.0.
(Assignee)

Comment 1

10 years ago
Does this one work? (I just posted it so it might take an hour to show up)
http://www.mozilla.org/access/dhtml/new/progressbar.html
(Reporter)

Comment 2

10 years ago
Yes, both this new example and the old example work.  For reference, the old progressbar can be seen here: http://www.mozilla.org/access/dhtml/progressbar
(Assignee)

Updated

10 years ago
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Comment 3

10 years ago
That means it is probably something wrong with the Dojo progress bar.
(Assignee)

Comment 4

10 years ago
I did not mean to mark it fixed.

What confuses me is that the Dojo example works in IA2 but not ATK -- this makes it sounds like a Firefox bug.
Meanwhile the Mozilla examples work, which makes it sound like a Dojo bug.

David or Simon, are either of you willing to try and debug this?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I rebuilt FF trunk on my ubuntu VM and have confirmed that accerciser seems to work with http://www.mozilla.org/access/dhtml/new/progressbar.html and not with the nightly dojo progressbar.

I notice for dojo's progressbar valuenow we are using alphanumeric values like "10%" and "0 out of 256 max chars"... probably because this makes for a nice screen reader experience... I wonder if the accerciser spinner which shows valuenow is barfing on these... maybe Eitan can tell us if we catch him online, or we could look at accerciser source.

Aaron, valuenow can be alphanumeric right?

Not sure when I can look at this next.

(Assignee)

Comment 6

10 years ago
David, I believe you found the problem.
When we convert that to a number for the ATK/AT-SPI value interface it's going to be 0.

Since the value was also 0 last time there is no change and thus no event is fired.
(Reporter)

Comment 7

10 years ago
Hacking dojo confirms what Aaron suspected.  The valuenow and probably all value interface properties need to report a float.  
Thanks for confirming Scott. So I'm not clear what the right fix is. Note that the spec says valuenow is a string: http://www.w3.org/TR/aria-state/#valuenow  (at least at the moment)
(Assignee)

Comment 9

10 years ago
We need to fix Dojo to use a number, and fix the ARIA spec so that it requires that valuenow/valuemin/valuemax is a number. I've send a note to the PFWG to fix the spec.

Not a Firefox bug.
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.