Re: ACTION-1474 Rewrite text alternative computation.

On Mon, Nov 17, 2014 at 12:07 AM, Joseph Scheuhammer <clown@alum.mit.edu>
wrote:

> Hi Dominic,
>
> Thanks for your comments.  Replies inline, below.
>
> On 2014-11-07 2:55 PM, Alexander Surkov wrote:
>
>>
>>
>> On Fri, Nov 7, 2014 at 2:43 PM, Dominic Mazzoni <dmazzoni@google.com
>> <mailto:dmazzoni@google.com>> wrote:
>>
>>     Thanks for taking this on! It's great to have the accessible name
>>     and description calculation in the form of an algorithm.
>>
>>     Here's some initial feedback:
>>
>>     (1) F.iii: You shouldn't always append spaces when concatenating
>>     the text alternatives of children. As an example:
>>
>>     <label>
>>       <input type="checkbox">
>>       Make this the <em>top</em>most element
>>     </label>
>>
>>     The correct accessible text is "Make this the topmost element",
>>     not "Make this the top most element". Similarly for the :before
>>     and :after pseudoclasses - they're appended with no whitespace.
>>
>>     I'm not sure how to resolve this, but as a first stab, how about:
>>     do not add extra whitespace when the previous and next elements
>>     are both inline and their text both comes from contents.
>>
>>
>> I don't recall what we do in Firefox but I agree that space should not be
>> required for inline text elements. So for example if that was a button
>> surrounded by text then spaces would be still needed. I think I would word
>> it flexible until we are confident we considered all scenarios.
>>
>
> I agree as well.  I'll replace the definition of "Append the result to X"
> with two new definitions:  "Prepend/append the result to X with a space"
> and "Prepend/append the result to X without a space", and then indicate
> where the two apply.
>
>>
>>
>>     (2) In the mapping table for aria-labelledby: should talk about
>>     "referenced objects", not a single "referenced object". Should
>>     explain what to do if some of the referenced objects are visible
>>     and others are not.
>>
>>
> I'll reword it.  Using MSAA+IA2 as an example:
> "If the referenced objects are in the accessibility tree expose pointers
> to them using |IA2_RELATION_LABELLED_BY| and expose reverse relations as
> described in Relations."
>
> Regarding invisibility, that's what the antecedant "If the referenced
> objects are in the accessiblity tree ..." is meant to cover.
>
>
>>     (3) The algorithm is incomplete for AXAPI. The text alternative
>>     algorithm gives explicit instructions on how to construct a
>>     string, and then the mapping table says to map that to AXTitle or
>>     AXDescription. The current behavior of Safari is to expose the
>>     visible text in AXTitle and ALSO the alternative text in
>>     AXDescription, so for example <button
>>     aria-label="Bar">Foo</button> would get an AXTitle of "Foo" and
>>     AXDescription of "Bar". The algorithm should handle that case,
>>     unless the Apple folks specifically want to change it.
>>
>>
> When I ran your <button> example in Safari, the Inspector app showed
> AXTitle as empty, and AXDescription as "Foo", which is what the accessible
> name row of the mapping table states for AXAPI.  I used Safari 6.2/OS X
> 10.8.5.
>
>
>>     (4) I'm not sure it does the right thing for a link with a
>>     tooltip. Consider:
>>
>>     You can read more about <a
>>     href="http://en.wikipedia.org/wiki/Russia" title="Russia">his home
>>     country</a> on Wikipedia.
>>
>>
> I'm not completely sure either, ;-).  The link role, which is applicable
> here, takes its accessible name from content or from author [1].  My guess
> is that since the @title attribute is used for the tooltip, the title text
> is used for the accessible description -- tooltips are generally used as
> additional descriptive information to support a label.  That leaves the
> content of the link for the accessible name.  That, at least, is consistent
> with the html mapping document with respect to names and descriptions for
> the <a> element [2].
>
>
>>     Firefox currently exposes "his home country" as the name, and
>>     "Russia" as the description. Both NVDA and JAWS read out the name
>>     first, but also read out the description when it has focus. The
>>     algorithm needs to handle this case. It needs to handle both the
>>     case where other text and the tooltip are present, and the case
>>     where the tooltip is the only provided text.
>>
>>
> Agreed, but this is more than just an editorial change, and likely
> requires further discussion.
>

Would the rule "the description never dupes the name" resolve it? So if for
example, you get the description text equal to the name at certain step
then proceed to the next step.


>
> [1] http://rawgit.com/w3c/aria/master/aria/aria.html#link
> [2] http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#a-element
>
>
> --
> ;;;;joseph.
>
> 'Array(16).join("wat" - 1) + " Batman!"'
>            - G. Bernhardt -
>
>