svg-a11y-ISSUE-1008: Recursive use aria-labelledby/describedby in text alternative computation [SVG Accessibility API Mappings]

svg-a11y-ISSUE-1008: Recursive use aria-labelledby/describedby in text alternative computation [SVG Accessibility API Mappings]

http://www.w3.org/WAI/PF/svg-a11y-tf/track/issues/1008

Raised by: Fred Esch
On product: SVG Accessibility API Mappings

>From Joanie Diggs.
https://lists.w3.org/Archives/Public/public-svg-a11y/2016Feb/0001.html

Hey all.

I have a question regarding two of the test assertions:

1. Under
https://www.w3.org/wiki/SVG_Accessibility/Testing/Test_Assertions#Multiple_idrefs_in_aria-labelledby:

   // two valid idrefs, one with an aria-label, one with aria-labelledby
   if given

   <circle id="test" aria-labelledby="t1 t2" cx='50' cy='100' r='15'/>
   <text id="t1" x="40" y="90" aria-label="big">the</text>
   <text id="t2" x="140" y="90" aria-labelledby='t3'>end</text>
   <text id="t3" x="180" y="90">finish</text>

   then accessible name = "big finish"

2. Under
https://www.w3.org/wiki/SVG_Accessibility/Testing/Test_Assertions#Multiple_idrefs_in_aria-describedby:

   // two valid idrefs, one with aria-describedby
   if given

   <circle id="test" aria-describedby="t1 t2" cx='50' cy='100' r='15'/>
   <text id="t1" x="40" y="90">the</text>
   <text id="t2" x="140" y="90" aria-describedby='t3'>end</text>
   <text id="t3" x="180" y="90">finish</text>

   then accessible description = "the finish"

In order to obtain the expected results stated above, one must
recursively follow aria-labelledby/describedby. But it appears that
doing so contradicts Step 2B of the Core AccName spec [1] which states:

  * if computing a name, and the current node has a non-empty
    aria-labelledby attribute, **and the current node is not already
    part of an aria-labelledby traversal**, process its IDREFs in the
    order they occur:
  * or, if computing a description, and the current node has a
    non-empty aria-describedby attribute, **and the current node is not
    already part of an aria-describedby traversal**, process its IDREFs
    in the order they occur:

    i. Set the accumulated text to the empty string.
   ii. For each IDREF:
       a. Set the current node to the node referenced by the IDREF.
       b. Compute the text alternative of the current node beginning
          with step 2. Set the result to that text alternative.
       c. Append the result, with a space, to the accumulated text.
  iii. Return the accumulated text.

(emphasis added)

When computing the text alternative for the element with id="test", 2B
instructs us to set the current node to "t1" and "t2" respectively and
return to Step 2.

When computing the text alternative for the element with id="t2" as part
of computing the text alternative for the element with id="test", we
*are* already part of an {aria-labelledby,ariadescribedby} traversal. As
a result, we are not free to proceed with steps stated in 2B and I think
we're thus left with using the textual contents of "t2", namely "end".

Long way of saying: Aren't the expected results for the tests above "big
end" and "the end" respectively?

--joanie

[1]
https://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html#mapping_additional_nd_description

Received on Friday, 5 February 2016 17:53:48 UTC