ISSUE-1021: Label Relationship is inconsistent on Mac and Linux - Should we expose?

It's not clear to me what (if anything) needs to be done in order to resolve this issue.

Some points worth considering:

The Acc Name computation, as stated for the Mac, has been that way since the 1.0-version days of the spec. And, as far as I am aware, that text describes what is appropriate and done for OS X for HTML and ARIA.

The SVG spec and the SVG AAM spec say nothing about AXTitleUIElement explicitly. As a result of the absence of overriding, explicit language in the SVG specs, the Acc Name behavior is also expected for SVG.

My understanding is that Apple is NOT opposed to exposing aria-labelledby for SVG via AXTitleUIElement -- in addition to AXDescription, which is in place already -- for SVG. In other words, it would not be wrong/bad to do so. However, Apple does not see any practical reason making this additional exposure as absolutely essential -- again, for SVG. The additional exposure IS appropriate and needed for other things, such as widgets. And Apple MIGHT turn around and add this exposure at some point for SVG. It just hasn't happened yet because it does not so far appear necessary.

From the above, I myself have reached the following conclusions:

1. No change is desired in the Acc Name spec because it reflects what is appropriate and what was/is implemented already for AX API, namely:

a. AXDescription for the string
b. AXTitleUIElement when there's only one ID

In the wild, item b seems to have an unwritten "and when there's a reason to do so". But putting such vague language in the Acc Name (or any other) spec seems like a bad idea.

2. No overriding language (such as "don't expose a pointer via AXTitleUIElement for SVG") should be added to the SVG specs for a couple of reasons:

a. Exposing it via AXTitleUIElement is not wrong/bad, even for SVG. ;)
b. Exposing it via AXTitleUIElement might ultimately be needed and implemented for SVG.

3. For the purpose of CR testing, we can prove:

a. Computed string is exposed via AXDescription as per the Acc Name spec.
b. The value of AXDescription is being calculated according to the SVG AAM spec.
c. Exposure via AXTitleUIElement is implementABLE: It's done for other element types.

As for Linux: While I've not yet added SVG-specific code to Orca, I can envision Orca might double-present text that is rendered, in the accessibility tree, and referenced by some other element's aria-labelledby. Thus just because VoiceOver doesn't (seem to, so far) need the AXTitleUIElement exposure in addition to AXDescription, doesn't mean that Orca doesn't need the AtkRelation exposure in addition to the AtkObject name property.

Taking all of this into account, I am of the opinion that the thing to do is remove AXTitleUIElement as a required component of CR testing (i.e. what's on the wiki) for SVG 1.1 AAM. And that is the only change I myself would make.

FWIW....

Overall, I agree with Joanie's comment above. In particular, for AXAPI, the accename-aam and core-aam [1] specify that aria-labelledby with one ID is mapped using AXTitleUIELement. What is unclear is whether AXDescription is always set, or only set when AXTitleUIElement is not used. The wording should be clarified.

But, (there is always a "but"), the ARIA 1.0 test cases show otherwise. Below are links to three relevant test cases from the 1.0 test harness. There may be more; I didn't do an exhaustive search:

1. Test case 104:
Given:
- Element with id "test" having role <code>main</code> with global state or property <code>aria-labelledby</code> with value "obj1", where the element with id "obj1" has text content "obj1"

Expect:
- Expose the labeling relationship as element AXTitleUIElement using the string "obj1".

2. Test case 146 [3]:
Given:
- Element with id "test" having no role with global state or property <code>aria-labelledby</code> with value "obj1", where the element with id "obj1" has text content "obj1".

Expect:
- Expose the labeling relationship as element AXTitleUIElement using the string "obj1".

3. Test case 540 [4]:

Given:
- An INPUT type=ANY with an id="test", an aria-labelledby="ID1" and no aria-label.
(Note: type=ANY means any of these HTML4 types: text, button, checkbox, radio, reset, or submit. The test file used type="button").

Expect:
- AXRole=AXButton, AXSubrole=<nil>, AXRoleDescription="button", AXDescription="Rich's button"

Of these, test cases 104 and 146 were not run against Safari/AXAPI (recall that for CR, only two platforms need a passing result. Here, AXAPI was not needed). Test case 540 was run and passed [5].

Test cases 104 and 146 fail using Safari 9.1/AXAPI on OS X Yosemite. However, they both pass using Chrome 49.0/AXAPI. Uggh. This means there is also an interoperability issue.

IMHO, test cases 104 and 146 are consistent with the spec. Test case 540 is not. Either Safari is not implementing the spec as written, or the spec is wrong. Or, Safari changed its implementation between ARIA 1.0 CR testing and the present time. We should get confirmation from Apple. The Chrome team should also be consulted since they did follow the spec, and they may object to any changes at this point.

For the record, the mapping text first appeared officially in the Last Call working draft of the 1.0 User Agent Implementation Guide, 05-Nov-2013. It hasn't changed since:

"
If aria-labelledby references a single element, expose the labeling relationship as element AXTitleUIElement.

If aria-labelledby references multiple elements, or if the labeling element is invisible or otherwise not exposed in the accessibility tree, use in calculating the accessible name as described in Name Computation and expose value as string AXDescription.
"
[6].

That means Apple signed off on the above mapping.

[1] http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaLabelledBy
[2] https://www.w3.org/WAI/PF/testharness/test?testsuite_id=1&testcase_id=104&platform_id=5
[3] https://www.w3.org/WAI/PF/testharness/test?testsuite_id=1&testcase_id=146&platform_id=5
[4]
https://www.w3.org/WAI/PF/testharness/test?testsuite_id=1&testcase_id=540&platform_id=5
[5] https://www.w3.org/WAI/PF/testharness/testresults?testsuite_id=1&testcase_id=540
[6] https://www.w3.org/TR/2013/WD-wai-aria-implementation-20131105/#mapping_state-property_table (scroll down to the aria-labelledby row).

Closing as obsolete.