W3C home > Mailing lists > Public > public-html@w3.org > February 2012

Re: Revert Request

From: Charles Pritchard <chuck@jumis.com>
Date: Wed, 01 Feb 2012 11:54:55 -0800
Message-ID: <4F29988F.6050504@jumis.com>
To: Jonas Sicking <jonas@sicking.cc>
CC: Laura Carlson <laura.lee.carlson@gmail.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Sam Ruby <rubys@intertwingly.net>, Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, HTML WG <public-html@w3.org>
On 2/1/12 11:44 AM, Jonas Sicking wrote:
>> >  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.

Yes, browsers implement a separate "accessibility tree".

Currently, "hidden" means hidden, for both non-sighted and sighted user.
That's intentional.

A site using the proposed @hidden semantics would be fundamentally 
different than a site using the old @hidden semantics. And that's 
something an AT would have to cope with.

Some ATs do walk the DOM.
display: none items have no CSS box, which means many events are disabled.

We've been working hard on Canvas to handle a special case where items 
are not marked display: none, but they lack CSS integration.
It's been several years now with Canvas, that it's taken to build a 
consensus. And that's not even crossing through to changing display: 
none semantics.

Those are some reasons why this @hidden thing is a huge battle.

It's really far more appropriate to do @hidden via alternate CSS 
stylesheets.
In that manner  @media alternative {} and @media screen {} might have 
two different visualizations.

And while that's certainly an option, it's not something that requires 
any change in the current display: none semantics.

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

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

It would be nice if we could just turn on microdata, or just use ARIA, 
and everything would just work.

But that kind of viewpoint only works for forward-thinking browser vendors.

For the rest of us, we're aware that people are still using IE6, that 
not everyone throws away their iPhone to get the newest model, with the 
newest browser; that some people keep their old laptop, which runs just 
fine, but Firefox stopped supporting in version 3; that some people who 
can't afford new computers get old ones via recycling programs. We're 
aware that people use old and existing software, and that's an OK 
situation. That's where WCAG-TECHS comes in.

This is a very different perspective than yours. I'm not asking you to 
change yours. Your perspective (upgrade, it's easy), is perfectly fine. 
I appreciate your perspective. I hope you will appreciate mine.


-Charles
Received on Wednesday, 1 February 2012 19:55:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:29 UTC