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
> 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]
> *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
> <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> 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/>
>