Re: Name and Description computation -- Proposed new texts

(see notes inline)

> 2)      I find the non-normative section 5.2 of the HTML-AAM more clear,
> useful and testable than the algorithms. Does anyone remember the reasons
> behind the decision to spec algorithms, rather than inputs and outputs
> (leaving the algorithms for generating the outputs as an implementation
> detail)?
>
I'm sure this is the reason that HTML-AAM has so far used that approach,
giving the specific alternative text attributes/elements for each element.
The difficulty with specifying inputs/outputs is in the recursive
situations, which can't be reduced to a simple list of fallback options.

> 3)      The examples in each step are useful, but it would be even more
> useful to have worked examples with complex markup and resulting
> accessibility trees. In my comment on ARIA step 1, for example, it wasn’t
> clear to me if the name from that example is only at this step, or the
> final result.
>
Agreed.  If anyone has some examples of complex but realistic DOM designs,
I would be happy to help work through the "should" outcome.  As I mentioned
in my note, this would help decide whether the rules are reasonable.


> *In ARIA Name calc*
>
> In the example in step 1, shouldn’t element3’s name be “good-bye” because
> it has aria-label=”good-bye”? From the ARIA 1.0 spec :
> http://www.w3.org/TR/wai-aria/states_and_properties#aria-label
>
> *aria-label** (property)*
>
> Defines a string *value* <http://www.w3.org/TR/wai-aria/terms#def_value>
> that labels the current element.
>
> Is this overcome by step 3? If so, maybe add a note to the example to this
> effect?
>

This is a valid question.  Currently (in both my and the existing text), if
a high priority alternative text attribute is specified, it prevents
lower-priority alternatives from being used, even if it results in an empty
string.  In this case, the aria-labelledby attribute causes aria-label to
be ignored, even though no text can be generated from the labelling element.

To make the algorithm more robust to authoring errors, we could add in a
rule that if the end result of any step is an empty string, then go to the
next step.  However, that could have impacts on the behavior of HTML img
elements, where empty strings are frequently specified intentionally.
E.g., if an author specifies <img alt="" title="decorative fluff" />,
should the tooltip be used as a name?


> In step 4, are you saying that this would not generate a text alternative
> at all? I think that’s a change (We don’t generate one in Edge, and have
> been asked to add a way to support a flat string name)
>
>
>
> <el1 aria-labelledby=”el2”>
>
> <el2 role=”presentation”>foo</el2>
>

Step 4 specifically refers to native labelling elements, not
aria-labelledby.  I'm not sure why the qualification about
role="presentation" was added, but my guess it was to get around authors
using things like table captions or form labels for their secondary effects
(e.g., formatting layout for a table caption, or larger hit targets for a
form label) rather than as a source of descriptive text.



> Step 6, tooltips. UIA (and I think AX) have a helptext field, in addition
> to name and description, that holds tooltip text. Is this something we want
> to consider as part of this algorithm? I am concerned that strings will be
> duplicated between helptext and description sometimes.
>

This is something I've been somewhat uncomfortable with, so I would welcome
discussions of alternative approaches. As a user, I would certainly find it
helpful if tooltips and descriptions were clearly distinguished.  In
addition, I would want a way to discover the tooltip text even if there is
also a detailed description.

Maybe the spec should require user agents to compute tooltips and
descriptions separately, and then in the API mapping there could be a rule
for APIs that don't support a tooltip field, to instead concatenate the
tooltip text onto the end of the description, with some localized text
clearly introducing it as a tooltip/pop-up text.


*In HTML Acc Name doc*
>
[snipping comments I don't have responses to]


> 5.1 This format is MUCH more clear. Thank you!
>
>
>
> Step 2. Do we really want to expose the value of an input as its name?
> We’re already exposing the value as the value.  Is this only to expose the
> value when it is part of a string like <label>Remind me in <input type=text
> value=5 /> minutes</lable>?  I don’t think we want <input value=”One
> Microsoft Way” name=”address” /> to have “One Microsoft Way” as both its
> value and it’s accName.  Is that the intent? If so, is it intended to be a
> repair technique for when authors don’t use labels? It seems like it would
> make a worse experience than not having that string included.
>

Step 2 only applies when the widget is the content of another element's
name.  It is not used for the input's own name.  It is therefore intended
to provide the text that you would normally read from the input if it was
part of a sentence/heading/label.

The example in that section needs work.  As it is, it wouldn't meet
accessibility standards because it doesn't include an accessible name for
the embedded widget itself!

A realistic example would be a calendar item in which the heading contains
a series of editable fields or drop-downs, for event, date, and time, like
 [Appointment with Cynthia] on [Nov 24] at [10:00] .  As the user focuses
on each of those fields in turn, you would use names such as "Event
Description" or "Date" with current value "Appointment with Cynthia" or
"Nov 24". But when using it as the heading for the section, you just want
to read out the current values in a sentence.

Aside: I'm not quite sure why aria-labelledby, unlike aria-label, is given
higher priority than the current value of an embedded widget.  Perhaps
others can chime in? I assume its to support things such as custom sliders
where the author is using JS to update a visible label, but it seems to me
it might create inconsistencies.

Using InnerText of a textarea as a name concerns me. This can be very long.
> While there is no character limit on accName, it becomes a usability
> problem to have a name of more than a few words. If we are going to do
> this, perhaps it should be truncated?
>

This is a general issue whenever labels are generated from contents or
labelledby relationships. Even alt text attributes can be uncomfortably
long for use as accessible name.  Maybe there should be a MAY statement in
section 4.2 that allows user agents to truncate the computed name, so long
as the full text is available on demand somehow?


> Will Step 4 override the values from step 2? 5.2.1 seems to indicate that
> value is not used as part of the name. Is that accurate?
>

Again, step 2 applies when embedding the input inside another element's
label. Section 5.2.1 refers to naming the input itself.


> Is 4D a complete list of labelable html elements? If so, please remove
> e.g..  If not, please make it a complete list and remove e.g.
>

No, it's not a complete list, but could be made so.  The full list from
HTML 5 is:

   - button
   - input (if the type attribute is not in the hidden state)
   - keygen
   - meter
   - output
   - progress
   - select
   - textarea