Re: FORMAL OBJECTION (was RE: Working Group Decision on ISSUE-204 aria-hidden)

On Aug 16, 2012, at 2:46 AM, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> wrote:

> On Thu, Aug 16, 2012 at 7:06 AM, Charles Pritchard <chuck@jumis.com> wrote:
>> Hypertext links are a key issue in this discussion
> 
> Are they?

Yes: while the a11y tree can collapse, expand and mutate (aria-live, aria-hidden, etc), such items are part of the current document's workflow. @longdesc may link to a new URL: think a href target=iframe.



> 
>> Beyond the role of "link", ARIA 1.0 does not have the concept of following a
>> hyperlink.
> 
> Not really true.
> 
> http://www.w3.org/WAI/PF/aria-practices/#kbd_layout_remaining_description
> 
> http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_relations_reverse_relations


These are references with the existing document. They do not request fetching a new document or otherwise suggest a separate document context.

With items which move through lists, such as a list of links, this can be an issue. If I have five iframes open, I believe the enumeration of links would depend on which frame has my current focus.

"[These semantics are] unlike longdesc which typically requires the author to create a separate".


> 
>> Nor does it have the concept of recognizing HTML.
> 
> What do you mean?

ARIA may be consumed in various ways by a secondary user agent. One of those ways may simply be taking a snapshot of a tree, be it the DOM or the a11y tree.

Currently an ARIA agent may Ollie describedby, and simply flatten the DOM itself; or it may request the a11y tree the UA provides. Some may chose to process HTML or SVG semantics to enhance the experience, just as some UAs may use CSS to enhance the experience.

That said, ARIA consumers are not expected to understand other languages-- just ARIA. There has been excellent work on suggested ARIA mappings for consuming other languages, though. Mainly, that work helps vendors create ARIA supporting end points.

Microsoft has aria* available in their HTMLElement enumerations, for example.




> 
>> The concept behind longdesc, describedat, or in part, this idea of an
>> extended tree are all somewhat similar to how iframe operates.
> 
> They are all links _of a sort_ yes.
> 
>> From the a11y side, I've heard and agree that the bulk of use cases we're
>> discussing are areas where content should be presented to all users in some
>> manner. That's quite different than the typical use of label/describedby;
>> where the content has been made available to the user, and there are simply
>> some issues in the DOM where elements did not map 1:1 to presentation.
> 
> I'm not sure that's the typical use of aria-label and
> aria-describedby. (It sounds more like the typical use of some of the
> ARIA roles.)
> 
>> The @longdesc semantic ought to exist, but it's not "hidden"; it's really
>> more of an iframe, a popup, a footnote; a sub-section only made available
>> when the user conveys an intent to get more depth or more information.
> 
> <details>
> 
> <a href>

Sure, some of the suggestions for many of the use cases are that we have <details hidden>, and authors may want a shortcut so they don't have to have button onclick removeAttribute(details.hidden);

That's an issue with some of the use cases. In the details case, the click event should happen and the details should be rendered in the render tree. A focus handler would also be appropriate.

Yes, @longdesc and a href target=iframe are quite similar.


> 
>> As I understand things, a11y-centric groups and members have proposed that
>> @longdesc (HTML shorthand) and a new aria-describedat (ARIA next) be minted
>> for the use cases brought up. In contrast, browser developers have asked
>> that the meaning of "hidden" be relaxed so as to backport this feature into
>> existing specs.
> 
> Not really. As I see it, the technical rationale here is ultimately
> about what authors are likely to do, and thus what user agents are
> going to need to do to give users access.


That seems more like a social rationale. We are all concerned about what authors may do. That's why there's so much passion on this thread.

The technical discussion seems about  side-effects should @hidden be loosened and semantic bloat should two attributes be added/maintained.

> 
> e.g. Will authors use @hidden to include or exclude text from
> @aria-describedby? If the former, will they reserve @hidden for
> flattenable content or use it for all usages of @aria-describedby,
> including to point to long, structured, or interactive content?

The documents tell authors not to do that. So I'd wager that authors using ARIA and actively reading will follow the instructions.

That said, they do need a means to accomplish the task. I recall a publisher posting to bugzilla about the issue and requesting that longdesc be maintained.

They changed my mind on the issue. Prior to that, I did not see much of a need beyond flowto semantics.

-Charles