Re: AccName test expectations bug + prototype bug?

Having a summary on Monday or Tuesday would be great. Thanks again!!
--joanie

On 9/29/18 9:53 PM, Bryan Garaventa wrote:
> I have little time at the moment, but I can write up a summary on Monday and send it through if that works.
> 
> 
> Bryan Garaventa
> Principle Accessibility Architect
> Level Access, Inc.
> Bryan.Garaventa@LevelAccess.com
> 415.624.2709 (o)
> www.LevelAccess.com
> 
> -----Original Message-----
> From: Joanmarie Diggs <jdiggs@igalia.com> 
> Sent: Friday, September 28, 2018 11:17 AM
> To: Bryan Garaventa <bryan.garaventa@levelaccess.com>
> Cc: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com>; nurthen@adobe.com; public-aria@w3.org
> Subject: Re: AccName test expectations bug + prototype bug?
> 
> Thanks for the detailed reply! Given that we need to fix issues which are blocking us from exiting CR, which includes the issue at hand, I could use an executive summary and specific conclusion. In particular:
> 
> 1. Given the language currently in AccName, what should the expected
>    results be?
> 
> 2. Is the language in the current spec sufficiently clear that
>    implementors should reach that same conclusion?
> 
> As for everything else you say, if you have some spare cycles to file new issues (e.g. on the CSS generated content) that would be great.
> 
> Thanks again!
> --joanie
> 
> On 9/28/18 1:50 PM, Bryan Garaventa wrote:
>> Rather than comment on github yet, I'll reply here since this will probably open up a debate.
>>
>> One problem has to do with the assumption that CSS rendered text is the same thing as "text from content" in accordance with the spec, and the spec does not actually state this, it only says if present, prepend and append this if found to what the algorithm already states.
>>
>> So according to the spec, CSS rendered content is not 'text from content', so it doesn't qualify as being a valid name in the calculation besides adding it to what the computation already returns without it being there at all.
>>
>> So the first question is, should CSS content be considered the same as 'text from content'? If yes, this will change lots of things everywhere.
>>
>> If no, we can remove the CSS content from this example just for the sake of this discussion, and then all we are left with is the title on the label or the title on the input, and the question then is, which one is considered to be the valid name?
>>
>> As you recall last week, you asked me to fix the bug where the title attribute was incorrectly being set on child nodes that are being parsed from the root node, which in this case is the outer label element, as referenced by aria-labelledby.
>>
>> According to the spec then, where label is the root node, since there is no aria-label, nor 'text from content' (because CSS content doesn't apply), nor is there a valid value property for an embedded form field, the next attribute on the list to check is the title, which is set on the root node (also the current node), so this is what gets returned as the name.
>>
>> So, since the original input is not the root node, nor does it qualify as an embedded element with a name such as a form field with a value, it's title attribute never comes into play.
>>
>> Even if CSS content were changed to be considered 'text from content', this still wouldn't change the issue, because the title attribute on the embedded element would still be ignored because only the value property is valid on embedded form fields as children of the root node.
>>
>> If you want me to fix it where the title on embedded elements is returned as an accessible name though, be aware this will change everywhere, not just here.
>>
>>
>>
>>
>> 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: Friday, September 28, 2018 8:14 AM
>> To: Bryan Garaventa <bryan.garaventa@levelaccess.com>
>> Cc: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com>; nurthen@adobe.com; 
>> public-aria@w3.org
>> Subject: Re: AccName test expectations bug + prototype bug?
>>
>> Thanks Bryan. I'm afraid, however, I'm still not convinced that the outer title "bar" gets used. And only Gecko is using it; all of the other user agents are not. So I spent some time writing out in painful deal what I think the algorithm says to do and opened an issue against AccName.
>>
>> It would be super helpful if people could read over it and tell me why I (and all implementors sans Mozilla) are wrong as **clearly demonstrated in the language of the AccName spec.** If I am wrong, I promise to finally shut up about this one and fix WebKit and Blink. :) Otherwise, I say we skip these two tests and fix the issue in 1.2.
>>
>> Here's the issue: https://github.com/w3c/accname/issues/31
>>
>> Sorry for being dense. And thanks for all your help!
>> --joanie
>>
>> On 9/27/18 11:23 PM, Bryan Garaventa wrote:
>>> Got it, they should now match. :)
>>>
>>>
>>> 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: Thursday, September 27, 2018 10:15 AM
>>> To: Bryan Garaventa <bryan.garaventa@levelaccess.com>
>>> Cc: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com>; nurthen@adobe.com; 
>>> public-aria@w3.org
>>> Subject: Re: AccName test expectations bug + prototype bug?
>>>
>>> Thanks Bryan.
>>>
>>> Ok, I changed 659 and 660 on the wiki so that the title of the input is "buz" rather than "bar". Could you please update your tool to reflect that change?
>>>
>>> Thanks again!
>>> --joanie
>>>
>>> On 9/27/18 12:59 PM, Bryan Garaventa wrote:
>>>> Hi,
>>>> Sorry for the delay, been out sick this week.
>>>>
>>>> This looks correct to me.
>>>>
>>>> These were the test that I recommended changing the title="bar" on the input element to "buz" instead, because it's hard to know what is happening when it matches the title on the outer label.
>>>>
>>>> Basically, only the outer title is computed as the name, and the CSS before and after content is prepended and appended accordingly to that, which I believe matches what the spec says.
>>>>
>>>> The second title="bar" is being added to Description however, because only the value of embedded nodes is supposed to be processed on form fields and not any other naming mechanism. So if that was changed to title="buz" it would show this more clearly.
>>>>
>>>>
>>>> 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: Wednesday, September 26, 2018 9:54 AM
>>>> To: Bryan Garaventa <bryan.garaventa@levelaccess.com>
>>>> Cc: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com>; nurthen@adobe.com; 
>>>> public-aria@w3.org
>>>> Subject: Re: AccName test expectations bug + prototype bug?
>>>>
>>>> Hey Bryan, all.
>>>>
>>>> Can you please check other tests, for instance 659 and 660. When I 
>>>> try 
>>>> https://whatsock.github.io/w3c-alternative-text-computation/Autogene
>>>> r
>>>> a
>>>> ted%20AccName%201.1%20Testable%20Statements%20-%20W3C/Name%20test%20
>>>> c a se%20659.html, it says the name is "foo bar baz". Is that 
>>>> correct?
>>>>
>>>> Thanks!
>>>> --joanie
>>>>
>>>> On 9/13/18 2:10 PM, Joanmarie Diggs wrote:
>>>>> I updated the tests which are impacted. Thanks!
>>>>> --joanie
>>>>>
>>>>> On 09/13/2018 01:22 PM, Bryan Garaventa wrote:
>>>>>> There is a drawback to this however, since the change now 
>>>>>> invalidates test 661 at 
>>>>>> https://www.w3.org/wiki/AccName_1.1_Testable_Statements
>>>>>>
>>>>>> Which you can run using the link below the heading of that test to see what I mean.
>>>>>>
>>>>>> So there are likely other places where this will occur as well. Small changes impact everything...
>>>>>>
>>>>>>
>>>>>>
>>>>>> Bryan Garaventa
>>>>>> Accessibility Fellow
>>>>>> Level Access, Inc.
>>>>>> Bryan.Garaventa@LevelAccess.com
>>>>>> 415.624.2709 (o)
>>>>>> www.LevelAccess.com
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Bryan Garaventa <bryan.garaventa@levelaccess.com>
>>>>>> Sent: Thursday, September 13, 2018 10:00 AM
>>>>>> To: Joanmarie Diggs <jdiggs@igalia.com>; Carolyn MacLeod 
>>>>>> <Carolyn_MacLeod@ca.ibm.com>
>>>>>> Cc: nurthen@adobe.com; public-aria@w3.org
>>>>>> Subject: RE: AccName test expectations bug + prototype bug?
>>>>>>
>>>>>> For the markup,
>>>>>>
>>>>>> <label for="test">foo <input id="test" type="button" name="test" 
>>>>>> title="bar"> baz</label>
>>>>>>
>>>>>> I have the result for
>>>>>>
>>>>>> accName: "foo baz"
>>>>>>
>>>>>> accDesc: "bar"
>>>>>>
>>>>>> (Running AccName Computation Prototype version: 2.16)
>>>>>>
>>>>>> There was a bug in that processing which I fixed a few minutes ago, but title shouldn't be processed on subnodes of a tree and added to name.
>>>>>>
>>>>>> 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: Wednesday, September 12, 2018 3:10 PM
>>>>>> To: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com>
>>>>>> Cc: Bryan Garaventa <bryan.garaventa@levelaccess.com>;
>>>>>> nurthen@adobe.com; public-aria@w3.org
>>>>>> Subject: Re: AccName test expectations bug + prototype bug?
>>>>>>
>>>>>> On 09/12/2018 05:39 PM, Carolyn MacLeod wrote:
>>>>>>> The 2 spaces is for your simpler variant:
>>>>>>> <label for="test">foo <input id="test" type="button" name="test"
>>>>>>> title="bar"> baz</label>
>>>>>>
>>>>>> Right. Though whether or not it should be is, I think, up to the HTML-AAM. What implementors are actually doing is another question, but, again, I believe what they do is simplify/collapse whitespace.
>>>>>>
>>>>>>> As for the CSS ::before and ::after content in test case 661 
>>>>>>> <https://www.w3.org/wiki/AccName_1.1_Testable_Statements#Name_tes
>>>>>>> t _ c as e_661>, I guess the accessible name would be "foobaz" 
>>>>>>> (no
>>>>>>> space?)
>>>>>>
>>>>>> Another question for the group. My guess is that we (the group) assume it should be "foo baz", but what's in AccName step 2.F.ii suggests to me that the space wouldn't be there. Thursday's going to be a fun meeting.
>>>>>> I can tell. :)
>>>>>>
>>>>>>> and the
>>>>>>> accessible description would be " bar " (with space before and 
>>>>>>> after?), except that I'm not really sure about those.
>>>>>>
>>>>>> Me neither. Another topic for Thursday I guess.
>>>>>>
>>>>>> --joanie
>>>>>>
>>>>>
>>>>
>>>
>>
>

Received on Sunday, 30 September 2018 11:13:33 UTC