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

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect, P3)

Description

[Joanmarie Diggs]

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

Comment 1

[alexander :surkov (:asurkov)]

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

Comment 3

[Patrick H. Lauke]

Could I suggest that the priority/severity here are ... a bit low on both counts? This behavior fundamentally breaks certain ARIA patterns/widgets at the moment, making things broken/unusable for screen reader users in Firefox...

Comment 4

[dipree]

I second Patrick's suggestion to increase the priority. It would be great to see Firefox invest into better supporting screen reader users.

Comment 5

[James Teh [:Jamie]]

(In reply to Patrick H. Lauke from comment #3)

This behavior fundamentally breaks certain ARIA patterns/widgets at the moment, making things broken/unusable for screen reader users in Firefox...

(In reply to dipree from comment #4)

I second Patrick's suggestion to increase the priority. It would be great to see Firefox invest into better supporting screen reader users.

This (and bug 1884659, filed just 2 days ago) is literally the first time we're hearing of this behaviour impacting anyone at all since this bug was filed 8 years ago. And this bug wasn't filed regarding a real situation, only a theoretical one.

Are there are real sites or toolkits that this is currently breaking? I'm happy to look at increasing the severity if this is breaking users on a daily basis, but s3 seems reasonable if this isn't actually preventing anyone from accessing something.

Comment 6

[Patrick H. Lauke]

Are there real sites that this is currently breaking?

It breaks the APG pattern here https://www.w3.org/WAI/ARIA/apg/patterns/listbox/examples/listbox-rearrangeable/#ex2_label (Multi-select listboxes) when using Firefox/VoiceOver on macOS. Firefox seems to be rewriting the DOM and constantly changing the aria-selected, making it impossible to actually do a selection/multiselection. We (@dipree and I) have been working on a widget to be used in a live site soon relying on this multiselect listbox, but the Firefox/VO behaviour is a showstopper. (this pattern works fine il all other browser/SR combinations we've tested, otherwise)

Comment 7

[Patrick H. Lauke]

It may well be that this pattern isn't super-common (yet) in the wild, so users may not be immediately affected on a day-to-day basis. Or it may be that because of bugs like the one in Firefox/VoiceOver here, sites are shying away from it, making it a chicken-egg problem.

Comment 8

[James Teh [:Jamie]]

Attachment: Bug 1305428: Don't set ARIA DOM attributes due to accessibility API calls.

Per the spec, with respect to ARIA, "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."
Although Firefox has not complied with this part of the spec for many years, this can cause problems for some ARIA widgets which aren't expecting ARIA attributes to be changed by the browser (nor should they, per the spec).
This might change one day, but for now, we should align with the spec.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/469d4a744966
Don't set ARIA DOM attributes due to accessibility API calls. r=eeejay

Comment 10

[Norisz Fay [:noriszfay]]

Backed out for causing ba failures on browser_caching_value.js

Backout link

Push with failures

Failure log

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d5975ef266e6
Don't set ARIA DOM attributes due to accessibility API calls. r=eeejay

Comment 12

[Sandor Molnar[:smolnar]]

Backed out for causing bc failures @ accessible/tests/browser/<...>

Backout link: https://hg.mozilla.org/integration/autoland/rev/a7ceb3056acce7ef54ee4e500eb46e76bd9568e8

Push with failures

Failure log -> TEST-UNEXPECTED-FAIL | accessible/tests/browser/mac/browser_selectables.js | Test timed out

Failure log -> TEST-UNEXPECTED-FAIL | accessible/tests/browser/selectable/browser_test_aria_select.js | Test timed ou

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f20ba2ecb66d
Don't set ARIA DOM attributes due to accessibility API calls. r=eeejay

Comment 14

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/f20ba2ecb66d