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

On Aug 14, 2012 11:03 PM, "Janina Sajka" <janina@rednote.net> wrote:
> Your comments on the ARIA docs are welcome.

Often provided.

> Regardless, all of these are specific to HTML 4 so should not be looked
> to for normative guidance in HTML 5

These specs repeatedly mention HTML5 and HTML5-specific features and
in some cases their references section includes HTML5.

So I don't understand why you think these specs are specific to HTML4.

> To the extent we have ARIA in HTML
> 5, it has so far been negotiated between the PF and the HTML WGs. The
> notable exception is this recent 204 decision.
>
> Last comment for now, structure in Describedby is OK when displayed, not
> when hidden according to latest ARIA thinking.

If the ARIA specs "are not final" and how HTML5 hosts ARIA is
"negotiated", then I don't see why the "latest ARIA thinking" should
be given greater weight than implementor feedback given here rather
than changing to reflect it.

Now there might be constraints, reflected in that thinking but not
articulated yet by yourself, on our collective action here.

A hard constraint would be substantial content in the web corpus that
depends on behavior contrary to what is proposed. I find it hard to
imagine what such content would look like.

Another constraint would be implementor feedback that we cannot do
what is proposed. So far, we only have such feedback by proxy, in the
form of what Richard said in his response to the Change Proposal:

"This creates an undue burden on assistive technologies. Assistive
technologies, such as screen readers would need to provide navigation
of hidden content to make this worth while. This would mean that the
AT would have to produce something similar to an accessibility tree or
DOM that the browser already does and then walk it. That is a huge
burden and we don't want to have ATs start to become browsers. Unless
the user agent is going to provide a vehicle to render the hidden
content referenced by aria-describedby in the future then the HTML5
specification should not make this statement. We should not be
requiring ATs to reproduce the functionality of the browser which
includes parsing content into their own DOM. This was done in the past
in the early versions of IBM's Home Pager Reader and the fact is that
the web is constantly evolving and this model cannot be sustained."

https://www.w3.org/2002/09/wbs/40318/issue-204-objection-poll/results

This response involves thoroughgoing misunderstandings that make me
question the value of any communications that happened with
implementors behind the scenes.

For example, the response supposes an accessibility API client
rendering the content would need to parse HTML where as actually it
would only need to render widgets based on walking the accessibility
tree.

Or again, the response supposes that rendering the content imposes
substantial new burdens on API clients because of ongoing evolution in
HTML. But in fact, these clients already have to shoulder most of this
burden. Consider how a screen reader would need to cope with a new
type of control. When we introduce a new control, we will need to
provide guidance to accessibility API servers on how to map the
control to accessibility APIs. There are two possibilities at this
point. One possibility is that we will be able to express the control
using existing API semantics that the screen reader understands. In
that case, its existing renderings (whether speech, braille, or
visual) would Just Work for the new control. Another possibility is
that we will need to invent new API semantics. In that case, the
screen reader will need to be updated anyway in order to render the
accessibility hierarchy to speech or braille. I concede that rendering
out the new semantics visually as well would add some work here, but
not as much as Richard's response seems to imagine. The fundamental
difficulty here is that accessibility API clients lag years behind
accessibility APIs, which themselves lag years behind evolving web UI
patterns. Fiddling around with whether user agents can or can't expose
hidden semantics really isn't going to address that difficulty.

Finally, a browser can include assistive technology and ARIA in any
case encourages any user agent to make use of its semantics. As such,
the spec text, however clunky, allows browsers to "provide a vehicle
to render the hidden content".

--
Benjamin Hawkes-Lewis

Received on Wednesday, 15 August 2012 09:01:36 UTC