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

Add support for Aria-placeholder #7004

Closed
feerrenrut opened this Issue Mar 23, 2017 · 7 comments

Comments

Projects
None yet
4 participants
@feerrenrut
Contributor

feerrenrut commented Mar 23, 2017

Add support for aria-placholder.

Example test cases

(inspired by / taken from aria spec), paste the following into a browser address bar:

data:text/html,<html> <head> <title>Test aria-placeholder</title> </head> <body> <span id="label1">Birthday text entry with text already entered:</span> <div contenteditable role="searchbox" aria-labelledby="label1" aria-placeholder="MM-DD-YYYY">03-14-1879</div> <span id="label2">Birthday text entry with text matching the placeholder:</span> <div contenteditable role="searchbox" aria-labelledby="label2" aria-placeholder="MM-DD-YYYY">MM-DD-YYYY</div> <span id="label3">Birthday text entry with no text entered:</span> <div contenteditable role="searchbox" aria-labelledby="label3" aria-placeholder="MM-DD-YYYY"></div> <span id="label4">Ensure that semi-colons and backslashes in the placeholder attribute are handled</span> <div contenteditable role="searchbox" aria-labelledby="label4" aria-placeholder="some;semi-colon;here\and here \;also"></div> </body> </html>

Expected UX:

Only in focus mode, since placeholder only needs to be reported when users will be entering form data.
Should be reported when using quicknav like 'e' + 'shift+e'

The spec indicates that the "author" should present the placeholder hint when the value for the field is empty, and not when it has been filled. Is this something that NVDA should enforce?

@feerrenrut feerrenrut self-assigned this Mar 23, 2017

@derekriemer

This comment has been minimized.

Show comment
Hide comment
@derekriemer

derekriemer Mar 23, 2017

Collaborator
Collaborator

derekriemer commented Mar 23, 2017

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Mar 24, 2017

Contributor

I think we should only report placeholder when there is no value. That's going to be a bit tricky, since the "value" property is not actually what we use for the content of an editable text field; we use the text from the TextInfo.

Because placeholder is more like content than it is name or description, I think we probably should report this in browse mode (but again only if the content is empty).

Because we're only reporting placeholder in the absence of content, I don't think we need the "Placeholder:" prefix you mentioned.

In my digging on this topic, I discovered that IA2 apparently agreed to rename the placeholder attribute to placeholder-text for compatibility reasons. See this IA2 thread and this Mozilla bug. It doesn't seem Firefox has made this change yet and Chrome seem to have gone with "placeholder". I'm not sure if the core ARIA mappings have been updated yet either. We might need to support both in the short term.

Contributor

jcsteh commented Mar 24, 2017

I think we should only report placeholder when there is no value. That's going to be a bit tricky, since the "value" property is not actually what we use for the content of an editable text field; we use the text from the TextInfo.

Because placeholder is more like content than it is name or description, I think we probably should report this in browse mode (but again only if the content is empty).

Because we're only reporting placeholder in the absence of content, I don't think we need the "Placeholder:" prefix you mentioned.

In my digging on this topic, I discovered that IA2 apparently agreed to rename the placeholder attribute to placeholder-text for compatibility reasons. See this IA2 thread and this Mozilla bug. It doesn't seem Firefox has made this change yet and Chrome seem to have gone with "placeholder". I'm not sure if the core ARIA mappings have been updated yet either. We might need to support both in the short term.

@feerrenrut

This comment has been minimized.

Show comment
Hide comment
@feerrenrut

feerrenrut Mar 24, 2017

Contributor

From the Aria spec:

Authors should present this hint to the user by displaying the hint text at any time the control's value is the empty string. This includes cases where the control first receives focus, and when users remove a previously-entered value.

To my interpretation, this specifies that it is the authors responsibility to add / remove the attribute based on the presence of a value.

Contributor

feerrenrut commented Mar 24, 2017

From the Aria spec:

Authors should present this hint to the user by displaying the hint text at any time the control's value is the empty string. This includes cases where the control first receives focus, and when users remove a previously-entered value.

To my interpretation, this specifies that it is the authors responsibility to add / remove the attribute based on the presence of a value.

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Mar 26, 2017

Contributor

I agree it's not clearly written, but I don't think that interpretation was intended. I think what they're actually talking about is the literal "display" of placeholder text. That is, if you're an author and you're going to implement placeholder text yourself (and make it accessible using aria-placeholder, as opposed to just using the HTML 5 placeholder attribute which does everything for you), you must only display the placeholder visually when the field has no content. Otherwise, it's not a valid use of aria-placeholder. That's also a hint to AT as to a reasonable UX for placeholder.

Still, since there's reasonable doubt, we should perhaps seek clarification from the spec group. I'm actually not sure how to go about doing that the official way.

Contributor

jcsteh commented Mar 26, 2017

I agree it's not clearly written, but I don't think that interpretation was intended. I think what they're actually talking about is the literal "display" of placeholder text. That is, if you're an author and you're going to implement placeholder text yourself (and make it accessible using aria-placeholder, as opposed to just using the HTML 5 placeholder attribute which does everything for you), you must only display the placeholder visually when the field has no content. Otherwise, it's not a valid use of aria-placeholder. That's also a hint to AT as to a reasonable UX for placeholder.

Still, since there's reasonable doubt, we should perhaps seek clarification from the spec group. I'm actually not sure how to go about doing that the official way.

@feerrenrut

This comment has been minimized.

Show comment
Hide comment
@feerrenrut

feerrenrut Mar 27, 2017

Contributor

It seems relevant to consider how the related html5 placeholder attribute is reported in various browsers with nvda. The placeholder attribute is discussed and examples given here.

With test address:

data:text/html,<label>Address: <input type="email" name="address"placeholder="john@example.net"></label>

Tested by tabing to the control in different modes.
Using NVDA version next-13911,3c8e30bd

  • NVDA in focus mode used with Firefox reports the placeholder text even when there is a user value entered. In browse mode there is no placeholder reported.
  • When using Edge the placeholder value is reported in both browse mode and focus mode. Unless there is a user value then the the placeholder value is not reported.
  • When using Chrome canary or IE the placeholder value is not reported.
  • Visually the placeholder text is only shown until a user value is entered (for all browsers)
Contributor

feerrenrut commented Mar 27, 2017

It seems relevant to consider how the related html5 placeholder attribute is reported in various browsers with nvda. The placeholder attribute is discussed and examples given here.

With test address:

data:text/html,<label>Address: <input type="email" name="address"placeholder="john@example.net"></label>

Tested by tabing to the control in different modes.
Using NVDA version next-13911,3c8e30bd

  • NVDA in focus mode used with Firefox reports the placeholder text even when there is a user value entered. In browse mode there is no placeholder reported.
  • When using Edge the placeholder value is reported in both browse mode and focus mode. Unless there is a user value then the the placeholder value is not reported.
  • When using Chrome canary or IE the placeholder value is not reported.
  • Visually the placeholder text is only shown until a user value is entered (for all browsers)
@feerrenrut

This comment has been minimized.

Show comment
Hide comment
@feerrenrut

feerrenrut Mar 28, 2017

Contributor

I raised an issue to clarify the spec: w3c/aria#541

Contributor

feerrenrut commented Mar 28, 2017

I raised an issue to clarify the spec: w3c/aria#541

feerrenrut added a commit that referenced this issue Apr 6, 2017

Add support for aria-placeholder
Fixes #7004

Handles values with backslash escaped semicolons and backslash escaped
backslashes.

@nvaccessAuto nvaccessAuto added this to the 2017.3 milestone Jun 21, 2017

feerrenrut added a commit that referenced this issue Jun 21, 2017

Update changes file
For PRs:
- #6864 - NVDA user configuration files can now be stored in the user's local application data folder. This is enabled via a setting in the registry. See 'System wide parameters' in the user guide for more details. (Issue #6812)
- #7055 - In web browsers, NVDA now reports placeholder values for fields (specifically, aria-placeholder is now supported). (Issue #7004)
@feerrenrut

This comment has been minimized.

Show comment
Hide comment
@feerrenrut

feerrenrut Dec 21, 2017

Contributor

This was implemented in PR #7055

Contributor

feerrenrut commented Dec 21, 2017

This was implemented in PR #7055

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment