Re: Accessible Name Calculation - questions

Sending this to the PF and HTML lists (BCC the "comments" list b/c those aren't intended for discussion)

Responses inline.

> On Aug 18, 2014, at 1:02 PM, Karl Groves <kgroves@paciellogroup.com> wrote:
> 
> Apologies for the cross-post. The following email references the
> following HTML WG document,
> http://rawgit.com/w3c/html-api-map/master/index.html#accessible-name-and-description-calculation
> which, in turn, references http://www.w3.org/TR/wai-aria/roles#namecalculation
> 
> In seeking to provide the best guidance to clients, as well as
> increase the robustness of tenon.io, I'd like to ask for clarification
> on the accessible name calculation rules described in the above
> documents.
> Each question will be delineated with "----------"
> 
> ----------
> Given the following:
> <img src="foo.jpg" alt="" title="WHEE">
> 
> According to the accessible name calculation description, the
> existence of a blank alt should cause title to be ignored. The alt
> exists and its value is empty, indicating that there is no suitable
> alternative. That doesn't seem to be the case in testing, which shows
> the titles being announced by screen readers. Do the rules require
> looking for printable characters when considering a "usable text
> string"?
> 
> (I realize an empty alt with a title is generally a stupid idea but
> I'm more interested in what *should* happen in this case when it comes
> to accessible name calculation)
> ----------
> 
> Section 8.11 of the HTML WG document says:
> 
> 8.11 Text level elements not listed elsewhere
> 
> em, strong, small, s, cite, q, dfn, abbr, time, code, var, samp, kbd,
> sub and sup, i, b, u, mark, ruby, rt, rp, bdi, bdo, br, wbr
> 
> If the element has an aria-label or an aria-labelledby attribute the
> accessible name is to be calculated using the algorithm defined in
> section 5.2.7. Accessible Name Calculation of the WAI-ARIA 1.0
> specification.
> 
> Text level element accessible name calculation
> 
> Use aria-labelledby
> Otherwise use aria-label
> Otherwise use the title attribute
> If none of the above yield a usable text string there is no accessible name

The HTML version of the label computation is wrong in several places. I filed this a while back.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23551
Bug 23551 - name and description section of HTML-AAPI oversimplifies step order; appear to conflict ARIA; needs rewriting

> Why is the element's text node not considered in these cases?

The ARIA spec specifies this. Rule 2C is "Otherwise, if the attributes checked in rules A and B didn't provide results, text is collected from descendant content if the current element's role allows Name From: contents. …"


> ----------
> 
> The following roles are listed in the ARIA spec as getting their names
> from "contents" or "author".
> 
> I'm not sure why "contents" would be used for these because they're
> used for groupings of elements and do not have any contents outside of
> that which exists in their child subnodes.
> 
> row - contents/ author
> rowgroup - contents/ author

That's a fair point. Please file a bug against the ARIA spec component in Bugzilla.


> ----------
> 
> Should CSS-generated content be considered when determining a
> "suitable text string"?

Yes. There is an existing bug for this scheduled for ARIA 1.1.

> ----------
> 
> Given the following, what should the accessible names be for the
> following inputs?
> 
> <label for="two">Whee
>    <input type="text" name="one" id="one" value="one">
> </label>
> 
> <input type="text" name="two" id="two" value="two">

Respectively:

1. I think the explicit @for reference would override the implicit association, and would expect this to be an HTML authoring error. My guess for this is value: "one", label: "" (blank, no label)... In this case, AT are allowed to attempt repair, so depending on the placement of that visible label, VoiceOver and other browsers may still speak "Whee" as the label even though it's not exposed as such in the accessibility API.


2. Should be: value: "two", label: "Whee one"


> Description:
> The label element references input with ID of "two" but the label also
> wraps the input with an ID of "one".  Does it label both inputs? Does
> it label only one? If so, which one?
> 
> 
> 
> Thank you all for your hard work.

Likewise.


> -- 
> Karl Groves
> Senior Technical Lead Accessibility Software Consultant & Director of Training
> The Paciello Group
> @karlgroves
> Phone: +1 443-875-7343
> 

-- 
Indifference towards people and 
the reality in which they live
is actually the one and only 
cardinal sin in design.
                — Dieter Rams

Received on Monday, 18 August 2014 20:24:53 UTC