Closed Bug 1303429 Opened 8 years ago Closed 6 years ago

expose placeholder object attribute for HTML placeholder

Categories

(Core :: Disability Access APIs, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla67
Tracking Status
firefox67 --- fixed

People

(Reporter: surkov, Assigned: MarcoZ)

References

(Blocks 1 open bug)

Details

(Keywords: good-first-bug)

Attachments

(1 file)

here's a link on IA2 thread Jamie's post: https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-September/002165.html fix HTMLTextFieldAccessible::NativeAttributes() to expose placeholder, add a test into test_HTMLSpec.html
Blocks: html5a11y
Related to this: It's been exposed for years on my platform with attribute name "placeholder-text." While I could add checks for attributes named "placeholder," it would be nice if it were exposed consistently. Therefore, could we do a couple of things: 1. Expose it with attribute name "placeholder-text" 2. Expose the aria-placeholder value with attribute name "placeholder-text" (even though that doesn't follow the rule of naming attributes by removing the "aria-") If that's a problem on IA2 (hopefully it's not), would it be possible to just expose it as described for ATK?
(In reply to alexander :surkov from comment #2) > I went on IA2 asking for opinions, see > https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-October/ > 002200.html And Jamie indicated placeholder-text was alright with him: https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2016-October/002201.html And it's in the Core AAM as placeholder-text: https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaPlaceholder So.... Ping?
Related: have filed bugs on chrome and edge to update current implementations What steps will reproduce the problem? (1) open http://s.codepen.io/stevef/debug/jmWrxV/dXMqBbOKgnPr (2) check the accessible name value for the 2 text inputs What is the expected result? the value of the placeholder and aria-placeholder is exposed via the placeholder property (for example in IA2 a placeholder-text object attribute) What happens instead? the value of the placeholder and aria-placeholder is exposed via the acc name property Please use labels and text to provide additional information. mapping for placeholder - https://w3c.github.io/html-aam/#att-placeholder placeholder maps to aria-placeholder defined here: http://w3c.github.io/aria/core-aam/core-aam.html#ariaPlaceholder Note: the current implemented mapping was correct at time, but since then placeholder properties have been added to acc APIs to handle the attribute
Just to make matters more interesting, when there's no label, Chrome exposes placeholder using the "placeholder" attribute, not "placeholder-text" as discussed on the IA2 list (for consistency with ATK). Firefox also uses "placeholder" for aria-placeholder. As a result, in order to support placeholder (since there hasn't been any movement on this), NVDA now supports the "placeholder" attribute, not "placeholder-text". Do other Windows AT support placeholder in Firefox/Chrome? If they do, they too possibly rely on the "placeholder" object attribute. As much as this really sucks, pragmatically, I think IA2 and ATK are going to need to diverge here. The alternative is to update any AT with existing implementations to use the new attribute. We could do this for NVDA, but it'd be good to have an answer on what other Windows AT are using. Dominic, any idea whether other Windows AT are relying on the "placeholder" IA2 object attribute?
Flags: needinfo?(dmazzoni)
Priority: -- → P3
Jamie, so should we use placeholder-text both for IA2 and ATK? and should we keep placeholder for a transition period (not sure how long it can be)?
Flags: needinfo?(jteh)
Given that Chrome (and thus NVDA and probably other AT) have been using "placeholder" in the wild for months (and several releases) now, my vote would be to go for the pragmatic path and use "placeholder" for IA2 and "placeholder-text" for ATK. Divergence isn't ideal, but nor is the tedium of advocating for updates across projects and dealing with backwards compat pain. We should note this divergence in the IA2 attributes spec, though.
Flags: needinfo?(jteh)
I would like to work on this bug. Can I get assigned to it please?
Assignee: nobody → abhishek.1si14cs006
Flags: needinfo?(dmazzoni)

Noted that in Firefox no iA2 placeholder attribute is exposed for elements with a placeholder HTML attribute, but is exposed for aria-placeholder. This means that unless the developer doubles up placeholder and aria-placeholder then the HTML placeholder text is not announced by SR's. Also note it is (HTML placeholder) exposed correctly in chrome and thus works as expected.

test case: https://s.codepen.io/stevef/debug/exjvgW

Suggest this needs fixing pronto :-)

Also note that in chrome's implementation HTML placeholder overrides aria-placeholder value,when both are present, which I think is correct?

Taking this bug.

Joanie, I don't see anywhere in our code where we explicitly mark placeholder-text somewhere. Is there some magic I am missing?

I will be following Chrome's path here:

  1. If both a label and placeholder are used, and they are different from one another, the placeholder attribute will be exposed.
  2. if they are identical, it will not.
  3. Same if no other labeling is present: The placeholder will become the acc name, and no placeholder attribute will be exposed.
Assignee: abhishek.1si14cs006 → mzehe
Status: NEW → ASSIGNED
Flags: needinfo?(jdiggs)

(In reply to Marco Zehe (:MarcoZ) from comment #10)

Joanie, I don't see anywhere in our code where we explicitly mark placeholder-text somewhere. Is there some magic I am missing?

I'm not sure what you're asking, so I'll try to address all possibilities. :)

If you mean the ARIA attribute, anything prefixed with "aria-" (e.g. aria-foo="bar"), Gecko turns that into an object attribute (name: "foo", value: "bar"). It does this unconditionally, but I forget where in the Gecko code this occurs.

"placeholder-text" instead of "placeholder" will of course be a slight twist on things. It's not being done for the ARIA property at the moment -- in Gecko anyway. It would be nice (and compatible with what's in Core-AAM, and consistent with WebKitGtk, and also with Gtk+) to have this special-cased at least on my platform. Then, having done so, please also expose HTML's placeholder attribute in the same fashion.

I hope I addressed your question.

Regarding:

I will be following Chrome's path here:

  1. If both a label and placeholder are used, and they are different from one another, the placeholder attribute will be exposed.
  2. if they are identical, it will not.
  3. Same if no other labeling is present: The placeholder will become the acc name, and no placeholder attribute will be exposed.

If that's what is dictated by AccName + HTML-AAM, great. (I'm still waking up and haven't looked yet. But if it's not, then please do what is dictated by AccName + HTML-AAM.

Steve: Could you please save me the time and tell me if what Marco proposes is what your spec dictates regarding placeholder exposure through a name?

Flags: needinfo?(jdiggs) → needinfo?(faulkner.steve)

If that's what is dictated by AccName + HTML-AAM, great. (I'm still waking up and haven't looked yet. But if it's not, then please do what is dictated by AccName + HTML-AAM.

its not currently, but it was, as it was decided that placeholder would not contribute to accessible name calculation, but at the time some implementers disagreed with removing as would leave some inputs in wild without accessible name. I tend to agree and think we should add back in the HTML-AAM.

Flags: needinfo?(faulkner.steve)

Thanks Steve. I also think we want interoperability between ARIA's placeholder and HTML's placeholder. Therefore, could you please file an issue against the AccName spec so that the ARIA Working Group can discuss this issue?

FWIW, Jamie and I also think that it should be put back in, since it makes sure that more inputs in the wild get a name. FWIW, in Firefox, placeholder is the absolutely last resort for the name calc right now, after really everything else failed.

(In reply to Joanmarie Diggs from comment #11)

"placeholder-text" instead of "placeholder" will of course be a slight twist on things. It's not being done for the ARIA property at the moment -- in Gecko anyway. It would be nice (and compatible with what's in Core-AAM, and consistent with WebKitGtk, and also with Gtk+) to have this special-cased at least on my platform. Then, having done so, please also expose HTML's placeholder attribute in the same fashion.

I just put a hack into the two places where property sets get converted to arrays to rewrite placeholder as placeholder-text for ATK. Thanks for the clarification!

The appropriate case is when placeholder is not used as the absolutely last fallback for the accessible name, and the input is not labeled by the same text as in the placeholder attribute itself. So a label and the placeholder text must be different for the object attribute to be exposed.

In addition, for ATK, placeholder is being renamed to placeholder-text to comply with the platform specification.

Pushed by mzehe@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/fd01e6363762 expose placeholder object attribute for HTML placeholder, r=Jamie
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: