RE: Yet another AccName sanity check: Name from non-embedded input's value

Hi,
When I originally created the algorithm the value was omitted, but when I compared this with the expected results listed on the testable statements during initial testing, I added this to the computation because it stated that this was the expected result.
https://www.w3.org/wiki/AccName_1.1_Testable_Statements#Name_test_case_558_.5BFIXME:_VERIFY.5D 

I agree though, there is no mention of this in the naming computation,. This is already removed, so all of the testable statements that state incorrect expected results based on obj.value when directly referenced will need to be updated on the wiki.

Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com
415.624.2709 (o)
www.LevelAccess.com

-----Original Message-----
From: Joanmarie Diggs <jdiggs@igalia.com> 
Sent: Monday, March 19, 2018 1:01 PM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com>
Cc: ARIA Working Group <public-aria@w3.org>
Subject: Yet another AccName sanity check: Name from non-embedded input's value

Hey Bryan and others interested in AccName.

I'm still validating test cases as part of fixing implementation bugs and found another instance where I think the current implementations are correct (according to the algorithm) and our expectations (WG and Bryan's tool) are wrong. The case in question is test case #558:

====
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"
====

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.
* 2J doesn't apply: Because there is no 2J. But I bet you didn't know
  that without looking at the spec because the algorithm is insanely
  long and you lost count some time ago. :)

End of options. Empty string. And that's what the implementations say too. What say y'all?

Thanks in advance!
--joanie

Received on Tuesday, 27 March 2018 17:36:52 UTC