Re: Revert Request

On Wed, Feb 1, 2012 at 12:41 AM, Charles Pritchard <chuck@jumis.com> wrote:
> On 2/1/12 12:29 AM, Jonas Sicking wrote:
>>
>> On Tue, Jan 31, 2012 at 5:33 PM, Charles Pritchard<chuck@jumis.com>
>>  wrote:
>>>
>>> On Jan 31, 2012, at 5:08 PM, Jonas Sicking<jonas@sicking.cc>  wrote:
>>>
>>>> On Tue, Jan 31, 2012 at 2:29 PM, Charles Pritchard<chuck@jumis.com>
>>>>  wrote:
>>>>>
>>>>> On 1/30/12 8:47 PM, Jonas Sicking wrote:
>>>>>>
>>>>>> Similarly:
>>>>>> <table aria-describedby="desc">...</table>
>>>>>> <div hidden id=desc>Description here</div>
>>>>>
>>>>>
>>>>> While I disagree with this method.
>>>>
>>>> Why? Assuming that the explicit goal is to create content only visible
>>>> to AT, which is the stated requirement from the accessibility
>>>> community.
>>>
>>> Because it conflicts with existing practices and assumptions about
>>> content, both from a general CSS/DOM perspective as well as AT and ARIA. The
>>> requirement here is for a semantic means of presenting content without
>>> affecting the default visual representation; and the issue is whether the
>>> existing mechanism can be obsoleted. There is not a suitable replacement at
>>> present.
>>
>> Please note that I was in no way talking about deprecating @longdesc
>> in my email, as explicitly mentioned.
>>
>> What I was talking about was the practice of providing AT-only content
>> by using aria and other AT attributes to point to content which has
>> been hidden using @hidden. This includes using @longdesc to point to
>> such in-page content. Please see examples in my email.
>
>
> Here is how I read this:
> "I was in no way talking about deprecating @longdesc... I was talking about
> was the practice of providing AT-only content... This includes using
> @longdesc"

Indeed. I was talking about @longdesc (among other attributes). But I
was not talking about deprecating @longdesc. I don't see that as a
conflict.

> But back to being on topic: hidden is the same as display: none.
> That's my understanding.

Correct.

> display: none is a sledgehammer. It's heavy duty. I think there was some
> talk about tree flattening concerns.
> There are certainly issues with event bubbling, and simply receiving events
> (like focus).

display:none does not affect event bubbling. It does affect ability to
receive focus, so that might be something we need to fix.

> It's completely non-backwards compatible, as hidden really does hide things,
> it takes them right out of several trees.
>
> That's the biggest issue. Regardless of ease of use or merit, it's too big
> of a departure from how all of the browsers out there currently work. It's
> too much work on AT vendors.

I can only speak to how AT interact with Firefox. The AT software do
not dig into the firefox layout trees directly, instead there is a
special tree of objects specifically created for AT tools. This means
that to make rich content work in display:none and @hidden content
there are no changes required to change AT software, only Firefox
needs to be changed.

I would expect the same to apply to other browsers.

Hence, the parties that we are asking to be changed here is not AT
software but rather browsers. So far I have not heard browser claim
that this is a too hard change to make.

All I hear is people trying to keep status quo and worried about
suggesting any changes to any software, rather than see what solution
would lead to the best accessibility.

/ Jonas

Received on Wednesday, 1 February 2012 19:45:29 UTC