Re: Finalizing an Issue-204 CP

On Sat, Apr 21, 2012 at 6:07 AM, John Foliot <john@foliot.ca> wrote:
> Benjamin Hawkes-Lewis wrote:
> > For example, it would be incorrect to use the href attribute to link
> to a section marked with the hidden attribute. Since the content is not
> rendered, linking to it</del> would have unpredictable
> behavior</del><ins>would result in behavior the user does not
> expect</ins> , either dropping the user at a location with no rendered
> content, or failing to navigate.
>
>> This still introduces a self-contradiction into the specifications,
>> since the behavior is defined to navigate the user to a location with
>> rendered content. There's no "or" and both your alternatives are
>> wrong.
>
> "Defined" where? Ben can you supply relevant references when you make these statements please. For ease of comprehension, direct quotes are also appreciated, with the reference URL then provided. Don't make us go hunting to find where you are reading (or misreading) these assertions.

I did provide these links to the relevant specifications in this thread:

  http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid

  http://dev.w3.org/csswg/cssom-view/#element-scrolling-members

Consider the markup:

   <div id="hidden-fragment" hidden>I am hidden.</div>

… then a few screens down in the same document …

   <a href="#hidden-fragment">Link</a>

A user clicks on the link. What happens?

The UA must follow the hyperlink:

   http://dev.w3.org/html5/spec/the-a-element.html#the-a-element

To follow the hyperlink, the UA must resolve the URL (successfully)
then navigate to the URL:

   http://dev.w3.org/html5/spec/links.html#following-hyperlinks

Since the URL is just a fragment identifier relative to the current
address, the UA must navigate to the fragment identifier:

    http://dev.w3.org/html5/spec/history.html#navigate

To navigate to the fragment identifier, the UA must add the new URL to
navigation history then scroll to the fragment identifier:

    http://dev.w3.org/html5/spec/history.html#scroll-to-fragid

"When the user agent is required to scroll to the fragment identifier,
it must either change the scrolling position of the document using the
scroll an element into view algorithm defined in the CSSOM View
specification, with the align to top flag set, or perform some other
action, such that the indicated part of the document is brought to the
user's attention. If there is no indicated part, or if the indicated
part is not being rendered, then the user agent must not scroll
anywhere."

In the case of a @hidden fragment, the "indicated part is not being
rendered", so the UA does not scroll or otherwise bring the indicated
fragment to the user's attention.

The proposed text is wrong, because what happens is fully defined:
navigation occurs, the address changes, but the UA does not bring the
indicated fragment to the user's attention because it is not rendered,
so the point of regard remains at the same rendered content as before.

Have I missed something here?

>> > <p class="note">Any structure in the referenced element, including
>> headings, links, tables, paragraphs, and form elements, will be lost.
>> The text children of the element will be flattened to a string. As such,
>> authors should only use this technique <del>for string content</del>
>> </ins>where such flattened content will provide a good user
>> experience</ins>. At the time of this writing, some screen reader
>> products will read both the accessible name and accessible description,
>> so authors should take care with the length of text provided via this
>> method.</p>
>>
>> Where's the rationale for introducing such text under @hidden rather
>> than in the ARIA specification or the WAI-ARIA section of the HTML5
>> spec?
>
> One rationale is that it is common practice throughout the HTML5 draft spec to provide warnings, advisories or "Notes" - in line - that provides relevant and pertinent advice to content creators (who may or may not go look in other documents).

My point is that this note (at least as written) is not especially
pertinent to @hidden.

ARIA currently says (normatively): "The element or elements referenced
by the aria-describedby comprise the entire description."

   http://www.w3.org/WAI/PF/aria/complete#aria-describedby

(ARIA both normatively suggests referenced elements *are* the
description and informatively suggests authors use @aria-describedby
to reference a hyperlink to a description, which is a
self-contradiction.)

It also says (normatively) UAs expose "Long description" as the
"accessible description" for the chart:

   http://www.w3.org/WAI/PF/aria/complete#textalternativecomputation

It also describes (informatively) how UAs should expose the accessible
description in some accessibility APIs as a plain text property and
how they should expose pointers between the accessibility tree objects
representing the describing elements in a APIs that support such
pointers:

   http://www.w3.org/WAI.new/PF/aria-implementation/#mapping_state-property_table

ARIA doesn't currently include a way to establish pointers to
descriptions without a plain text accessible description.

Consider the following markup:

  <img alt="October Sales chart" aria-describedby="#description-link">
  <a id="#description" href="october-sales.html">Details</a>

"Details" is a passable accessible name for the link but it is not a
good accessible description for the image.

So what can we do?

One option is to change user agent requirements. For example, we could
map this so that when @aria-describedby points to elements with
sub-elements or interactive content, user agents do not expose an
accessible description but only expose a pointer to the accesssible
element and/or (for APIs that don't support pointers) an accessible
action to bring the description into focus.

Another option is to add author conformance requirements or guidance.
Saying "authors should only use this technique where such flattened
content will provide a good user experience" constitutes such
guidance, but it is not limited to @hidden.

It is undeniable that this markup is even more problematic:

  <img alt="October Sales chart" aria-describedby="#description">
  <a hidden id="#description" href="october-sales.html">Details</a>

But it is more problematic *not* because the accessible description is
flattened to "Details" (that happens regardless of @hidden) but
because user agents will not to expose a pointer to the link because
it is not in the accessible object hierarchy.

The proposed text fails to express this.

Now we could provide text expressing this, but is that useful? Don't
we want to be providing guidance/requirements to inhibit authors
creating harmful markup like the first example, rather than an even
more harmful subset of such markup? And doesn't that generic guidance
belong either in the WAI-ARIA section or in WAI-ARIA itself (even if
we repeat it in the HTML spec)?

>> Saying "The text children of the element will be flattened to a
>> string" is a direct contradiction of the ARIA specification which
>> takes account of various elements and attributes in the calculation of
>> the accessible name and description.
>
> Again Ben, can you please supply relevant references when you make these statements.

Sure.

"Text children of the element" means text child nodes (attributes are
not "children", child elements are not "text children"). But the
algorithm in the ARIA specification recurses over descendant element
nodes, attribute nodes, and text nodes.

  http://www.w3.org/WAI/PF/aria/roles#namecalculation

Consider this markup:

  <div id="label">bar <span> foo </span> <img alt="baz"
src="kitten.jpg"> quux</div>

The CP spec text implies that the accessible name calculated from the
<div> is "bar quux".

The ARIA spec text implies that the accessible name calculated from
the <div> is "bar foo baz quux".

I don't have a strong feeling about including guidance for authors
"who may or may not go look in other documents". But the inclusion of
guidance that misrepresents the technical references it purports to
summarize through vague language (as opposed to explicit wilful
violation) is counter-productive. Spec writers can avoid the cost of
formulating and maintaining appropriate language by keeping
duplication of material in "other documents" to a minimum. For
example, we could say something like "accessible name and description
calculation [WAI-ARIA] will flatten the referenced elements to plain
text, losing interactivity and semantic structure".

>> Markup is a "string" so "string" is the wrong word to use here:
>>
>> http://en.wikipedia.org/wiki/String_(computer_science)
>
> While this very much feels like a splitting of hairs, if you have a better definition / description of what we are talking about here, please be kind enough to provide that change. A criticism without an alternative is simply a waste of everyone's time (IMO) - and this is a time sensitive undertaking.

The spec uses some precise definitions of "string" that do not mean
"absence of markup". For example, the "innerHTML" property returns a
string.

I suggest "plain text" or "plain text string".

This would be more consistent with language in the spec and its
references, for example:

  http://www.w3.org/TR/charmod/#sec-RefProcModel

  http://www.rfc-editor.org/rfc/rfc2046.txt

  http://www.w3.org/WAI/PF/aria/complete#def_accessible_name

  http://www.w3.org/TR/WCAG/#namedef

> Do you have a reason why it shouldn't be "should"?

Considering making new guidance MUST-level conformance requirements
before reverting to making them SHOULD-level or purely informative
leads to thinking through situations that would constitute exceptions
to the guidance which helps us produce more precise requirements for
interoperability and avoidance of harm.

Can we think of any exceptions where using @aria-describedby to
reference hidden DOM constituting a good description as rich text but
a poor description as plain text would not be harmful? If not, why
leave such markup as conforming HTML? If there are such exceptions, it
could help authors to spell them out.

--
Benjamin Hawkes-Lewis

Received on Saturday, 21 April 2012 12:14:11 UTC