whatsock / w3c-alternative-text-computation Goto Github PK

Testing out this markup:

<label for="test">Some Text</label>
<progress id="test" max="100" value="33"></progress>

using the alternative text computation tool:
https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html

shows no accessible name. As a element listed under Forms:
https://www.w3.org/TR/2014/REC-html5-20141028/forms.html#the-progress-element

I would expect the computation of the acc name to fall under §4.1.7 of the Accessible Name Computation:
https://www.w3.org/TR/2014/REC-html5-20141028/forms.html#the-progress-element
where item 2 says to use the label.

Other places imply that label can be used if there is a role=progressbar
https://www.w3.org/WAI/ARIA/apg/practices/names-and-descriptions/

but this seems to both be redundant and also makes no apparent difference in the calculated output of the accessible name. Am I missing something important or is this just a bug?

Provided this input:

<img src="foo.jpg" id="test" alt="test" aria-labelledby="t1">
<div id="t1" style="visibility:hidden">foo</div>

The calculated accname is "foo", but if we add an internal, inline node like this:

<img src="foo.jpg" id="test" alt="test" aria-labelledby="t1">
<div id="t1" style="visibility:hidden"><span>foo</span></div>

The result is "test".

In this example, the link is not hidden, but the sample implementation will still ignore it:

<style>
a {
	display: initial !important;
}
</style>

<a style="display: none">test</a>

According to ARIA, the name for a row (and also rowgroup) should be computed from its contents. The implementation fails to do that:

https://xi.github.io/babelacc/?input=%3Cdiv+role%3D%22row%22%3Efoo%3C%2Fdiv%3E

In HTML there are two ways to associate a label with an input element:

<label>
  Wrapped
  <input>
</label>

<label for="foo">
  Via ID
</label>
<input id="foo">

Only the latter is handled correctly.

The expected result of the "Name checkbox-label-embedded-listbox" test case is "Flash the screen 1 times." I think this might be incorrect, given the language in AccName. We need to verify it and either update the test case or change the language of the spec.

I assume that the rationale for including the "1" in the calculation is that it is the selected option. But the AccName spec's step 2E states, "If the embedded control has role combobox, return the text alternative of the chosen option." In this test case, the role is listbox; not combobox. And none of the other items in 2E seem to cover this case.

(Originally posted by me on the public-aria list)

I'm now working on the test cases where the expected result includes "Garaventa the weird." Both Firefox and WebKit have results which include "Eli" instead of "Garaventa." Looking at the AccName algorithm, I think Firefox and WebKit are correct.

Searching the algorithm, I see only one mention of the presentational role, namely in step 2D, which states:

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").

Comment:
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. In SVG2, the desc and title elements provide a description of their parent element.

Looking at your test case, the markup relevant to which name is chosen is this bit:

<span role="presentation" aria-label="Eli">
  <span aria-label="Garaventa">Zambino</span>
</span>

While the presentational role is applied to the outer span, my understanding of an attribute provided by the node's native markup is something specific to HTML. The aria-label attribute can be used on HTML
of course; but the aria-label attribute is not provided by HTML. So my read of step 2D is that technically "Eli" should be chosen.

Furthermore, in the case where the thing being calculated is a name, I don't think we'd get to step 2D because step 2C states:

Otherwise, if computing a name, and if the current node has an aria-label attribute whose value is not the empty string, nor, when trimmed of white space, is not the empty string:

• If traversal of the current node is due to recursion and the current node is an embedded control as defined in step 2E, ignore aria-label and skip to rule 2E.
• Otherwise, return the value of aria-label.

Step 2C doesn't say anything about the presentational role. And the current node is not an embedded control as defined in step 2E. So why don't we want to use the aria-label value of "Eli"?

Is it intentional that the whitespace is added based on initial instead of actual styling? Consider the following example:

<button>
  <h1 style="display:inline">foo</h1><h1 style="display:inline">bar</h1>
</button>

https://xi.github.io/babelacc/?input=%3Cbutton%3E%0D%0A++%3Ch1+style%3D%22display%3Ainline%22%3Efoo%3C%2Fh1%3E%3Ch1+style%3D%22display%3Ainline%22%3Ebar%3C%2Fh1%3E%0D%0A%3C%2Fbutton%3E

I would expect there to be no whitespace since both elements are styled as inline. However, this implementation adds whitespace.

The sample implementation adds and removes whitespace,which it shouldn't. Example: The test cases contained in the repository should output the following name:

My name is Garaventa the weird. (QED) Where are my marbles?

This is the actual result:

My name is Garaventa the weird. ( Q E D ) Where are my marbles?

For this test case:

if given
  <div id="test" role="combobox" tabindex="0" title="Choose your language.">
    <span> English </span>
  </div>
then the accessible name of the element with id of "test" is "Choose your language. English"

I question the expected result which matches what is in the WhatSock tool. In particular, I don't think "English" should be included. Walking through the steps in the AccName algorithm, setting the current node to the div with id of "test":

• 2A doesn't apply because the current node isn't hidden.
• 2B doesn't apply because the current node lacks an aria-labelledby attribute
• 2C doesn't apply because the current node lacks an aria-label attribute
• 2D does apply, because the current node's native markup does provide an attribute (e.g. title) that defines a text alternative.

2D's instructions are: "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")." The alternative defined by the host language is the value of the title attribute, namely "Choose your language." So we return that attribute and end the calculation. This is, btw, what both Firefox and WebKit do.

According to html-aam-1.0, the hidden attribute maps to aria-hidden="true". This implementation seems to rely on the fact that hidden also visually hides the element.

Example: https://xi.github.io/babelacc/?input=%3Ch1+style%3D%22display%3Ablock%22+hidden%3Efoo%3C%2Fh1%3E

<input id=test>

<label for=test>
before
<input value=value aria-labelledby=aria disabled role=presentation>
after
</label>

<div id=aria>aria-labelledby</div>

input with id=test should not use Step 2E (use the value of the 2nd input because it has not role=textbox due to role=presentation) but Step 2B (use aria-labelledby). It works correct in Chrome

Test case expectation discrepancies

1. Name test case 543. Becase "Reset" is the displayed text on the push button, and there is no other name source, "Reset" should be exposed as the accessible name. WhatSock's tool shows the empty string as the calculated accessible name. Please verify that the spec includes this scenario in its algorithm and that the error is in the tool.

2. Name test cases 548, 733, 734, 735, 736, and 737. (These are essentially the same test, but with a different input type.) Our expectation is "crazy clown"; WhatSock's tool shows "crazy beard". Please verify the tool is correct according to the algorithm in the spec.

3. Name test case 600. Our expectation is the empty string; WhatSock's tool shows "Div with text". In this particular case, I think our expectation is correct. We do not want divs (or paragraphs or any other non interactive, textual element) to have accessible name calculated from content. Many divs, etc. have a bunch of text. And at least some screen readers will present the accessible name if there is one. Imagine arrowing down into a huge div/paragraph and having the screen reader spew out its full contents.

4. Name test cases 661, 662, 663, and 663a. (These are essentially the same test, but with a different input type.) Our expectation is a name of "foo bar baz"; WhatSock's tool is a name of "foobaz" and a description of "bar". I'll add a description test for the same markup. In the meantime, please verify the tool is correct according to the algorithm in the spec.

5. Name test cases checkbox-label-embedded-combobox, file-label-embedded-combobox, password-label-embedded-combobox, radio-label-embedded-combobox, text-label-embedded-combobox. (These are essentially the same test, but with a different input type.) Our expectation is a name of "Flash the screen 1 times." WhatSock's tool is a name of "Flash the screen 1 2 3 times." Here the numbers come from the list item text, and only the item with "1" has aria-selected="true". Is this scenario covered by the algorithm? If not, it should be. If it is, please verify that the tool has the correct expectations.

6. Name test cases checkbox-label-embedded-menu, file-label-embedded-menu, password-label-embedded-menu, radio-label-embedded-menu, text-label-embedded-menu. (These are essentially the same test, but with a different input type.) Our expectation is a name of "Flash the screen 1 times." WhatSock's tool is a name of "Flash the screen times." This is a variant of the previous test case. Determining whether or not our algorithm covers inclusion of aria-selected="true" in the name calculation is needed.

Name test case 558 says:

if given
  <input type="text" value="peanuts" id="test">
  <img aria-labelledby="test" src="foo.jpg"/>
then the accessible name of the element with id of "test" is "peanuts"

And this expectation is confirmed by the WhatSock tool.

But I don't think this is correct. As I originally posted on the ARIA mailing list:

The image is labeled by the input. But the only thing exposed by the input is the value attribute. So calculating the name from the input beginning with step 2 (i.e. current node is the input), we get:

• 2A doesn't apply: The input is not hidden
• 2B doesn't apply: Calculating a name; the input lacks aria-labelledby
• 2C doesn't apply: Calculating a name; the input lacks aria-label
• 2D doesn't apply imho: I don't see value as an attribute that defines a text alternative. And when I look at the name calculation stuff in HTML AAM, it doesn't say value is such an attribute. See section 5.1.1.
• 2E doesn't apply: The input is not embedded within the label for another widget (emphasis added). So while the input is referenced by aria-labelledby, I think that's trumped by the fact that what references it is an image rather than a widget.
• 2F doesn't apply: Input/textbox doesn't allow name from content.
• 2G doesn't apply: Input is not a text node.
• 2H doesn't apply: The input is not a descendant of an element whose name is being computed.
• 2I doesn't apply: The input lacks a tooltip attribute.

End of options. Empty string. And that's what the implementations say too.

I have a question regarding the results for this test case:

if given
  <label>This <input type="checkbox" id="test" /> is</label>
  <label for="test">a test</label>
then the accessible name of the element with id of "test" is "a test"

The WhatSock version of the above test case

Set current node to input with ID of test (the input) and start algorithm:

• 2A doesn't apply because the input is not hidden
• 2B doesn't apply because the input lacks an aria-labelledby attribute
• 2C doesn't apply because the input lacks an aria-label attribute
• 2D does apply because the input's native markup provides an element that defines a text alternative

2D says: "return that alternative in the form of a flat string as defined by the host language, unless the element is marked as presentational" The element is not market as presentational. So what does the host language state/define? Section 5.1.1 of the HTML AAM, item 2 says:

Otherwise use the associated label element(s) accessible name(s) - if more than one label is associated; concatenate by DOM order, delimited by spaces.

There is more than one label associated: the label containing the checkbox and the label with the for attribute. Processing them in DOM order would, I think, result in the full label being "This is a test" rather than "a test".

I think we have a similar situation with the alternative version of this test case:

if given
  <label for="test">a test</label>
  <label>This <input type="checkbox" id="test" /> is</label>
then the accessible name of the element with id of "test" is "a test"

The WhatSock version of the alternative test case

The algorithm work seems like it would be the very same, so we have to do what 2D states, namely return both labels in DOM order separated by a space. The only difference with this alternative is that "a test" preceeds "This is". So I would expect the label to be "a test This is".

AccName test case 737 has the following:

if given
  <label for="test">
    crazy
    <select name="member" size="1" role="menu" tabindex="0">
      <option role="menuitem" value="beard" selected="true">clown</option>
      <option role="menuitem" value="scuba">rich</option>
    </select>
  </label> 
  <input type="image" id="test" src="foo.jpg"/>
then the accessible name of the element with id of "test" is "crazy clown"

That test case can be found here and confirms that expectation: https://whatsock.github.io/w3c-alternative-text-computation/Autogenerated%20AccName%201.1%20Testable%20Statements%20-%20W3C/Name%20test%20case%20737.html

But most user agents are only returning a name of "crazy." Looking at the AccName spec, I see that step 2.E's third bullet states:

If the embedded control has role combobox, return the text alternative of the chosen option.

And if I change the test case to have role combobox the user agents do the right thing. Therefore, could you please recheck your expected result and confirm it is correct or correct it? Also, if you correct it, could you please update your test cases so that following the link I mentioned above reflects the new expectation? I'll then update the AccName tests accordingly.

Thanks in advance!