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

On Thu, Aug 16, 2012 at 5:50 PM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
>> 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.

And what will happen if user agents do something different to what the
spec describes?

For example, if Firefox/NVDA and Safari/VoiceOver implemented the
proposed behaviors would the spec change accordingly?

> The ARIA spec. is not "negotiated" by another working group.

Note I didn't say it was; I closely followed PFWG Chair Janina's wording here.

> The ARIA spec. went through a last call comment period.

Sadly, the W3C Process doesn't guarantee sufficient review.

More importantly, it doesn't guarantee that, as the web corpus
evolves, browsers can continue to implement the ARIA spec to get web
compatibility even for the features described in the spec as opposed
to new features.

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

Yes, the value of targeting ARIA 1.0 Host Language conformance for
HTML5 is less than entirely clear to me.

In terms of spec cleanliness, I suspect HTML+ARIA would be better off
as an extension spec along the lines of HTML5+RDFa, but spec
cleanliness does not necessarily lead to better interoperability. The
devil is in the details of how exactly HTML and ARIA interact, in the
confusion between the two vocabularies. It is hard to properly
modularize them for the same reasons it is very hard to properly
modularize CSS or HTML itself.

For the W3C's Mission of ensuring interoperable web access,
implementors knowing where to go in order to produce interoperable
code is a lot more important than spec cleanliness.

I imagine popular browser implementors will just follow some sort of
mishmash of the Living Standard and Steve's HTML5 to AAPI mapping
guide. It's not an ideal situation; ideally we'd have a mapping guide
(or a version of it) that follows the Living Standard. Authors
generally won't consult any of these specs, but I wonder what people
writing guidance for authors will look at. Maybe they'll look at the
developer's version of the Living Standard and the ARIA best practices
guide and try and make sense of the elaborate differences between them
in how to express basic widgets in markup. It looks like MDN at least
has been pilfering from the Best Practices guide, even if they've
massively mangled the markup in the process:

https://developer.mozilla.org/en-US/docs/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-describedby_attribute

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

[snip]

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

Sorry, Richard, but you are continuing to misunderstand what the
proposal is asking. (Note it's not me who is asking for this. I
suspect it would better match author expectations and hidden more
useful if we disallowed references to @hidden sub-DOMs.)

Consider a typical user agent plus accessibility API client AT
scenario. The browser not the AT would parse the HTML, correct the
errors, resolve the hrefs, build the DOM, including for the hidden
sub-DOM. The sub-DOM would not (at least initially) be included in the
accessibility tree. When the the sub-DOM was opened by an action on
the node pointing at it via @aria-describedby, either (a) the browser
would render the content in an overlay with a backing accessibility
tree or (b) the browser would expose and maintain an accessibility
tree for the sub-DOM and the AT would render the accessibility tree.
At no point would ATs be responsible for HTML DOM construction or even
require access to the raw DOM: they would operate purely and entirely
via the accessibility tree. This would be fundamentally similar to
NVDA pulling out the link nodes from the exposed accessibility tree
and rendering links widgets in a Links List, except it would involve a
widget for all the roles in the ARIA taxonomy rather than just the one
widget.

That's certainly an additional burden, but it's not the level of
burden nor the interoperability risk you're implying. For one thing,
most of the ARIA roles already have native representations in platform
widget sets (derived as they were from desktop widget sets). I do
agree with you that an implementation where the AT _merely_ triggers
an action in the browser is likely more attractive to typical AT
implementors like NVDA, but if Apple would prefer to go down the route
of spitting out the widgets on the VoiceOver side, that's their
business. We're already in a situation where different combinations of
clientside technologies meet user requirements with a different
division of labour in different setups.

--
Benjamin Hawkes-Lewis

Received on Thursday, 16 August 2012 18:09:12 UTC