I'm not sure where in this document this should go but I ran across the following interesting case and couldn't see a place where this is specified. 
A site I was looking at had a label specified as
<label for="edit-submitted-your-name">Your name <abbr class="form-required" title="This field is required.">*</abbr></label>

IE & Safari exposed the accessible name of the associated text field as "Your name *"
FF & Chrome exposed it as "Your name This field is required."

FF more or less follows the algorithm [1] which is technically speaking different from ARIA spec alg [2]. I don't know which algorithm IE and Safari implement. Not looking at this particular problem it's a large issue, I tried to start discussion couple years ago [3] but didn't moved far.

[1] http://asurkov.blogspot.ca/2012/11/accessilbe-firefox-text-equivalent.html
[2] http://www.w3.org/TR/wai-aria/roles#textalternativecomputation
[3] http://lists.w3.org/Archives/Public/wai-xtech/2012Mar/0187.html

Does @title on <abbr> define a text alternative? If so, then based on the updated text alternative computation [1], shouldn't the correct accessible name for the text field be "Your name This field is required." as FF and Chrome have it? That is, the accessible name's accumulated text is a combination of the <label>'s text node (rule 2G), "Your name", and the <abbr>'s @title, "This field is required.", as per rule 2D?

Otherwise, if the @title on <abbr> is not considered to define the element's text alternative, does this mean "Your name *" is the correct accessible name, rule 2D for the text node "Your name" and also for the <abbr> text node "*"?


[1] http://w3c.github.io/aria/accname-aam/accname-aam.html#mapping_additional_nd_te

per Firefox impl abbr takes his name from @title attribute over its subtree. However a11y HTML guide doesn't say that [1], but that's rather a bug. If name is a title then it should be part of text field.

[1] file:///Users/alex/mozilla/html-api-map/index.html

Using @title for the name of abbr seems to be covered in the HTML-AAM mapping for @title on abbr [1] and the accname calculation for text level elements [2]. The wording is "Associates the accessible name", but I think that "Provides the accessible name" would be clearer. This seems consistent with what FF does, and would result in the @title on abbr being used in the name for the text field.

Do you still think there's a bug to be filed?

[1] http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#att-title-abbr
[2] http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#text-level-elements-not-listed-elsewhere

The accessible name calculation for text level elements seems incomplete. IMO for most of those elements the child text content should appear in the accessible name computation. This is not specified in the document at all. 

Once this has been corrected we then need to decide whether title should override the child text node in the calculation. Generally in the aria spec it does not - however for abbr I believe maybe it should as title has different behaviour here to its behaviour on most other elements.

(In reply to James Nurthen from comment #6)
> The accessible name calculation for text level elements seems incomplete.
> IMO for most of those elements the child text content should appear in the
> accessible name computation. This is not specified in the document at all.

Agreed.
 
> 
> Once this has been corrected we then need to decide whether title should
> override the child text node in the calculation. Generally in the aria spec
> it does not - however for abbr I believe maybe it should as title has
> different behaviour here to its behaviour on most other elements.

What do you think about breaking out the name calc for abbr and dfn and indicating that @title overrides subtree, and for the remaining text level elements, specify that name comes from subtree, and otherwise @title if no usable subtree (admittedly a rare instance and likely author error)?

Should this be moved somewhere or is it overcome by events?

Cynthia raised more or less the same issue in Jan 2016 in the ARIA GH repo before the HTML-AAM moved to the Web Platform group. Perhaps it's best to follow up there? That issue now lives at https://github.com/w3c/html-aam/issues/25