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

RE: Revert Request

From: John Foliot <john@foliot.ca>
Date: Wed, 1 Feb 2012 21:19:38 -0800
To: "'Charles Pritchard'" <chuck@jumis.com>, "'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>
Message-ID: <010d01cce16a$44d5b160$ce811420$@ca>
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.

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

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

* 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

The Accessibility Task Force endorsed retention of @longdesc proposal
preserves what support we have in the 3 key areas of Discoverability & User
choice, Preservation of HTML Semantics and Richness, and (the limited but
existing) User-Agent Support."

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. I have tried, repeatedly, to focus on the end user requirements,
and have waited for appropriate solutions to come forward from those browser
vendors: Jonas (Mozilla) to date is the only one to even attempt to
seriously address the problems (which, frankly, is why I invested the time
it took me to reply formally to his proposal - I respected the fact that he
was trying to come forward with a solution beyond "deprecate longdesc")

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

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

Backward compatibility is also supposed to be one of the foundational tenets
of HTML5.

Received on Thursday, 2 February 2012 05:20:23 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:20 UTC