Re: placeholder part of accessible name calculation?

Hi Patrick,

although I appreciate and respect your opinion a lot, I think in this particular case you are wrong.


On 20. Jul 2020, at 10:46, Patrick H. Lauke <redux@splintered.co.uk<mailto:redux@splintered.co.uk>> wrote:

On 20/07/2020 08:20, Marc Haunschild wrote:
Hi,
Maybe I was looking at the wrong places, but I can’t find the answer to my question mentioned in the subject of my mail.
 I’m testing a website with a form that has no label, but placeholder instead.
I know that this does not meet success criterion 1.3.1.

1.3.1 is about making sure info and relationships that are visually apparent are also conveyed in the markup. So if there's no label, there's no relationship that needs to be conveyed...so I don't think this would have any impact on 1.3.1.

I know, so this is SC 1.3.1, not SC 2.5.3.

As Jan already mentioned, relying on placeholder alone does however fail 3.3.2 as when the user starts to enter things into an input, or if there's already a value shown for the input, there is effectively no visible label or instruction.

I’m not sure about that: If a user does not use the keyboard for entering things, but the voice like saying “Write “Marc” into “Name”” it should work. Because the placeholder is visually accessible while giving the command.

As for whether or not placeholder counts as giving an accessible name to an element, I seem to remember that it falls under step D of the accessible name calculation https://www.w3.org/TR/accname-1.1/#mapping_additional_nd_te


"[...] if the current node's native markup provides an attribute (e.g. title) or element (e.g. HTML label) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, unless the element is marked as presentational (role="presentation" or role="none").”


Actually not. I finally found this in the HTML-AAM (with  a little help from Jan):
5.1.1 input type="text", input type="password", input type="search", input type="tel", input type="email", input type="url" and textarea Element Accessible Name Computation<https://www.w3.org/TR/html-aam-1.0/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-email-input-type-url-and-textarea-element-accessible-name-computation>

  1.  If the control has an aria-label<https://www.w3.org/TR/wai-aria-1.1/#aria-label> or an aria-labelledby<https://www.w3.org/TR/wai-aria-1.1/#aria-labelledby> attribute the accessible name<https://www.w3.org/TR/html-aam-1.0/#dfn-accessible-name> is to be calculated using the algorithm defined in Accessible Name and Description: Computation and API Mappings 1.1<https://www.w3.org/TR/accname-aam-1.1/>.
  2.  Otherwise use the associated label element(s) accessible name<https://www.w3.org/TR/html-aam-1.0/#dfn-accessible-name>(s) - if more than one label is associated; concatenate by DOM order, delimited by spaces.
  3.  If the accessible name<https://www.w3.org/TR/html-aam-1.0/#dfn-accessible-name> is still empty, then: use the control's title attribute.
  4.  Otherwise use the control's placeholder attribute.
  5.  If none of the above yield a usable text string there is no accessible name<https://www.w3.org/TR/html-aam-1.0/#dfn-accessible-name>.

So I will have to consider the markup failing SC 1.3.1 and SC 3.3.2 (for keyboard users only), but meeting SC 2.5.3. Also a placeholder is for examples, not for labelling or describing something - I'm aware of these things.

Anyway this is just for giving correct evaluation reports. In real life it does not make a difference. While not meeting two SCs it anyway has to be fixed - and after a fix, the label (or aria-label or aria-labeledby) will be used as accessible name.

Thanks to everyone! - I consider my question as solved. But feel free to tell me, if I'm wrong!

Marc