HTML-AAM: should aria-placeholder be used for accessible description on elements?

[cyns]

in 5.1.1, aria-description is used for name calculation, but it is not used in 5.1.2 for description calculation, even if it was not used as the name. Is this intentional? If so, what's the rationale?

[cyns]

@stevefaulkner @jasonkiss another question for you

[cyns]

@AmeliaBR any thoughts on this one?

[stevefaulkner]

@cyns unclear what you mean are you talking about "aria-placeholder attribute" being in accname but not accdescription calc?

[cyns]

yes, sorry, aria-placeholder. changed it.

[cyns]

I think, if it's following general rules, that it would come after label and before placeholder.

[cyns]

@stevefaulkner @AmeliaBR
How about adding aria-placeholder as step 4, between label and placeholder?

[jasonkiss]

@cyns, are you suggesting the following?

5.1.1 input type="text", input type="password", input type="search", input type="tel", input type="email", input type="url" and textarea Element Accessible Name Calculation

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(s) accessible name(s) - if more than one label is associated; concatenate by DOM order, delimited by spaces.
3. Otherwise use the aria-placeholder attribute.
4. Otherwise use the placeholder attribute
5. Otherwise use the title attribute
6. If none of the above yield a usable text string there is no accessible name

5.1.2 input type="text", input type="password", input type="search", input type="tel", input type="email", input type="url" and textarea Element Accessible Description Calculation

1. If the element has an aria-describedby attribute the accessible description is to be calculated using the algorithm defined in Accessible Name and Description: Computation and API Mappings 1.1.
2. Otherwise use the aria-placeholder attribute if it wasn't used as the accessible name.
3. Otherwise use the placeholder attribute if it wasn't used as the accessible name
4. Otherwise use the title attribute if it wasn't used as the accessible name.
5. If none of the above yield a usable text string there is no accessible description

[AmeliaBR]

@jasonkiss's suggestion makes sense to me. Make the text available one way or the other.

[cyns]

@jasonkiss yes, that's what I was suggesting. make sense?

[dstorey]

Apologies if I'm misunderstanding this, but the placeholder mapping spec states:

"When the placeholder and aria-placeholder attributes are both present, and the placeholder attribute's value is non-empty, user agents must expose the value of the placeholder attribute, and ignore aria-placeholder. If the placeholder attribute's value is empty, then user agents must expose the value of the aria-placeholder attribute." – https://w3c.github.io/aria/html-aam/html-aam.html#att-placeholder

…so it would seem weird to me if aria-placeholder wins out in step 2 over placeholder in step 3. Shouldn't it be the other way around? (and ignored for description if placeholder exists due to the fact the text above says it should be ignored if placeholder is non empty)

My perhaps incorrect assumption was either placeholder or aria-placeholder is used in step 3 of the naming algorithm and 2 of the description algorithm (https://w3c.github.io/aria/html-aam/html-aam.html#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-email-input-type-url-and-textarea-element-accessible-name-calculation) depending on which one wins out based on the quoted text above.

[jasonkiss]

@dstorey Good call.

See http://lists.linux-foundation.org/pipermail/accessibility-ia2/2015-April/001877.html for part of the discussion around that text you quote from the HTML-AAM. So placeholder wins out over aria-placeholder when both exist with non-empty values. That seems to be the current state for those, rightly or wrongly.

Also, while I haven't been able to find a definite consensus or decision in the record re order of placeholder vs title in the name computation, I get the impression that the reasons placeholder wins out over title are:

1. authors are currently and regularly using placeholder as a label,
2. placeholder is visible (initially) and title is both neither visible nor available to keyboard-only users or "on hover" on touch devices. See the thread starting with Bryan Garaventa's comment at https://lists.w3.org/Archives/Public/public-pfwg/2015Apr/0071.html

I also get the impression that how placeholder and aria-placeholder are mapped and how they impact the computation of name and description is open to renegotiation.

Admittedly late to this, I know, but I'll note that I haven't been entirely comfortable with the HTML-AAM recommending the use of an attribute as fallback for name or description when other specs and guidance around the use of that same attribute recommends that authors not use it in such a way that it might be a reasonable fallback. A similar question came up around the HTML-AAM providing mappings for deprecated elements and attributes (can't remember which elements or attributes in particular right now). Since the AAMs are normative specs, I feel like they shouldn't be identifying mappings for elements and attributes that are not part of the host language or that are being used in ways that are contrary to best practice as recommended by the host language. It seems to me that simply including placeholder in the name computation validates its usage by authors in providing an accessible name. At what point should an AAM stop documenting the recommended API mappings for popular but ill advised authoring practices?

Does this mean I think that placeholder and aria-placeholder shouldn't be in the name and description computation? I think I'm leaning that way, and that placeholder should be mapped somehow just as placeholder (either via object attributes or a distinct property), leaving it to AT to do something with it. This looks to be have been an earlier suggestion from @klown. That would be more consistent, I think, with all the formal advice around the use of placeholder.

Meanwhile, I do understand the argument for so including it in the computation, given its popular use that way. From that perspective, if we keep with the current, then I'd hope we could at least add some kind of note accompanying that section in the HTML-AAM explaining that, despite its presence in the name computation, placeholder shouldn't be used this way.

[jasonkiss]

This issue was moved to w3c/html-aam#41