-
-
Notifications
You must be signed in to change notification settings - Fork 637
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
Comments
Once the user types, the placeholder text should disappear, yes.
…On Wed, Mar 22, 2017 at 10:32 PM, Reef Turner ***@***.***> wrote:
Add support for aria-placholder
<https://rawgit.com/w3c/aria/master/aria/aria.html#aria-placeholder>.
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?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#7004>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFGivb575T3fEh9GGuCUHvRY1N56QHiWks5rofXxgaJpZM4MmL59>
.
--
Derek Riemer: Improving the world one byte at a time!
- University of Colorado Boulder Department of computer science, 4th
year undergraduate student.
- Accessibility enthusiast.
- Proud user of the NVDA screen reader.
- Open source enthusiast.
- Skier.
Personal website <http://derekriemer.com>
|
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. |
From the Aria spec:
To my interpretation, this specifies that it is the authors responsibility to add / remove the attribute based on the presence of a value. |
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. |
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:
Tested by tabing to the control in different modes.
|
I raised an issue to clarify the spec: w3c/aria#541 |
Fixes #7004 Handles values with backslash escaped semicolons and backslash escaped backslashes.
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)
This was implemented in PR #7055 |
Add support for aria-placholder.
Example test cases
(inspired by / taken from aria spec), paste the following into a browser address bar:
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?
The text was updated successfully, but these errors were encountered: