Sanity check needed for test cases 659 and 660

[joanmarie]

(Edited to reflect the fact that not a single user agent is producing the results we currently have in the expectations, namely "foo bar baz".)

Test case:

<style type="text/css">
  label:before { content: "foo"; }
  label:after { content: "baz"; }
</style>
<label for="test" title="bar">
  <input id="test" name="test" title="buz">
</label>

Starting the algorithm:

Step 1.  Set the root node to the input with id of "test"
         Set the current node to the root node (i.e. the input)
         Set the total accumulated text to the empty string ("")
Step 2A. N/A: The current node is NOT hidden.
Step 2B. N/A: Computing a name, but current node lacks aria-labelledby
Step 2C. N/A: Computing a name, but current node lacks aria-label
Step 2D. Applicable: "The current node's native markup provides an 
         attribute (e.g. title) or element (e.g. HTML label) that
         defines a text alternative.

Aside: The current node in this test case has both a title and an HTML label. So we defer to the HTML-AAM whose section 5.1.1 says we should prefer the label element.

What AccName Step 2D says we should do is: "return that alternative in the form of a flat string as defined by the host language". In the comment which follows, AccName says: "For example, in HTML, the img element's alt attribute defines a text alternative string, and the label element provides text for the referenced form element."

It's unclear to me what "return that alternative in the form of a flat string as defined by the host language" means. Does it mean, calculate the accessible name of the label, or return the displayed text of the label? From testing, it seems that most user agents are going with the displayed text, so apparently I'm not the only one.

Anyhoo.... Let's assume calculate.

Step 1.  Set the root node to the label
         Set the current node to the root node (i.e. the label)
         Set the total accumulated text to the empty string ("")
Step 2A. N/A: The current node is NOT hidden.
Step 2B. N/A: Computing a name, but current node lacks aria-labelledby
Step 2C. N/A: Computing a name, but current node lacks aria-label
Step 2D. Applicable? The current node (label) does have a title....

Assuming 2D is applicable, we are instructed to return that alternative in the form of a flat string as defined by the host language". The alternative (title) is "bar". So we exit the inner calculation returning "bar". That's the result for the outer calculation.

Personally, I don't think "bar" should be the result, but the algorithm seems to make it possible.

As for what we'd need to do to reach the point where we include the rendered text ("foo" and "baz" along with the title "bar"), I think we have to reach 2F when calculating the alternative for the label. So in the spirit of thoroughness, let's assume 2D is NOT applicable in the inner calculation (i.e. title is not a valid alternative for a label element).

Step 2E. N/A: Current node is the label; not a control embedded within
         a label or element directly referenced by aria-labelledby.
Step 2F. Applicable: label is a native host language text alternative.

Ok, here we go:

Step 2F   i.  Set the accumulated text to the empty string.
Step 2F  ii.  Prepend the before without a space ("foo")
              Append the after without a space ("baz")
Step 2F iii.  Then it has us descend the children. The only child is the
              input we're trying to calculate the name of.
Step 2F  iv.  Return the accumulated text.

Where do we get the title ("bar") from?? In other words, it seems to me that even if we make it to 2F (which I'm not convinced we do), I don't see anything which says grab the title. And of all the user agents, only Gecko is including the "bar". None of the user agents are including the "bar". The test case was recently modified making the title of the input "buz" instead of "bar" for clarity. With that modification, Gecko now returns "foo buz baz" rather than "foo bar baz".

All of this said, I'm sure I'm missing something. So please explain where in the algorithm above I'm doing the wrong thing. Thanks!

[mcking65]

Gut reaction 1: this should be an unlabeled input that fails miserably. The fact that we would calculate a label almost seems extreme.

Gut reaction 2: I can imagine this kind of stuff exists in the real world and there is some value in calculating a label.

Gut reaction 3: What is the logical conclusion by visual inspection? That is, what would a sightee who knows nothing at all about labeling call the input? Assume they are not rolling their mouse around (the page just loaded), and that person is just asking someone else, "What do you want to put in the blabla field?" What would that person say instead of blabla? If we cannot get to that answer without following the algorithm, then what are our options? This seems like a very important question because it gets at the purpose of guessing the author's intent when it is ambiguous from the code.

I assume the test is visually displayed as something like "foo baz" and that most people would call it the "foo" field? But, without a real life scenario, it is hard to guess. If the real world scenario were "Bring shirts" then it might be called the shirts field. Maybe the bring shirts field.

Step 2D. Applicable? The current node (label) does have a title....

Assuming 2D is applicable, we are instructed to return that alternative in the form of a flat string as defined by the host language". The alternative (title) is "bar". So we exit the inner calculation returning "bar". That's the result for the outer calculation.

It seems like this is the "correct" way to interpret the current spec. This is with the assumption that we should be calculating on the label at all. That means the CSS content does not have a chance of getting included.

BTW, I hate including titles in the calculation at all but accept as a necessary stopgap measure for creating a less sucky life in a world full of lousy accessibility.

We also need to accept that our guessing algorithm is limited and will, ppossibly more often that we like, deliver crappy results. So, we should draw some lines in the sand about just how far we will go to guess. Every step and condition we add to do a better job of guessing in scenario A has the potential to screw up scenario B. If we leave the CSS content out, and if someone bothers to test the label, maybe they will conclude their code is crap and fix it???

[joanmarie]

@mcking65: Thanks for your reactions and thoughts and also for bringing it back to practical/real-world stuff. So, I'll take the sightee challenge, using your bring shirts example, with "bring" replacing "foo" as the before text and "shirts" replacing "baz" as the after text.

Assume they are not rolling their mouse around (the page just loaded), and that person is just asking someone else, "What do you want to put in the blabla field?" What would that person say instead of blabla?

I'd replace blabla with "bring blank shirts" because bring-input-shirts is stuck together looking like a single fill-in-the-blank entity. Then, confused sightee that I am, I'd hover the mouse over the mess in the hopes that I could figure out if an appropriate answer is "blue", "Boston Red Sox", "5", or "medium, women's".

Does this:

1. Tell me what to fix in user agents?
2. Inform me that we should skip this test for AccName 1.1?
3. Get us closer to sorting out what we want to do long term (i.e. in the 1.2 or 1.3 cycle)?

I'm very much interested in 3. And if the answer to 2 is "yes", awesome. But if the answer to 2 is "no", I desperately need an answer to 1 (and arguably needed it a while ago) please and thank you. :smile:

[accdc]

Hi, As requested, I'll summarize what I wrote that the prototype algorithm is doing based on what the spec says. This is just in relation to the title attributes, since CSS content does not count as "text from content" according to the spec, which is why the titles get exposed at all in this test case. In contrast, if CSS content did count as 'text from content', neither of the titles would come into play at all in these test cases.

In reading further, I need to revise my initial assessment. I've spent some time tracing the root node and current nodes, and I found where the disconnect seems to be.

The root node isn't the same thing as the referenced node, as occurs with explicit labels, whether by the label element or by aria-labelledby references. So, in accordance with the spec, it doesn't matter how many labels an element has or how many times multiple labels get stitched together, because the root node is always the first element passed into the function for computation.

This means, only this root node element may have a title attribute that gets processed, and no others on any other elements, because all other elements, even when passed up the tree to parent containers via explicit label references, are technically children of the root node regardless.

So, that means, for these tests, the correct accessible name would be: "foo buz baz"

I've updated the prototype algorithm to reflect this, and it appears to work correctly using this interpretation.

accName: "foo buz baz"

accDesc: "buz"

(Running AccName Computation Prototype version: 2.17)

[devarshipant]

My reading of the computation...

Accessible Name: "foo baz"

Calculated from 2.F.ii:

Check for CSS generated textual content associated with the current node and include it in the accumulated text. The CSS :before and :after pseudo elements [CSS2] can provide textual content for elements that have a content model. For :before pseudo elements, User agents MUST prepend CSS textual content, without a space, to the textual content of the current node. For :after pseudo elements, User agents MUST append CSS textual content, without a space, to the textual content of the current node.

Accessible Description: "buz"

Calculated from 2.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").

Since title is supplemental and provides additional information, 2.D could be:

Otherwise, if the current node's native markup provides an attribute (e.g. title) AND 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").

Total Accumulated Text = "foo baz buz"