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

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

The WAI-ARIA spec. is in CR. Meaning we are validating implementations and
all comments have been processed. The ARIA spec. is not "negotiated" by
another working group. The ARIA spec. went through a last call comment
period. If there are features that you would like to negotiate for 1.1 then
we can discuss that there with members of the ARIA working group. The ARIA
implementation guide is in last call but that is not the ARIA spec. itself.
As I have offered in the past if you would like to join the WAI-ARIA
working group you are welcome. We cannot have the HTML5 spec. defining ARIA
any more than we can have HTML5 defining RDFa or CSS. It is an
unsustainable and unmanageable approach to standards.

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

First, Benjamin, I have actually built a screen reader and work directly
with screen reader vendors on multiple OS platforms. Your comment is
completely misinformed. I stand by my statement.

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

Again, you have failed to understand the breadth of what you are asking.
One of the reasons you don't want ATVs doing the processing is error
correction. The fact of the matter is the web is ugly and browsers have to
perform error correction. A common scenario is anchor href values. They are
terrible and browsers actually have to fix this stuff. Also, there is
malformed html content that the browser needs to correct. If the algorithms
for doing this do NOT match the browser your AT will not reflect same DOM
as the browser.

We already have an accessibility API mapping guide in development for
HTML5. The net is to do this right the user agent needs to do the browser
work and not the AT. I have also built middleware transcoding servers for
seniors with distributed access to many users. You can see these issues in
spades.

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