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

On Thu, Aug 16, 2012 at 10:18 PM, 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.

Note "hyperlink" is not necessarily a link to another document. (Not
sure if there's a more convenient term for that than "interdocument
link"?)

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

Right, it's true ARIA doesn't have native semantics for making
references beyond the current document.

I'm not sure that's a deficiency, but then I'm not a big proponent of
adding vocabulary to ARIA at this point.

> 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.

I'm really not quite sure what you mean.

An accessibility API client can typically access not just the links in
the current frame, but also all the other activatable links in the
document, and the links in other tabs, windows, and active
applications. It can locate each individual link within the desktop
environment GUI graph. Which links it chooses to enumerate is very
much up to the client.

I believe a Links List provided by typical AT like JAWS or VoiceOver
includes all the activatable links in the current tab, because that's
closest to an end-user's mental model of what a document is, even if
the tab actually contains multiple documents through transclusion
mechanisms like <iframe>, <frame>, <object>, <embed>, <img>, and
<video> etc, and the focus is inside one of those transcluded
documents.

Not sure how that behavior should change, or is changing, now that
ARIA and HTML are introducing new mechanisms for state into HTML
documents, such as @hidden, <dialog>, <details>. My naive view is that
links in @hidden should never be included, that links in <details> and
<dialog> should never be included unless open, and finally that if
<dialog> is modal, links in ancestor documents and dialogs should not
be presented.

The proposal accepted by WG decision makes @hidden a little like
<details> and <dialog> by giving it a sort of "unlocked" state, and in
that case links should be presented when it is "unlocked".

>>> 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.

Note that AAPI clients are not expected to understand ARIA per se,
just their system accessibility APIs. But yeah a DOM client consuming
ARIA needs to understand ARIA semantics. It might or might not also
need to understand some of the semantics of the host language and
other languages in the document in question. Probably to be genuinely
useful it would need to.

I'm still not sure what you mean by ARIA having the "concept" of
recognising HTML (how would the normative requirements for ARIA differ
if it did?) or how that relates to the proposal accepted by the WG. It
certainly doesn't require accessibility API clients to understand
blobs of HTML, as I've been trying to explain to Richard.

There is an important case where one of the proposals involves
spitting blobs of raw markup straight into the accessibility API and
that's mathematics:

     https://www.w3.org/Bugs/Public/show_bug.cgi?id=16586

Not sure I like the idea (for some of the same reasons as Richard's
misplaced objection) but to get away from that we'd need official ways
to represent mathematical semantics in the various accessibility APIs.

>>> 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.

Not clear on the issue here?

Author-side, progressive disclosure on focus can be handled with a
focus event listener.

Browser-side, some implementations could "click" <details> on focus to
follow platform conventions.

>>> 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.

I didn't say we weren't!

(As I've said before, my mental model of how authors work suggests we
should exclude @hidden content from aria-describedby.)

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

If you want to make that distinction, okay, but I don't think the
purely technical discussion really matters except for the social
effects of those technical details. For example, semantic bloat is bad
because it leads to more browser bugs and more author confusion.

>> 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.

I think a) the documents are very hard to read, b) most authors using
ARIA won't read them, and c) when the specs are pointed out to them,
they'll find what they demand counterintuitive. Witness:

http://www.nvda-project.org/ticket/2597

> 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.

I think <details> or <a href> would be a significantly better method
for ebooks to go with. Just treat it as part of typical ebook chrome
(like chapter headings or page numbers) rather than as some sort of
modification of the text.

It would be ideal if AT could programmatically associate <img> with
the following widget that reveals its description, however.

@aria-describedby can do that, of course, but it's way too clunky for
typical authors.

--
Benjamin Hawkes-Lewis

Received on Thursday, 16 August 2012 22:37:50 UTC