Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No mention of aria-placeholder in name/description calculation algorithm #17

Open
joanmarie opened this Issue May 3, 2018 · 9 comments

Comments

Projects
None yet
6 participants
@joanmarie
Copy link
Contributor

commented May 3, 2018

Moving this over from w3c/aria#337.

Should aria-placeholder be part of the accessible description calculation?

@joanmarie joanmarie added this to the 1.2 milestone May 3, 2018

@scottaohara

This comment has been minimized.

Copy link
Member

commented Feb 14, 2019

Hey @joanmarie

re: the open mozilla ticket expose placeholder object attribute for HTML placeholder, @stevefaulkner noticed we were also missing placeholder in HTML AAM's accName, so we added it.

@joanmarie joanmarie added the agenda label Feb 15, 2019

@joanmarie

This comment has been minimized.

Copy link
Contributor Author

commented Feb 21, 2019

As per today's ARIA WG discussion, I opened an issue against HTML-AAM regarding the ordering/preference of title versus placeholder. Since we want to be in sync with them, we should probably wait until we have consensus on that issue before deciding what we want to do in AccName. w3c/html-aam#168

@jnurthen

This comment has been minimized.

Copy link

commented Feb 26, 2019

From the comments in w3c/html-aam#168 I think it is agreed that placeholder should come after title. @joanmarie should we keep this on the agenda for this week?

@joanmarie

This comment has been minimized.

Copy link
Contributor Author

commented Feb 27, 2019

From the comments in w3c/html-aam#168 I think it is agreed that placeholder should come after title. @joanmarie should we keep this on the agenda for this week?

If we have more to discuss, then yes. If instead the plan is to move forward and bring AccName into alignment with what's in HTML-AAM, then I don't think this needs to be on the agenda -- at least not until we have a pull request for AccName or further questions for which input is required.

@jnurthen

This comment has been minimized.

Copy link

commented Feb 27, 2019

@stes-acc

This comment has been minimized.

Copy link

commented Mar 8, 2019

I still AM a bit confused regarding placeholder as fallback in accessible name / description computation.

UIA-mapping-wise, content is transported using own designated property: https://www.w3.org/TR/core-aam-1.1/:

MSAA/UIA mappings for aria-placeholder : Object Attribute: placeholder-text: / Property: AriaProperties.placeholder:

and https://w3c.github.io/html-aam/ points to the https://www.w3.org/TR/core-aam-1.1/ for mapping of placeholder.

With other words, Jaws, NVDA whatsoever will speak placeholder by default no matter what is in accName/accDescription. At least this default makes sense for me.

Html-aam 5.1.1 maps placeholder as last resort and ARIA-WG decision in 3/7/19 meeting was to follow them here in the ARIA accessible name computation module.

In consequence, if placeholder will be mapped now in accName as last resort for cases like

<input type="text" placeholder="Search"/>

we will have a filled accName: <”Search”> AND a filled Object Attribute: placeholder-text:<”Search”> AND AT must DECIDE to speak ONLY ONCE of them on focus. That’s the caveat. Who is going to tell AT that?

In the last WG meeting minutes, it was said: “if you have a valid name and not description that idea is placeholder goes into the description”

The question is now REALLY and it must be made crystal clear if placeholder is rated as

a) “valid name”
b) “tolerated fallback”

If a), then placeholder string

<label for=”ip1”>Cities</label> <input type="text" id=”ip1” placeholder="Search"/>

Will NOT go into accName but into accDescription.

If b) then placeholder string

<input type="text" placeholder="Search"/>

will go into accName (as discussed above). But what is with accDescription in this case? Read on.

Things get a bit more complicated now if we add a tooltip:

<input type="text" placeholder="Search" title=”Search for cities”/>

According to the logic given above, there must be now a precedence ruling applied for title vs. placeholder which is currently title > placeholder (is that so decided?) yielding accName=”Search” and accDescription=”Search for cities”.

But as a potential side effect of this mapping rule for this, in

<input type="text" placeholder="Search"/>

since title is NOT defined, do we have also an automatic fallback mapping of placeholder being mapped to the accDescription when title is missing in such cases? If so, this leaves us with accName=”Search” AND accDescription=”Search” AND a filled Object Attribute: placeholder-text:<”Search”> which AT needs to fiddle out what to speak now and what not because of redundancy.

I think in consequence when title or aria-describedby is NOT defined for that node, placeholder should not mapped AT ALL to accDescription.

This is what I meant saying we need concrete “what will happen” examples to discuss this.

@accdc

This comment has been minimized.

Copy link

commented Mar 8, 2019

Hi,
I did mention moving this into the Description property conditionally, but with feedback from John and others, the group decision seems to be tilting towards having this be part of Name only, which is how the HTML AAM states this.

If this is the case, then placeholder content would only appear as Name if there were no prior labelling mechanisms detected, such as all those listed prior including the title attribute, otherwise placeholder would not appear in either Name or Description, and assistive technologies would then have to do whatever they wish with that information as they currently do now, because the placeholder content would not appear anywhere within either as part of AccName.

Does this make sense? Is this what people think this should do?

@devarshipant

This comment has been minimized.

Copy link

commented Mar 8, 2019

If this is the case, then placeholder content would only appear as Name if there were no prior labelling mechanisms detected, such as all those listed prior including the title attribute...

HI @accdc -- what are your thoughts on giving precedence to placeholder over title in the naming computation?

Here is the use case with placeholder + title + value on an input control.

  • <input type="text" placeholder="First name" value="Dev" title="only first name">

The result (with Chrome 72 / JAWS 2019) 'First Name Dev only first name' seems okay as placeholder is concise (and hopefully vetted to be meaningful). I think Chrome already computes placeholder (First name) as name and title (only first name) as description in the accessibility tree as shown below.

placeholder-title precedence

However, the proposed HTML AAM gives precedence to title over placeholder in the name computation (see 3 and 4 below):

  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. If the accessible name is still empty, then: use the control's title attribute.
  4. Otherwise use the control's placeholder attribute.
  5. If none of the above yield a usable text string there is no accessible name.
@accdc

This comment has been minimized.

Copy link

commented Mar 8, 2019

We did actually go over that, and the goal of the mappings is part of the role parody project, where it was brought up that these two specs need to be in alignment, so if we did make it so that placeholder whent before title, then the HTML AAM would need to change this to match this instead.

I'm not strongly aligned with either, but I need there to be ARIA WG agreement which one is the best course to follow, and if the latter, then the Web Platforms WG would need to agree as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.