Re: ACTION-1474 Rewrite text alternative computation.

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.

[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 -

Received on Monday, 17 November 2014 05:08:05 UTC