Re: Question about a couple of tests

Joanie,

Q1. I don't like the extra space either and I removed the extra whitespace
in the expected result - so it matches what ARIA 1.1 says we should do
(assuming Joseph's changes go through). These two tests blindly followed
the rules as I saw them.  I think we may have to change something on the
SVG side - perhaps just an editors note and will raise an issue in the SVG
TF. In the super unlikely event, SVG wants to keep the extra whitespace I
will let you know.

Q2.  Yes that was a typo. Now fixed.

                                                              
     Regards,                                                 
                                                              
    Fred Esch                                                 
 Watson, IBM, W3C                                             
  Accessibility                                               
                                                              
 IBM Watson       Watson Release Management and Quality       
                                                              






From: Joanmarie Diggs <jdiggs@igalia.com>
To: Fred Esch/Arlington/IBM@IBMUS
Date: 01/22/2016 03:26 PM
Subject: Question about a couple of tests



Hey Fred and happy Friday! :)

Regarding the following:

// one valid idref, id t1 invalid
if given <circle id="test" aria-describedby="t1 t2" cx='50' cy='100'
r='15'/><text id="t2" x="40" y="90">end</text> then accessible name = "
end"

// one valid idref, id t1 invalid
if given <circle id="test" aria-labelledby="t1 t2" cx='50' cy='100'
r='15'/><text id="t2" x="40" y="90">end</text> then accessible name = "
end"

Q1. I personally think the leading space is not desired.

Looking over the SVG AAM, I don't think it is the cause of this
expectation. I discussed this issue with Joseph and we went over the
AccName text, and the text in 1.1, if followed as written, does indeed
seem to indicate there should be a space as your test expectations
indicate. However....

Looking over the 1.0 name calculation [1], there is language about
trimming whitespace. For instance under 2A, it states:

    User agents will then trim whitespace and join the substrings using
    a single space character.

And if you look at the 1.1 spec [2], way down under 2.F.iii, there's
this Editor's Note:

    (Joseph) the last step above needs work since there are cases where
    you "append with a space" and others where you "append without a
    space". Example of the latter: <label> <input type="checkbox"> Make
    this the <em>top</em>most element</label>. The result is "Make this
    the topmost element", not "Make this the top most element" Б─⌠ do not
    append a space after "top".

Lastly, Joseph (who agrees with me about the leading whitespace not
being desired), asked me to file an issue so he can work on adding the
trimming-and-collapsing stuff from 1.0 into 1.1. But Cynthia already has
[3].

So..... With all this in mind, is the reason why there's an initial
whitespace in the tests I cite above:

a) Inheritance from core
b) It's important to preserve it for SVG accessibility

If the former, we're set; if the latter, I think something in the SVG
AAM is called for.

Q2. In the first test, with aria-described by, is that a copy-and-paste
error with the expectation being that the accessible description (rather
than the accessible name) be " end" (or "end")?

Thanks!
--joanie

[1] https://www.w3.org/TR/wai-aria-implementation/#mapping_additional_nd_te

[2]
https://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html#mapping_additional_nd


[3] https://www.w3.org/WAI/ARIA/track/issues/750



т