Clarification sought regarding exposing title attribute via description when also part of name calculation

[joanmarie]

Given this test case:

<label for="test">foo <input id="test" type="button" name="test" title="bar"> baz</label>

The accessible name of the input should be "foo bar baz" based on what is in the AccName + HTML-AAM specs. The question is: Should "bar" be exposed as the accessible description?

The HTML-AAM states the following regarding accessible description calculation of input type="button":

1. If the element has an aria-describedby attribute the accessible description is to be calculated using the algorithm defined in Accessible Name and Description: Computation and API Mappings 1.1.
2. Otherwise use the value attribute if it wasn't used as the accessible name
3. Otherwise use the title attribute if it wasn't used as the accessible name
4. If none of the above yield a usable text string there is no accessible description

The element lacks an aria-describedby attribute and a value attribute. It does have a title attribute. And while the title attribute was used as part of the accessible name; it technically was NOT "used as the accessible name." Thus the accessible description seems like it should be "bar".

Whether or not the accessible description should indeed be "bar" is something I will gladly leave to authors and those with similar expertise. As an implementor, I would find it helpful if the spec were more explicit, e.g. something in the ballpark of:

Otherwise use the `title` attribute if it wasn't used as the complete accessible name

if my current, literal reading is the correct expectation. Otherwise, something in the ballpark of:

Otherwise use the `title` attribute if it wasn't used as part of the calculated 
accessible name

Thanks in advance!

[joanmarie]

See also: https://bugs.webkit.org/show_bug.cgi?id=189379.

[scottaohara]

The missing bit here is that the label that surrounds the input is providing the accessible name via the text within the label, thus neglecting the title as part of the accessible name and using the attribute's value as a description instead.

It does seem odd to me that the label element is not mentioned in this spec as a method of providing a source of an accessible name.

[stevefaulkner]

Hi @joanmarie this is tricky :-)
I don't think that if there is another source of accessible name for the button that title should be included in acc name calculation. I also don't think that if it appears as complete or part of the acc name calculation it should be used in accdescription calc.

Currently implementations in browsers are not interoperable, as in they are all over the place in regards to acc name calculation for examples (mostly edge cases) i added to https://thepaciellogroup.github.io/AT-browser-tests/test-files/input-button.html look at tests 5-10. I have not had time to record what i observed yet.

@scottaohara is correct that it is odd that the label element is not taken into account in the acc name calculation for button, that is a bug.

[joanmarie]

@scottaohara is correct that it is odd that the label element is not taken into account in the acc name calculation for button, that is a bug.

Well, the label element IS taken into account in the acc name calculation. The label element's content is:

• "foo" (text)
• (button input with title of "bar")
• "baz"

@stevefaulkner and @scottaohara: What do you each think the expected title should be?

[scottaohara]

The acc name should be “foo baz”. The label is provided by the text nodes of the label element, which is why the title shouldn’t be considered part of the acc name.

[stevefaulkner]

@scottaohara that is what i get from testing in all except firefox.

[joanmarie]

@scottaohara that is what i get from testing in all except firefox.

Indeed. And when I read what's in the AccName spec (general rule for descending children and concatenating strings for name-from-content) + what's in the HTML AAM (overrides the calculation for certain elements), "foo bar baz" is the expected result. If my reading is correct, we either need to fix the user agents (what I was planning to do) or AccName and/or HTML AAM.

I'll write up the exact manual calculation steps here both as a sanity check and as for subsequent discussion.

[joanmarie]

Oops. I think my read was incorrect due to AccName step D:

Otherwise, if the current node's native markup provides an attribute (e.g. title) or element (e.g. HTML label) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, unless the element is marked as presentational (role="presentation" or role="none").

I guess we can close this. Sorry for the noise!

[scottaohara]

Thank you for the discussion @joanmarie :)

[joanmarie]

I'll keep this closed (or at least not reopen it, since it's your spec and issue tracker), but @stevefaulkner stated:

@scottaohara is correct that it is odd that the label element is not taken into account in the acc name calculation for button, that is a bug.

You want me to file a new issue for that?

[scottaohara]

that's ok @joanmarie. i'll reopen this issue and assign to myself.

thanks

[joanmarie]

@scottaohara, regarding:

The acc name should be “foo baz”. The label is provided by the text nodes of the label element, which is why the title shouldn’t be considered part of the acc name.

Should there be one space in between "foo" and "baz" or two? I just assumed one, and I do think most user agents tend to simplify/collapse whitespace. But a member of the ARIA Working Group pointed out the two spaces in the label element. And since AccName in this case seems to totally defer to your spec, we need to be sure whitespace simplification is covered.

Thanks again for all your help with this one!

[scottaohara]

I believe you're correct @joanmarie.

I'll check some more and verify for you.

[scottaohara]

So checking with @stevefaulkner as well as doing some quick manual testing, I couldn't find an instance of extra white space (beyond a single space) being reported in the accessible name of an element.

Sometimes when looking directly at text nodes, there were instances where a single bit of white space was included in the accName if there was a line break in the source code. But the extra white space wasn't included in the accName of the element that made use of the text.

so for example:

<label>
  Text 1
  <input>
  Text 2
</label>

Reported as "Text 1 Text 2"

And

 <input title="test       this">

Reported as "Test this"

[scottaohara]

Noting this related issue (29).