Re: Finalizing an Issue-204 CP

This is a very thorough analysis, thanks Ben!

On Sat, Apr 21, 2012 at 10:13 PM, Benjamin Hawkes-Lewis
<bhawkeslewis@googlemail.com> wrote:
> 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.


I like this approach. Would this be something that we could introduce into aria?

Regards,
Silvia.

Received on Saturday, 21 April 2012 21:56:54 UTC