Join GitHub today
No mention of aria-placeholder in name/description calculation algorithm #17
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
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.
Sounds like a plan. Get Outlook for iOS<https://aka.ms/o0ukef>…
________________________________ From: joanmarie <email@example.com> Sent: Wednesday, February 27, 2019 12:28:02 AM To: w3c/accname Cc: James Nurthen; Comment Subject: Re: [w3c/accname] No mention of aria-placeholder in name/description calculation algorithm (#17) From the comments in w3c/html-aam#168<w3c/html-aam#168> I think it is agreed that placeholder should come after title. @joanmarie<https://github.com/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. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#17 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABpQP2fOarzYszq2w42NoSbBU2PimPvfks5vRkGSgaJpZM4Tx1BU>.
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:
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
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”
If a), then placeholder string
Will NOT go into accName but into accDescription.
If b) then placeholder string
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:
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
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.
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?
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.
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.
However, the proposed HTML AAM gives precedence to title over placeholder in the name computation (see 3 and 4 below):
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.