1885071 - Consider removing bottom part of nsTextEquivUtils::AppendFromValue

Status: RESOLVED FIXED

(Core :: Disability Access APIs, task)

Description

[James Teh [:Jamie] (away returning 14 Apr)]

Bug 1858048 tweaks nsTextEquivUtils so that it aligns with the spec with regard to name from value; i.e. the "embedded control" part of the Acc Name spec. However, this raised the question of why we still need this code at the bottom of nsTextEquivUtils::AppendFromValue. According to the comment, it appends "value if and only if the given accessible is in the middle of its parent." I don't really understand why we need this.

Curiously, commenting it out causes a whole bunch of tests to fail weirdly. For example, list items start returning only their bullet text, which just doesn't make any sense to me. And yet putting it inside a if (aAccessible != sInitiatorAcc) block (which I think means it shouldn't run because we should have returned Value) allows the tests to pass. So, there's clearly something we're missing here.

I think we should remove this code, but we need to figure out why it appears to be necessary first.

Comment 1

[James Teh [:Jamie] (away returning 14 Apr)]

I'm not sure what was going on when we commented this out initially. However, testing it again (after the fix for bug 1858048), only 5 tests fail now. They're all similar to this:

    <label>Story
      <textarea id="textareawithchild" name="name">Foo</textarea>
      is ended.
    </label>

This test checks the name of the textarea. It expects "Story foo is ended." With this code commented out, you get "Story is ended".

In this case, we're calculating the name for the textarea. Even though we encounter the textarea as a result of walking the label's subtree, the textarea is the initiator accessible, so the top part of AppendFromValue doesn't apply.

Strictly speaking, I don't think this is required according to the Acc Name spec:

Embedded Control: Otherwise, if the current node is a control embedded within the label (e.g. any element directly referenced by aria-labelledby) for another widget

The key point is "another widget" here. We're calculating the name for the textarea and the label is for the textarea, not "another" widget. That said, our existing behaviour here does make some sense.

Chrome is oddly inconsistent here. The example above yields "Story is ended." However, if you explicitly associate the label using aria-labelledby instead of just the wrapping label, you get "Story foo is ended."

In any case, I think it's just easier to leave this alone for now. We can always revisit this if this becomes a real problem.

Comment 2

[Nathan LaPré]

I took a crack at this in this revision which ended up removing the block of code, as part of an effort to address some failing web platform tests. The behavior of appending the value only if it's in the middle of the parent is probably valuable behavior for actual usability, but it deviates from the Acc Name spec, and we had to drop it to support spec requirements (namely, consulting each node only once in name from content traversals).