RE: AccName test expectations bug + prototype bug?

Hi Jonie,
When you go through expected results within the test cases, it might be a good idea to look at test 659, because the use of repetitive information makes it unclear what the algorithm is meant to do. There are two instances of title="bar".

    <label for="test" title="bar"><input id="test" type="text" name="test" title="bar"></label>

There is CSS pseudo element text in that test too, but according to the computation I have running, only the title on the label is added because it is the first referenced part of the label and there is no other labelling mechanisms that apply prior to that. Since the same title is in the input though, it's not clear where and what is being applied and when.

I recommend changing the test to the following instead, which uses title="buz" on the input to clarify this.

<style type="text/css">
    label:before { content: "foo"; }
    label:after { content: "baz"; }
  </style>

  <form>
    <label for="test" title="bar"><input id="test" type="text" name="test" title="buz"></label> 
  </form>

Then the expected result is:

accName: "foo bar baz"

accDesc: "buz"

(Running AccName Computation Prototype version: 2.16)


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

-----Original Message-----
From: Bryan Garaventa 
Sent: Thursday, September 13, 2018 10:23 AM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com>; 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?

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_test_cas

> 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 Thursday, 13 September 2018 18:00:53 UTC