Re: Finalizing an Issue-204 CP

On Tue, Apr 24, 2012 at 12:40 AM, Cynthia Shelly <cyns@microsoft.com> wrote:
> 1) I prefer should, and the " where such flattened content will provide a good user experience" text, because I think there are times when flattening small amounts of markup in a short label doesn't cause a problem.  However, I can live with must not, and the rest of the stronger language here.  There may be others who object, so I was trying to make it softer.

It's better to drop contentious requirements than paper over
disagreements by watering them down. It's even better to hone the
requirements until they command consensus.

This is why I suggested focusing the conformance requirement on the
generated plain text not the source markup.

For example you could use text like:

"Note hidden labels and descriptions will not be exposed as objects in
the accessibility tree, but may be used as part of accessible name and
description calculation [WAI-ARIA]. Note the calculation will flatten
the labelling and describing elements to plain text strings, losing
interactivity and semantic structure. Authors must only use hidden
labels and descriptions to label and describe elements when the
calculated plain text strings are appropriate accessible names or
descriptions."

For example the following would conform to this particular requirement
because although <label> includes a sub-element, it still flattens to
an appropriate accessible name for the <input>.

   <input id=f type=checkbox checked>
   <label hidden for=f>
     I do <strong>not</strong> want to receive marketing materials.
   </label>

> 2) I also agree that using aria-label is sometime a better technique, but I would like to see the widest range of techniques for providing accessibility text work.  If someone has tried to add accessibility text, I want it in the APIs.

We should encourage people to add accessibility text in ways that make
it robustly available to anyone who needs it. That's only an
intersecting set with the set of people who are using accessibility
API clients.

We often expose accessibility text to the APIs without making it
conforming markup.

Consider <img> with @title but no @alt. ARIA maps this so that @title
provides an accessible name for <img>. But by recent WG decision, it's
also non-conforming because @title has usability problems.

Similarly, hiding labels and descriptions with @hidden has
demonstrable usability problems.

Consider the case of users rejecting author styles in favour of styles
that make content/services more accessible to them. Merely rejecting
author styles will not make @hidden labels and descriptions visible,
but it will make labels and descriptions hidden with CSS visible.

Even if we allow that there are cases where hiding labels didn't have
demonstrable usability problems, we already have a markup feature that
works really well for this purpose: @aria-label. Since it's less
likely to break, we should encourage its use over more brittle
techniques. You say it's "sometime a better technique", but this seems
questionable given nobody's come forward with an example where it
would be better.

As for descriptions, assuming you already have an accessible name,
what sort of additional short description would you not want rendered
*even* when your images are not displayed and your CSS is not applied?

There's a broader problem here where the spec is walking away from
requiring authors to provide names for controls or even providing them
good advice on how to provide such names. The text for @hidden seems
to be the wrong place to fix this though.

Compare: https://www.w3.org/Bugs/Public/show_bug.cgi?id=10710

--
Benjamin Hawkes-Lewis

Received on Tuesday, 24 April 2012 19:01:13 UTC