Re: AccName test expectations bug + prototype bug?

Precedence in that case would be set by the HTML AAM. And two of those
editors tell me it's "foo baz". But I'll look at their spec again and
see if it's addressed.

Thanks!
--joanie

On 09/12/2018 01:50 PM, Carolyn MacLeod wrote:
> Hi, Joanie.
>  
> I guess 2. D. is fuzzy in this case, because it says:
>  
> " if the |current node|'s native markup provides an attribute
> <https://w3c.github.io/accname/#dfn-attribute> (e.g. |title|) or element
> <https://w3c.github.io/accname/#dfn-element> (e.g. HTML |label|) that
> defines a text alternative, return that alternative "
>  
> but the example has both an attribute (title) *AND *an element (label)
> so the returned value is ambiguous.
>  
> Sorry...
> Car
>  
>  
> 
>     ----- Original message -----
>     From: Joanmarie Diggs <jdiggs@igalia.com>
>     To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
>     Cc: ARIA Working Group <public-aria@w3.org>
>     Subject: AccName test expectations bug + prototype bug?
>     Date: Wed, Sep 12, 2018 11:45 AM
>      
>     Hey Bryan, all.
> 
>     In order to get AccName out the door, I'm trying to fix the remaining
>     issues in the implementations. While working on one, and discussing it
>     with others (including the HTML-AAM editors), my conclusion is that our
>     expectations are wrong.
> 
>     One example test case -- which is repeated in multiple variations
>     throughout our test set -- can be found here:
>     https://www.w3.org/wiki/AccName_1.1_Testable_Statements#Name_test_case_661.
>     As you will see there, the expected result is "foo bar baz". That test
>     case has CSS-generated content which is not relevant to the problem at
>     hand, so I'll provide a simpler variant:
> 
>     <label for="test">foo <input id="test" type="button" name="test"
>     title="bar"> baz</label>
> 
>     Beginning the calculation from the AccName spec:
> 
>     1. Root node = input with id="test"
>        Current node = input with id="test"
>        Total accumulated text = ""
> 
>     2. Compute the text alternative for the current node (input with
>        id="test"):
> 
>        A. n/a because the current node is not hidden.
> 
>        B bullet 1. n/a because the current node lacks an aria-labelledby.
> 
>        B bullet 2. n/a because we're not computing a description.
> 
>        C. n/a because the current node lacks an aria-label.
> 
>        D. Does apply because the current node's native markup does provide
>           an attribute (e.g. title) or element (e.g. HTML label) that
>           defines a text alternative. We are instructed to "return that
>           alternative in the form of a flat string as defined by the host
>           language." Therefore, we should return "foo baz" as the accessible
>           name; not "foo bar baz".
> 
>     Do you agree with my assessment? If so, then we need to update the test
>     expectations in WPT and regenerate results based on those expectations.
> 
>     In addition to the above, while I'm pretty sure that Bryan's
>     tool/prototype used to return "foo bar baz" for test case 661, it no
>     longer does. Now it returns accName: "foo bar baz bar". Surely that's
>     not correct (right?).
> 
>     Thanks in advance for your timely responses to these issues (Must. Get.
>     AccName. Out. The. Door! :))
> 
>     --joanie
> 
>      
> 
>  
>

Received on Wednesday, 12 September 2018 18:04:31 UTC