Closed Bug 415299 Opened 13 years ago Closed 13 years ago

Support string values for ARIA widgets


(Core :: Disability Access APIs, defect)

Not set





(Reporter: aaronlev, Assigned: aaronlev)


(Blocks 1 open bug, )


(Keywords: access)


(1 file)

Sliders may have strings instead of numbers for the value points. For example, the screen resolution slider in Windows (800x600, 1600x1200, etc.), the security slider in IE (high, medium, low, off, etc.)

Here's a real example: 

The problem is the the accessible value interface only supports numbers.

Another place we'll eventually have this problem is for axes on a diagram or chart.

We're going to need some new ARIA property to expose this, so we'll have to recommend that soon for ARIA 1.0.

Event data won't work because 1) we don't have it in IA2 and 2) it does not allow you to get the info unless the value actually changed.
The plan is to support aria-valuetext as an optional string attribute. It would be exposed via an object attribute called valuetext, as well as IAccessible::get_accValue()
If the aria-valuetext text equivalent is not used by the author we should still expose the object attribute and string in get_accValue. Just take the value number and convert it to a string to put there. This way the AT will only have to check in one place.
I've updated the Mozilla slider example to add the optional aria-valuetext. The value text is now a dollar amount from 0 to 100.
I'm not sure aria-valuetext is the best, possibly aria-textvaluenow is better? what about valuemin and valuemax. If it is the screen resolution they may want to specifiy start and end available resolutions.
Btw, could we use existing aria-valuenow and others instead to introduce new attributes. HTML doesn't refer to strong typification so why do we need to force users to remember new attributes? Actually their values are strings and we can work with them depending on value type. I guess it's possible because no one wants to use both attributes the same time, right?
Surkov, this is what the W3C PFWG decided on.
The valuenow is not optional, but valuetext is an optional text equivalent.

So if you have something like "low medium high" you can use 1, 2 or 3 for the valuenow, valuemin=1, valuemax=3 and value text will be "low", "medium" or "high"
> Btw, could we use existing aria-valuenow and others instead to introduce new
> attributes. HTML doesn't refer to strong typification so why do we need to
> force users to remember new attributes?

If you used aria-valuenow with strings we wouldn't know what value to expose in the value interface, which requires a number. And we have to support the value interface in order for ATs on Linux to treat this correctly.

So the proposed solution is compatible with what is available today on both Linux and Windows. Orca can be updated to use the string value when available, but it will still work with Orca as it is now.
Comment on attachment 301369 [details] [diff] [review]
If optional aria-valuetext is set, expose it via get_accValue(). Also expose it in valuenow interface if the Value interface is supported.

Ok, if we are implementing what's W3C PFWG decided then it's fine with me. Path looks ok.

>+    nsAutoString valuetext;
>+    GetValue(valuetext);
>+    attributes->SetStringProperty(NS_LITERAL_CSTRING("valuetext"), valuetext, oldValueUnused);
>+  }

I would personally like similar method from nsAccUtils but it sounds you're not :)
Attachment #301369 - Flags: review?(surkov.alexander) → review+
Attachment #301369 - Flags: approval1.9?
I will change it to use nsAccUtils method. Sorry, I always forget it's there.
So it sounds valuetext is the sort of description of valuenow. Of course I
don't know exactly how it will be used but why are valuemin/max are special
Yes, valuetext is a description for valuenow. The group didn't consider having valuemintext or valuemaxtext, but I think it would be overkill for what we need.

valuetext is just used to provide a better representation for the current value when there is something better than a number.

For example, 3 = "high". The author intended the user to realize that.
But if they will decide at some point to introduce descriptions for min/max then I guess textvaluenow or valuenowtext is a bit better than valuetext because this name isn't related with valuenow.
I can bring that up, but I suspect people will like the shorter name and not see a good reason to change it. Also, if we actually decide that other values besides the current one need descriptions, we will probably want to be able to describe all of the possible points, so that we can use the same thing for labelled axes on a diagram etc.
Could you give me an idea how these values may be used by AT?
valuetext will be used by screen readers to announce the new value when the slider changes.
I meant other values besides the current one
Test build has the valuetext attribute for the Mozilla ARIA slider.
Attachment #301369 - Flags: approval1.9? → approval1.9+
Closed: 13 years ago
Resolution: --- → FIXED
Duplicate of this bug: 491740
You need to log in before you can comment on or make changes to this bug.