Because ARIA 1.x is one-way (getter support only), setters should not change property values and should return False when called

NEW
Unassigned

Status

()

Core
Disability Access APIs
P5
normal
2 years ago
9 months ago

People

(Reporter: Joanmarie Diggs, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
ARIA 1.x is officially one-way: ATs and other platform accessibility tools can get properties, but cannot set them. At least that's the scenario many of us have been living under. Adding the ability to set properties and states via platform accessibility APIs is planned for ARIA 2.x.

For this reason, calling setters such as (but not limited to) atk_value_set_value() and atk_selection_clear_selection() should do two things in an ARIA 1.x environment:

1. NOT set/change any value or state in response to attempts coming from platform accessibility APIs' setter methods.

2. Return False indicating the attempted change has failed.

From some quick testing, item 2 is not occurring: True is being returned. Which is arguably understandable given that, in at least the case of the Value interface, setting the current value seems to work *insofar as subsequently asking for the current value returns the new value.* Furthermore, when I use the inspector, I see that the element's aria-valuenow value is being correctly updated. This would all be extremely cool were it not for the following:

The web application itself does not update in response to the accessibility-API-triggered change of the aria-valuenow value. The appearance of the widget remains unchanged (in this case, the slider remains at 10%). This is presumably due to the fact that the author (in this case Dojo) is not listening for changes because ARIA 1.x is one way.

If the widget in question were a field in which you indicated how much of a "tip" or "contribution" you wanted to make on top of a price you were paying, the user could tell the AT to reduce the value from 100% to 1%. And the AT would try, be told it succeeded, and would see that the value had really been changed -- according to the platform accessibility API's method to get the current value. But when the user clicked "submit," the unchanged slider with its value of 100% would be submitted and the user charged quite a bit more than he/she expected.

I feel bad for asking you to disable something that would work if only authors knew to pay attention to changes coming from the user agent. However, until setting states and values is added in 2.0, the situation described above strikes me as quite problematic.

Lastly, the situation described above conflicts with what is in the Core Accessibility API mapping spec in which section 5.1 [1] states:

=====
With respect to WAI-ARIA 1.0, accessibility APIs operate in one direction only. User agents publish WAI-ARIA information (roles, states, and properties) via an accessibility API, and an AT can acquire that information using the same API. However, the other direction is not supported. WAI-ARIA 1.0 does not define mechanisms for assistive technologies to directly modify WAI-ARIA information.
=====

The same statement can be found in the Core AAM 1.0 REC [2].

Therfore if this functionality could be disabled until issues are sorted out as part of 2.0, that would be great. Thanks!

[1] https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#mapping_general
[2] https://www.w3.org/TR/2014/REC-wai-aria-implementation-20140320/#mapping_general

Updated

2 years ago
Blocks: 343213

Comment 1

2 years ago
Joanie, is ARIA 2.0 going to take a different approach, than updating aria-foo values?

Updated

9 months ago
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.