RE: Issues with HTML5 placeholder and related Accessibility API mappings

Possibly, I’m not sure that would apply in this case though.

I’ve built three test pages to show where the breakdown is, so hopefully this will make it clearer if you can reproduce it.

The first test page uses a similar construct to those I’ve encountered across many travel and local trip planning sites in the past. I’ve simplified it a bit, but it exposes the issue when you have large tables that included embedded date fields and there is a need to give the form fields an explicit label beyond the one that is included as part of the table headers.

1.
http://whatsock.com/test/no_placeholder.html

Validated: http://validator.w3.org/check?uri=http%3A%2F%2Fwhatsock.com%2Ftest%2Fno_placeholder.html&charset=%28detect+automatically%29&doctype=Inline&group=0


Using JAWS in Firefox, you can press Insert+F5 to bring up a list of the field labels visually. This matches the accessible name property in the accessibility tree for each object.

Now, here is the same page, with placeholder added:
2
http://whatsock.com/test/with_placeholder.html

(All else is the same)

Now, if you press Insert+F5 using JAWS in Firefox, every edit field is labeled “mm/dd/yyyy”, because this is now the accessible name property for every form field. Additionally, the title value has been bumped off the list and is no longer in the accessibility tree object for any of these form fields.

Playing devil’s advocate, I modified the placeholder example in the following page to also include an aria-label attribute that duplicates the title, at
3
http://whatsock.com/test/with_placeholder_and_aria-label.html


Now, if you press Insert+F5 in JAWS using Firefox, you will see the correct form field labels, which matches the accessible name property in each form field object, however the placeholder has now been bumped off the list in the accessibility tree, and cannot be found anywhere on the page.

From: Gunderson, Jon R [mailto:jongund@illinois.edu]
Sent: Monday, March 23, 2015 7:11 AM
To: Steve Faulkner; Bryan Garaventa
Cc: PF
Subject: RE: Issues with HTML5 placeholder and related Accessibility API mappings

Bryan,

Maybe evaluation tools should help developer understand the complexities of labeling form controls and can provide feedback to the development team on how there markup is being interpreted to assistive technologies.  If there are certain combinations that should not be used the feedback could be a warning or a violation.

Jon


From: Steve Faulkner [mailto:faulkner.steve@gmail.com]
Sent: Monday, March 23, 2015 5:51 AM
To: Bryan Garaventa
Cc: PF
Subject: Re: Issues with HTML5 placeholder and related Accessibility API mappings

Hi Bryan,

On 22 March 2015 at 17:00, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:
Hi, so just to clarify the problem, there are two primary issues regarding placeholder.

1. The naming calculation sets placeholder as the preferred labelling mechanism over title, which contradicts all historical guidance to use either the label element or title attribute as reliable methods for doing this.

Historical guidance does into take into account new features.
Name calculation also puts aria-label and aria-labelledby before label element and title attribute, which contradicts all historical guidance.
I suggest that when a visible label is not provided using the label element, providing a sometimes visible label (via placeholder) is better than providing a sometimes visible label (for mouse users) via title (never visible on mobile/ touch screens and most desktop browsers for keyboard only users)

I suggest that using placeholder as fallback for an accessible name will bring about a better user experience. I suggest this from looking at how placeholder is being used in the wild.
Here is another 5565 examples of usage of the placeholder attribute (from partial grep of top 87,000 web site home pages: source latest data set 2015-01-08 (780 Mb)<http://files.paciellogroup.com/HTMLData/webdevdata.org-2015-01-07-112944.7z> 87,000 pages.)

LARGE HTML file (6mb)
http://www.html5accessibility.com/HTML5data/top15000-placeholder.html


Don't get me wrong, I consider the added complexity to the name/description calculation to be problematic and one we have to work out in conjunction with browser implementers as the current non interoperable implementation across bowsers helps no one especially users.

2. The accessibility tree property mappings for placeholder don’t make sense, because if you include a valid form field that includes a title, a placeholder, and a referenced tooltip via aria-describedby, it breaks the available properties within the object for conveying all of this information at the same time for AT users. It also doesn’t make sense to put placeholder in the name property, and title in the description property, because it should be the other way around, not counting the addition of an explicit description via aria-describedby.


I think that the idealised best practice and reality of use are colliding here.




From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>]
Sent: Saturday, March 21, 2015 12:21 PM
To: Steve Faulkner
Cc: PF
Subject: RE: Issues with HTML5 placeholder and related Accessibility API mappings

> The placeholder like the title is used as a value when no better value is provided using the recommended methods, the spec does not imply that it an author
> should use it as a label, but does imply that user agents use it as a possible source for a label. The API mapping spec is for UA implementers, not authors.

Granted, that’s why I explained in my original message how this information was represented in the accessibility tree is wrong, which I proved by breaking it when all three attributes are used correctly. (title + placeholder + aria-describedby)

Along with the label element, the title attribute has always been the secondary method for providing the explicit name for a form field:
http://www.w3.org/TR/WCAG20-TECHS/H65.html


Now, the naming calculation says that placeholder should be used as the accessible name before the title attribute when present, meaning that the placeholder is used as the label for that field and not the title.

This is reflected in the accessibility tree, view Object Inspector in Firefox.

If anything, placeholder should be placed after title in that list, not before.

>> As such, it seems logical to me to treat placeholder as a temporary field value in the accessibility tree when there is no actual value present on the
>> edit control, because it's acting as a place holder value, which would have no impact if the form was submitted because it still wouldn't exist in the
>> DOM as the value of that field.

> Disagree, as is regularly the case where the ONLY source of an accessible name for a control is placeholder text, an unfortunate reality.

I’m not talking about the only accessible source, but the case when a field is properly marked up, such as the following:
<input title="Birth date" placeholder="mm/dd/yyyy" aria-describedby="t1id" /> <div id="t1id"> Make sure you only enter a future date </div>

According to the naming calculation, placeholder is used as the label for this field, not the title. (View in Firefox and Chrome to confirm this in the accessibility tree) Additionally, the title cannot be found anywhere because it already has a description.

>> which would have no impact if the form was submitted because it still wouldn't exist in the DOM as the value of that field.
> placeholder never exists in the DOM as the value of the field as far as I know it is always present as the value of the placeholder attribute i the DOM
> (if present).

I know, I’m referring to the accessibility tree mappings for placeholder, not the DOM.

From: Steve Faulkner [mailto:faulkner.steve@gmail.com]
Sent: Saturday, March 21, 2015 4:25 AM
To: Bryan Garaventa
Cc: PF
Subject: Re: Issues with HTML5 placeholder and related Accessibility API mappings


On 19 March 2015 at 19:16, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:
The issue being that many see placeholder as a label substitute, which is an incorrect assumption, even though the spec seems to imply that this is true.

The placeholder like the title is used as a value when no better value is provided using the recommended methods, the spec does not imply that it an author should use it as a label, but does imply that user agents use it as a possible source for a label. The API mapping spec is for UA implementers, not authors.



Technically the concept of placeholder is to provide hint text in the place where the value is to be entered, as a temporary 'place holder' for the value of that field, not as a label for that field.

agreed

When placeholder is used as a label however, it is temporary and disappears when a user interacts with the field, rendering this as useless as a visual label, which presents cognitive accessibility issues for some users, and presents additional issues for non-sighted AT users.

agreed,  and thus the advice present in the HTML5 spec

As such, it seems logical to me to treat placeholder as a temporary field value in the accessibility tree when there is no actual value present on the edit control, because it's acting as a place holder value, which would have no impact if the form was submitted because it still wouldn't exist in the DOM as the value of that field.

Disagree, as is regularly the case where the ONLY source of an accessible name for a control is placeholder text, an unfortunate reality.
which would have no impact if the form was submitted because it still wouldn't exist in the DOM as the value of that field.

placeholder never exists in the DOM as the value of the field as far as I know it is always present as the value of the placeholder attribute i the DOM (if present).

I have grepped some placeholder usage example data from a random selection of 10,000 html files,  note its a big HTML file (3.8 mb)  and the output is crappy HTML.
http://www.html5accessibility.com/HTML5data/placeholder-usage.html




--

Regards

SteveF
HTML 5.1<http://www.w3.org/html/wg/drafts/html/master/>