Tracker for placeholder accessibility

RESOLVED FIXED

Status

()

RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: MarcoZ, Assigned: davidb)

Tracking

(Blocks: 1 bug, {meta})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

This is spun off bug 457800.

From the spec:
"The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry. A hint could be a sample value or a brief description of the expected format."

To me, this sounds like a classic example of being exposed as an accessible description. The specification also says that the placeholder attribute should not be used as a replacement for a label. So it would be inappropriate to turn the placeholder attribute's value into the accessible name. This is in contrast to what we do for XUL:textbox and the emptyText property, where it *is* meant as a replacement for a label.

The spec also says: "For a longer hint or other advisory text, the title attribute is more appropriate." So what should we do if both placeholder and title attributes are present? The spec doesn't say that these are mutually exclusive, so it *is* possible the title attribute can also be specified. My gutt feeling is to say "concatenate" in accessible description.

Any thoughts?
This might depend on how the placeholder is used. If the placeholder is targeted to be a label of the text field, for example, if placeholder is "zip code" for the text field intended to enter zip code then we could append it to the end of the accessible name. If the placeholder is used to give a hint what and why should be entered, for example, "enter zip code to search" then we could append it to description. I do not concern to implementation details, it might be trick, but at the first glance it sounds reasonable.
Summary: Impleement accessibility solution to support the placeholder attribute → Implement accessibility solution to support the placeholder attribute
Yeah concat/append sounds the safest to me.
Marco suggested over IRC that we might want to extend the AccessibleValue interface. This sounds like the 'right fix' to me. (cc'ing Pete)
I also sent Pete e-mail on this explaining briefly some background.

Comment 5

9 years ago
I don't think IAValue is the right approach.  It's meant for things like sliders.  The HTML5 spec at http://dev.w3.org/html5/spec/Overview.html#the-placeholder-attribute says, "For a longer hint or other advisory text, the title  attribute is more appropriate."  That seems to be saying use placeholder or title, depending on whether the hint is short or long.  And I assume that the expression of title in a visual GUI is hover text and the expression of placeholder is perhaps grayed out text in the box until it gets focus.  If title and placeholder are mutually exclusive then for accessibility you could use the same means to expose placeholder as is used for title.  How is title exposed today?  Via accessible description?  If so then you could expose placeholder via accessible description.  The referenced spec doesn't say anything about the case of using both title and placeholder but I assume it's legal to use both.  It both title and placeholder are specified it seems acceptable to ignore the placeholder text since both should contain the same information but with the placeholder being abbreviated and the title being more complete.  Are there cases where title would not provide information that placeholder does?  Would that be considered bad form?
Blocks: 457800
No longer depends on: 457800
Jamie, text fields can have placeholder text that often visually appears as the italicized, or otherwise styled text inside the field. Users have learned that clicking the field removes the text. In terms of offering this placeholder text to your users, how would you expect us to serve it via API?

I'm leaning towards making it part of the description, or an object attribute.
I too think it should be exposed in the description. This seems logical to me and not a hacky solution. Something to consider, though: should it be exposed as the name if the name is otherwise unspecified?
Blocks: 389237
No longer blocks: 457800
Depends on: 457800

Comment 8

9 years ago
(In reply to comment #7)
> Something to consider, though: should it be exposed
> as the name if the name is otherwise unspecified?

I think, it should be exposed as the name, if name isn't specified otherwise. This feature will be extremly often used as a label-replacement. Beside the fact, that the text of the spec should be changed, to better reflect the practical usecase of this feature, the placeholder-hint will have the most important meaning, if no other name-text is computable.
Assignee: nobody → bolterbugz
Posted patch WIP (obsolete) — Splinter Review
Comment on attachment 481004 [details] [diff] [review]
WIP

I'd like to see a regular label for construct in the tests, too, where we make sure the label wins over the placeholder text.
Posted patch patchSplinter Review
Attachment #481004 - Attachment is obsolete: true
Attachment #482917 - Flags: review?(surkov.alexander)
Note for consistency I set the last placeholder in the tests to "meh" locally.
(In reply to comment #11)
> Created attachment 482917 [details] [diff] [review]
> patch

Can you describe an affect of the patch? Placeholder isn't exposed as a part of anonymous content of HTML input any more?
(In reply to comment #13)
> (In reply to comment #11)
> > Created attachment 482917 [details] [diff] [review] [details]
> > patch
> 
> Can you describe an affect of the patch?

Without the code change the first three tests fail (confirmed just now). So, in cases where there is no name for a text field we will use the placeholder text if it exists.

> Placeholder isn't exposed as a part of
> anonymous content of HTML input any more?

I don't know.
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #11)
> > > Created attachment 482917 [details] [diff] [review] [details] [details]
> > > patch
> > 
> > Can you describe an affect of the patch?
> 
> Without the code change the first three tests fail (confirmed just now). So, in
> cases where there is no name for a text field we will use the placeholder text
> if it exists.

Honestly I didnt' grab any idea how we should expose placeholder. Looking at your patch it makes me feel you're going to expose it as accessible name. But you didn't give any comment for the patch. Searching through bug history I can see several different suggestions and I don't have any clue why did you choose this appproach (though I don't feel it's wrong). Just please give me some background.

> > Placeholder isn't exposed as a part of
> > anonymous content of HTML input any more?
> 
> I don't know.

It is, otherwise your latest test will fail. Btw, if we're going to expose placeholder as a name and treat as label replacement then we should not create  accessibles for it. What do you think?
Actually the last test is only checking for the label, not the placeholder.

Note we don't expose the placeholder at all before this patch. The idea of this patch is to implement the placeholder as the name when we can't otherwise find a name. I think I agree with comment 8 essentially.

We could additionally expose the placeholder as description iff it wasn't used as the name, but I don't see a nice way to implement that. So I think this patch is one everyone can agree with, and this latter problem can be resolved separately.
Ok, so this bug sounds a bit wider than @placeholder exposing in accessible name because we should have common solution for HTML and XUL and we should take care about accessible children of entries created for placeholder (because text interface be broken in some way). Perhaps we could call this bug fixed by your patch but we need new one to take care about follows. Or we could turn this one into meta and file new bug fro you patch.
Filed bug 604386 for placeholder-as-child-in-a11y-tree interference.
Depends on: 604386
Keywords: meta
Summary: Implement accessibility solution to support the placeholder attribute → Tracker for placeholder accessibility
Comment on attachment 482917 [details] [diff] [review]
patch


>   nsresult rv = nsAccessible::GetNameInternal(aName);
>   NS_ENSURE_SUCCESS(rv, rv);
> 
>   if (!aName.IsEmpty())
>     return NS_OK;
> 
>+  // text inputs and textareas might have useful placeholder text
>+  mContent->GetAttr(kNameSpaceID_None, nsAccessibilityAtoms::placeholder, aName);
>+

it sounds we should have name empty check here as well. If we prefer aria and label names then we should  do the same for placeholder stuffs. Do you agree?

if we have tests for thsi then we should add test for placehodler, though I doubt we have them.

r=me with fixed/addressed
Attachment #482917 - Flags: review?(surkov.alexander) → review+
(In reply to comment #19)

> it sounds we should have name empty check here as well. If we prefer aria and
> label names then we should  do the same for placeholder stuffs. Do you agree?
> 
> if we have tests for thsi then we should add test for placehodler, though I
> doubt we have them.
> 
> r=me with fixed/addressed

The patch tests this :)

testName("ph_text2", "a label");
<input id="ph_text2" type="text" aria-label="a label" placeholder="meh" />

Explanation:
nsAccessible::GetName() calls GetARIAName first and if it succeeds we return. So ARIA still gets dibs.

I will add an early return if placeholder succeeds in a name though. I'll post the updated patch on the correct bug now that this is meta... to avoid noise here.
I think we're done here.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
(In reply to comment #16)
> We could additionally expose the placeholder as description iff it wasn't
> used as the name, but I don't see a nice way to implement that. ... this... problem can be
> resolved separately.
Was a bug ever filed for this? It is necessary for the placeholder example here, where the field has a label as well as a placeholder:
http://www.html5accessibility.com/tests/form-test.html
Is there a valid use case for this in the wild?
Related NVDA ticket: http://www.nvda-project.org/ticket/1638
bug filed 670083, thank you, Jamie.
You need to log in before you can comment on or make changes to this bug.