Re: Name and Description computation -- Proposed new texts

Hi Amelia,

I wrote:
 > Just a note to say I've skimmed it and realized it's going to take me 
a while to give it the attention it deserves.  I'll be picking away at 
it as time permits.

I am working through your changes, and am concentrating on the changes 
to the core algorithm (accname-aam.html) for now.  Rather than wait 
until I've gone through a complete analysis, I've decided to start by 
commenting on some of the changes I've noticed, and followup with more 
as I go along.

First off, this is a good refactoring of the algorithms -- thanks for 
taking the time to do it.  Having a document that describes the basic, 
core aspects of the text alternative computation (TAC), and having other 
documentation of how different markup languages modify or enhance the 
basic TAC is why accname-aam.html was separated out from the Core-AAM 
and ARIA specs in the first place.

Secondly, I'm not sure of the best place to make comments.  My 
preference would be to either raise issues on github, or use W3C's 
bugzilla its issue tracker.  Email is my last choice, but since that is 
where the comments are currently being logged, I'll stay with the flow.

* "Authors should/must provide a name" (Section 4.2)
(https://rawgit.com/AmeliaBR/aria/acc-name/accname-aam/accname-aam.html#mapping_additional_nd_name)

This is true, but I don't think it belongs here, as you suggested in an 
editor's note.  The primary target audience is user agent implementers, 
and possibly checking tools.

Having said that, authors do need guidance, and there should be a 
companion document for authors.  Perhaps the "HTML5: Techniques for 
providing useful text alternatives" 
(https://w3c.github.io/alt-techniques), or add a section to the 
"Authoring Practices Guide" (http://www.w3.org/TR/wai-aria-practices-1.1/).

* "Root node" vs. "original node" (Section 4.1)
(https://rawgit.com/AmeliaBR/aria/acc-name/accname-aam/accname-aam.html#terminology)

It's a good idea to change the term since the "root node" is not always 
a root in the sense of using its descendent nodes for the computation. 
For example, the "root node" could have an aria-labelledby that 
references one of its grandfather's siblings.

However, I'm not keen on the term "original".  Two terms that may be 
better are "target" or "primary".  "Target" communicates that this is 
the element for which the TAC is being run.  However, "target" might 
have too much association with DOM events, as in "event target".

"Primary" doesn't have that DOM event baggage but it doesn't convey as 
well that it's the object of the computation.  There may be other terms 
that are better here -- "base" or "basis node"?

* Example showing aria-labelledby is only "one hop". (Example in Step 1B)
(https://rawgit.com/AmeliaBR/aria/acc-name/accname-aam/accname-aam.html#step-element-ariaby-join)

An aria-label has been added to the example that shows the meaning of 
"if not already processing an aria-labelledby traversal". The original 
version of the example did not have an aria-label ("Example 1" at step 
2B [http://www.w3.org/TR/accname-aam-1.1/#step2B]).

The point of the example is to show that if the computation is 
processing aria-labelledby, it does not process any subsequent 
aria-labelledby.  You can think of it as setting a "labelledby" state, 
and, while in that state, the TAC does not follow any aria-labelledby on 
the labelling node.  The original example used elements that had 
aria-labelledby attributes only.  Adding an aria-label is distracting 
since it adds a question about the precedence and interaction of 
aria-labelledby and aria-label.  I would remove the aria-label from this 
example to keep focus on the aria-labelledby restriction.

Regarding precedence of the aria-labelledby over aria-label, that is 
implicit in the way the current TR of the TAC is worded.  If 
aria-labelledby is encountered, it's used to compute the name.  Any 
aria-label on the same element is ignored, with one exception (there's 
always an exception).  There is an example of how the two can combine in 
the current TR, specifically when aria-labelledby points "to itself".  
If that self-same element has an aria-label, then that aria-label *is* 
used.  Here is a very simple example, where the name is "Alfred":

<input id="self" aria-labelledby="self" aria-label="Alfred">

Example 2 in the current TR provides an more complex version of this at 
step 2C (http://www.w3.org/TR/accname-aam-1.1/#step2C).  I've repeated 
part of it below, where the <span> with role="button" has the name 
"Delete Documentation", composed from a self-referential aria-labelledby 
and its aria-label:

 >     <a id="file_row1" 
href="./files/Documentation.pdf">Documentation.pdf</a>
 >     <span role="button" tabindex="0" id="del_row1" 
aria-label="Delete" aria-labelledby="del_row1 file_row1"></span>

* Removal of embedded menu button from Step 2.
(https://rawgit.com/AmeliaBR/aria/acc-name/accname-aam/accname-aam.html#step-element-embedded-control)

There's an editor comment about removing the menu button as an embedded 
control since it "... did not seem to be consistent with the concept of 
menus as a collection of distinct commands (rather than as a 
selection)."  Perhaps, but menu buttons are used that way.  Here are a 
couple of screen shots showing that usage, taken from one of OS X's 
System Preferences dialogs.
http://clown.idrc.ocad.ca/Fluid/aria/MenuButtonPix.html

In another email thread, Jon and Nick have suggested dropping the term 
"menu" and just saying "button" in this case.  That might be better, but 
I had thought that "menu button" was clearer, and would give the reader 
an idea of why a button was involved here.  Perhaps the document should 
just say "button" here, and point to a usage involving a menu button for 
clarification.

That's it for now; more to come.

-- 
;;;;joseph.

'Array(16).join("wat" - 1) + " Batman!"'
            - G. Bernhardt -

Received on Monday, 30 November 2015 15:09:41 UTC