RE: [REVIEW REQUESTED][ARIA] placeholder

That can be adjusted.


Rich Schwerdtfeger



From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: Joseph Scheuhammer <clown@alum.mit.edu>, Steve Faulkner
            <faulkner.steve@gmail.com>, Joanmarie Diggs
            <jdiggs@igalia.com>, Matthew King/Fishkill/IBM@IBMUS, W3C WAI
            Protocols & Formats <public-pfwg@w3.org>, Alexander Surkov
            <surkov.alexander@gmail.com>
Date: 04/07/2015 12:59 PM
Subject: RE: [REVIEW REQUESTED][ARIA] placeholder



I understand, thanks.

What I’m trying to point out though, is that having it there within the
naming calculation is an all or nothing result as it is currently
implemented within the accessibility tree on Windows, which you can see by
running the following code in Firefox and checking the accessibility tree
object for each form field.

<div role="heading" aria-level="1" id="sharedGroupLbl"> Travelling </div>

<form>

<label for="dept1"> Departure </label>
<input id="dept1" placeholder="mm/dd/yyyy" title="Set the date you plan to
leave" aria-describedby="sharedGroupLbl" />

<label for="ret1"> Return </label>
<input id="ret1" placeholder="mm/dd/yyyy" title="Set the date you plan to
return" aria-describedby="sharedGroupLbl" />

</form>

E.G For field 1
Name: Departure
Description: Travelling
Value: ""
All other information is lost, including both title and placeholder.

I think Joseph's proposal to put placeholder within its own property
instead of using Name or Description would solve this by letting the AT
handle how it is represented, so it could still be handled correctly on
mobile devices that don't render titles.

There is also an issue when title and aria-describedby overwrite each other
as well.



From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Tuesday, April 07, 2015 8:30 AM
To: Bryan Garaventa
Cc: Joseph Scheuhammer; Steve Faulkner; Joanmarie Diggs; Matthew King; W3C
WAI Protocols & Formats; Alexander Surkov
Subject: RE: [REVIEW REQUESTED][ARIA] placeholder

Hi Brian,

On mobile devices title is not rendered to sited users when you hover over
it. At least placeholder is visible until you type over it.

My thoughts are that placeholder should be in the name calculation to deal
with situations where the author left the label out so that the user is not
left with nothing. Accessibility compliance rules shoul enforce actual
labeling <label for>, aria-labelledby, etc.

You don't want be in a situation where you pick up a mobile app or go to a
kiosk to buy a ticket and the author forgot to test for accessibility and
be left with nothing as there is nobody for us to scream at about it not
being accessible. It is fallback. :-)

Rich

Rich Schwerdtfeger

Bryan Garaventa ---04/06/2015 12:31:49 PM---> It is not being called an
acceptable alternative, it is being and has already been implemented as

From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
To: Steve Faulkner <faulkner.steve@gmail.com>, Matthew
King/Fishkill/IBM@IBMUS
Cc: Joseph Scheuhammer <clown@alum.mit.edu>, Joanmarie Diggs
<jdiggs@igalia.com>, W3C WAI Protocols & Formats <public-pfwg@w3.org>,
Alexander Surkov <surkov.alexander@gmail.com>
Date: 04/06/2015 12:31 PM
Subject: RE: [REVIEW REQUESTED][ARIA] placeholder
________________________________________



> It is not being called an acceptable alternative, it is being and has
already been implemented as  a fallback source when other sources are not
available.

I still don’t understand why it makes sense for placeholder to have greater
priority in the naming calculation than title, because if you have a form
field that has both a placeholder and a title on it, the browser now
automatically chooses placeholder as the accessible name.

Also, the fact that placeholder is in the naming calculation at all,
implies to any developer reading it that placeholder is an “acceptable
alternative” with greater priority than title, which does pass all HTML
validators.

From: Steve Faulkner [mailto:faulkner.steve@gmail.com]
Sent: Monday, April 06, 2015 3:14 AM
To: Matthew King
Cc: Bryan Garaventa; Joseph Scheuhammer; Joanmarie Diggs; W3C WAI Protocols
& Formats; Alexander Surkov
Subject: Re: [REVIEW REQUESTED][ARIA] placeholder

Hi Matt,
On 5 April 2015 at 19:37, Matthew King <mattking@us.ibm.com> wrote:
On 4 April 2015 at 20:07, Bryan Garaventa
<bryan.garaventa@ssbbartgroup.com wrote:
> If it were possible to show that 5560 examples across the web used
> the following syntax:
>
> <div role=”checkbox” aria-selected=”true”></div>
>
> Would we have to say in the spec that this is a valid use of the
> checkbox role and it’s supporting state by getting browsers to map
> aria-selected to checkbox?
>
Steve Faulkner <faulkner.steve@gmail.com> wrote on 04/05/2015 01:17:57 AM:
> Hi Bryan, the analogy does not make sense. The examples provided are
> a random sample of usage from approx 80,000 web sites.

Steve, If a random sample demonstrated high frequency usage of selected in
the way Bryan described, how does the analogy fail?

Because what bryan describes simple does not work for anyone currently,
what I am describing works for the majority of users now and is a common
practice now. I am not saying we should advise authors that it is
conforming to use the placeholder as a label, in fact I advised the
opposite in the HTML5 spec [
http://www.w3.org/TR/html5/forms.html#the-placeholder-attribute].

The accessible name calculation for many elements has, as implemented,
included non conforming sources, inclusion in the accessible name
calculation rules for UA implementations does not mean that it is
conforming for authors, it means that in the absence of conforming sources,
sources which are known to include useful information should be included.



If a random sample demonstrated that the <p> element or <<span> elements
immediately preceding an input very frequently contained a valid label if
if another labeling technique was not used, does that mean we should make
those elements part of the accessible name calculation?

This what some AT already do, but I don't consider it a practice that
browsers should or need to implement.


Steve continues:
> What I am trying to illustrate is that how placeholder content is used in

> accessible name calculation needs to take into account how
> placeholder is used in web sites, in the wild, not how we wish it
> would be used.

I am questioning whether placeholder should be allowed to be a part of the
name calculation. Yes, it may sometimes have a useful value. But, I am not
convinced that calling it an acceptable alternative to the long list of
options we already have available to authors is a good idea. Other random
samples could demonstrate how using placeholder as a label would be
extremely confusing to AT users.

It is not being called an acceptable alternative, it is being and has
already been implemented as  a fallback source when other sources are not
available.


Another equally valid position could be .... Authors have had enough
warning and guidance against this practice so too bad for the 5,560 in your
random sample. Kill the pernitious practice before the random sample of 80k
turns of 60k such pages. Make all conformance checkers fail them.

There is nothing to say that accessibility checkers should not fail the use
of placeholder in this context. HTML conformance checkers are another
issue.


Another possibility is to force user agents to fix the accessibility
problems with placeholder presentation so that they really could be a fully
accessible alternative.

Suggest asking the implementers on list how that is to be accomplished.
Getting implementers to change the behaviour of mainstream UI for
accessibility purposes is not easy.



Another possibility is for new options in HTML or CSS that make it super
easy for authors to use the label element in a way that is both completely
accessible and mobile friendly so that the desire to co-opt placeholder for
this purpose evaporates.

Suggest asking the implementers on list how that is to be accomplished and
providing concrete proposals on how to make that happen.



To some, it may feel the placeholder as alternative label train has left
the station. But, before jumping on board, I am curious to know if we are
evaluating the potential efficacy of other viable paths.

Suggest getting feedback from implementers.

--

Regards

SteveF
HTML 5.1