Hi James,
On 2015-04-29 7:34 AM, James Teh wrote:
On 29/04/2015 12:08 AM, Joseph Scheuhammer wrote:
a few questions is aria-placeholder ever to be used as fallback for
accname/description calculation?
My position is that, yes, aria-placeholder text can be used as a
fallback for a name, but the decision should be left to the AT. The
placeholder text should be mapped to a "placeholder" property in all
cases, and if the accessible has no "name" property, then the AT can use
other properties as alternatives, including the "placeholder" property.
That way the AT knows that it's using placeholder text for the name.
Pardon my lack of awareness here; I'm coming into this discussion cold
and am not part of the W3C working groups.
I'm late to this party myself. I only started thinking about it as the
PFWG finished up the definition of @aria-placeholder, and started to
work on how to expose it via a11y APIs. I think the general intuition
was: if the author has not provided a name nor a description, and only
placeholder text is available, then the AT hasn't got much to work
with. It could use the placeholder text to provide something beyond
just the role.
Feel free to point me at a thread or something.
Here's the start of one thread:
https://lists.w3.org/Archives/Public/public-pfwg/2015Apr/0032.html
I'm curious as to why placeholder shouldn't be exposed as the
description by UAs. There's certainly an argument for giving the AT as
much choice as possible, but there's also an argument for abstraction.
The placeholder essentially describes what a user might enter into the
field, so it would seem to amp to description quite well where a label
is already present.
I agree to some extent. If used as specified, placeholder text is
closer to a description than it is to a name. But, it is supposed to be
a description of the *format* of the text, thus "MM-DD-YYYY" for a
date. That same placeholder text might re-occur in the multiple date
fields, but each field represents a different date, say arrival date vs.
departure date. The placeholder is not a good description of the
content of the fields.
I don't quite follow why ATs would want to differentiate this in such
a major way as to not have it exposed as the description. To put this
another way, I can possibly understand wanting to have an attribute
like description-from-placeholder:true or something for ATs that
really want this for some reason, but I'd imagine that in the majority
of cases, this wouldn't be used. Am I missing something obvious here?
You propose that placeholder text should be mapped to a description.
Others have suggested it be mapped to a name. That argues that it
should mapped to neither, but always mapped to a placeholder property.
That way the placeholder semantic is not lost, and the AT can present it
as it sees fit. One AT may decide that it should be presented as a
description while another AT might decide to present it as a name.
That's not possible if it is collapsed into the name or description field.
Personally, if I were the end-user, I'd want it presented as
"placeholder: MM-DD-YYYY" or "placeholder: Last name, First name", and
so on, even where the author failed to supply a label and a
description. That way I know what it is and can react accordingly. And,
that's what is communicated to the visual end user by various visual cues.
--
;;;;joseph.
'Array(16).join("wat" - 1) + " Batman!"'
- G. Bernhardt -
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
