Re: Revert Request

On Wed, Feb 1, 2012 at 9:19 PM, John Foliot <john@foliot.ca> wrote:
> Charles Pritchard wrote:
>> To: Jonas Sicking
>>
>> > 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.
>>
>> Yeah, you're hearing the claim from authors and a11y experts instead.
>> There's a reason for that.
>
> One of the reasons is that a significant part of the problem is at the OS /
> Accessibility API level.

What do you have to back up that claim? Given that we in Firefox
already expose rich content for aria-describedby when the content is
not hidden, i see no reason we couldn't when the content is hidden.
With no changes to Accessibility APIs or OSs.

>> > 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.
>>
>> I assure you, the a11y experts commenting on this thread have been
>> working in accessibility for a long time.
>> Yes, they are conservative, trying to keep some things the same. That's
>> because there is structure around those things.
>
> FWIW, as one active member is this thread, (and also one of those long-time
> accessibility folk) I am less focused on new versus old (status quo) and
> more on user needs and interaction patterns. As I concluded in my response
> to Jonas' Change Proposal (http://www.w3.org/wiki/A11yTF/longdescresponse):
>
> "For Jonas' Proposal to truly solve the problem at hand the Browsers would
> have to address the core issues identified - this is not a mark-up problem,
> this is a User Agent problem.
>
> * For any Proposal to succeed, the Browsers must address the discoverability
> problem for all users. This is not indicated anywhere in Jonas' Change
> Proposal.

Does any other proposal? If so, could you provide a link.

> * For any Proposal to succeed, the Browsers must natively support the
> user-choice of consuming or not consuming the longer textual description.
> This is not indicated anywhere in Jonas' Change Proposal.

Does any other proposal? If so, could you provide a link.

> * For any Proposal to succeed, the Browsers must preserve the HTML richness
> of the longer textual description content. Currently with aria-describedby
> the only way to do this is to visibly render the text on screen, and thus a
> browser requirement. This is not indicated anywhere in Jonas' Change
> Proposal.

Yes it is. My proposal says that this is something that browsers should change.

> Jonas indicates that none of the browsers vendors have said they can't
> address these problems, but we've seen no indication that they are prepared
> to do so.

Why are you more concerned about this part of the HTML5/ARIA specs
than, say, the willingness to implement <input type=date>?

> Meanwhile, the existing technique (using @longdesc) *does* address those
> problems, at least for the core user-group that require longer textual
> descriptions.

How does longdesc address any of the problems you raise above?

/ Jonas

Received on Thursday, 2 February 2012 07:03:04 UTC