(In reply to Alice Boxhall from comment #0)

The Accname-aam is meant to provide the basis for name/description computations.  As such, it is cross-cutting with respect to various markup languages and is meant for HTML, SVG, and DPub, among others.  As such, it is worded in a neutral way as to avoid language specifics, although it does offer examples and commentary using HTML and SVG.  These are informative only and not normative.  

Note that there is one such comment at step 2d:  "For example, in HTML, the img element's alt attribute defines a text alternative string, and the label element provides text for the referenced form element. In SVG2, the desc and title elements provide a description of their parent element."

You are correct.  It is not an exhaustive list.  But, it can't be.  It is up to a markup language specific document, like the HTML-aam to specify how its elements and attributes are used in the name calculation, and how they may override, reinforce, or buttress the basic algorithm.

You wrote that the HTML-aam "... provides text alternative computation steps for (all?) element types ...".  In a sense, it does *not* list all element types since it does not list a single SVG element.  But, that's fine, since this is the HTML-aam, and it should list all (and only) html elements and attributes.  It's up to the SVG-aam to deal with SVG.  And it does, even specifically with respect to step 2d:
http://w3c.github.io/aria/svg-aam/svg-aam.html#mapping_additional_nd

Hope that helps.

Hm - it helps me understand why the accname spec doesn't specify this (which I wouldn't expect it to), but doesn't help me actually correctly implement the acc name calculation in Blink.

For example, http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#accessible-name-and-description-calculation lists the following steps for an <input type=text>:
1. If the control has an aria-label or an aria-labelledby attribute the accessible name is to be calculated using the algorithm defined in Accessible Name and Description: Computation and API Mappings 1.1.
2. Otherwise use the associated label element
3. Otherwise use the placeholder attribute
4. Otherwise use the title attribute
5. Otherwise use the aria-placeholder attribute
6. If none of the above yield a usable text string there is no accessible name

However http://www.w3.org/TR/accname-aam-1.1/#mapping_additional_nd_te has two steps which refer to native markup:
D. Otherwise, if the current node's native markup provides an attribute or element that defines a text alternative, return that alternative as a flat string, unless the element is marked as presentational (role="presentation" or role="none").
and
H. Otherwise, if the current node has a tooltip attribute, return its value.

I'm trying to implement a general purpose algorithm for text alternatives based on Accname-aam which only specialises for these two steps, but trying to merge the two specs leads to ambiguities: in this case, is a `placeholder` or `title` attribute to be considered at step D or step H? I'm going to guess that it's step H, but until we actually have a resource (which would obviously be external to Accname-aam) to explain what markup should be considered for each of steps D and H it's very much a judgement call.

Since this thread is out of date and no longer matches present day AccName spec text, I'll close this for now, but if this is still an issue with the current AccName spec and referenced other specs please file an issue on GitHub for AccName to address in 1.2.