RE: Revert Request

Matthew Turvey wrote:
> 
> I think people who are unhappy with this change would be best advised
> to actually start discussing the problems they see with it, rather
> than sending revert requests which could just end up being a waste of
> everyone's time. I think the best place to have these discussions
> would be on this list.

The problem is, we *HAVE* been talking about this, it's just some folks
haven't been actively listening (and I can look pointedly at you Matt).

The problem with trying to push html-rich content into some kind of hidden
or off-screen location is that once done so, *the Accessibility APIs* - not
the browsers, not the screen readers, the Operating system APIs, flatten
that text to string text and any and all HTML markup is lost. And there is a
very good reason for this - tab focus.

I first brought this to the attention of the Working Group in an email
almost a year ago (24 Feb 2011 -
http://lists.w3.org/Archives/Public/public-html/2011Feb/0415.html) and
further expanded on it in a detailed, researched response to Jonas' change
proposal on 28 Oct 2011
(http://www.w3.org/wiki/A11yTF/longdescresponse#Potential_for_Harm) 

There is no question that when Jonas first brought forward his proposal he
did so with the desire to find an alternative to @longdesc, and I both
discussed he proposal with him face-to-face at TPAC '11 (as well as thanked
him for the effort), but I also reiterated to him what the problems with
regard to the AAPIs were - he was both unaware and surprised by those facts,
but at the same time he no longer had the time to further work on his CP -
as evidence by the fact that he has not responded to Maciej's feedback on
that CP.

The current change added to the draft specification is technically flawed -
it breaks the web, the hardware and software simply cannot deliver on the
idea. If you, hixie and others refuse to listen to the subject matter
experts, then there is very little we can do about that, but no matter, you
still can't turn lead to gold and from a purely technical perspective this
is a harmful and non-starter change to the HTML5 draft. 

However, I for one am willing to be proven wrong. 

I welcome your *detailed* plans on how to deliver on the 3 key
user-requirements previously outlined in my response to Jonas using this
current change to the spec, your strategy on how you will convince all of
the OSes out there to re-write their Accessibility APIs, and how you will
further convince the hardware and software manufactures who will need to
completely rewrite their tools to address these fundamental changes to the
entire accessibility infrastructure.  

I look forward to you explaining how you can maintain html-rich content
hidden from sighted users, maintain tab-focus of that content so that those
non-sighted users can interact with that content, and yet how those
additional "tabs" will not get in the way of sighted keyboard users. I will
also remind you that AT does not simply mean screen readers, but also
includes tools such as screen magnifiers that shift the magnification 'zone'
to the tab-able element (and who are actively adding support for ARIA today)
for those low-vision users who can still see the screen, but just not all of
it.

Please, do discuss.


> The change proposal endorsed by the HTML-A11Y-TF (which you were a
> member of at the time) clearly regards invisibility as an essential
> feature of longdesc. For example:
> 
> "[longdesc] does not force a visual encumbrance or default visual
> indicator on sighted users. "
> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Conclusi
> on
> 
> and:
> 
> "There is no forced visual encumbrance. This is by design. "
> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/UseCases
> 
> and 7 of the 10 use cases apparently require the link to be completely
> invisible:
> http://www.d.umn.edu/~lcarlson/research/ld.html#uc-01

Again, you twist the words to suit your fancy. There has never been a
suggestion that the ability to know of the existence of longer textual
descriptions not exist, only that in the real world we cannot force that on
the design community. Even Jonas acknowledges as much in his change
proposal:

    "This is because page designers often have quite strict requirements on
the visual appearance of the page and it would likely negatively impact the
level of accessibility support if contents specifically for for example
screen readers had to be provided within those requirements."
http://www.w3.org/html/wg/wiki/ChangeProposals/DeprecateLongdesc 

The Task Force and PFWG are both in agreement and in fact WANT that the
user-agents provide a means for sighted users to easily discover
supplemental information that serves as an *accommodation* if desired
whenever it is available - we have said so numerous times, and have
applauded tools (browsers, plugins, blog posts) that are emerging as proof
of concepts around that idea today. 
(Opera's "TellMeMore" -
https://addons.opera.com/addons/extensions/details/tellmemore/1.2/ |
Firefox's "Longdesk" Plug-in -
https://addons.mozilla.org/en-US/firefox/addon/longdesk/ | Sean
Hayes[Microsoft] -
http://blogs.msdn.com/b/accessibility/archive/2011/03/25/configuring-interne
t-explorer-to-handle-longdesc.aspx | Dirk Ginader's jQuery Plugin -
https://github.com/ginader/Accessible-Longdesc)  

In my response to Jonas' CP I once-again reiterated the 3 major
user-requirements that we need, to meet the accessibility needs of not just
blind users, but any user who may wish or require enhanced textual
descriptions of complex images. They are:

 * Browsers must address the discoverability problem for all users.
 * Browsers must natively support the user-choice of consuming or not
consuming the longer textual description.
 * Browsers must preserve the HTML richness of the longer textual
description content. 


> Concerns about this tweak to the spec may be entirely valid, or
> entirely misplaced, or motivated by something else entirely, or easy
> to address satisfactorily without wasting the editor's, staff and
> chairs' time. Until people start discussing their concerns, there's no
> way of knowing whether there's anything of substance to be reviewed
> here or not. As above, I think people who feel it's important to
> discuss this issue would be best advised to actually start those
> discussions.

OK Matt, I've done that. I've shown where we've discussed this before, I've
repeated once again what the problems are, I've brought forward the
technical reasons why this is IMPOSSIBLE to support with today's
technologies, and I've invited you to provide specific details on how you
think the insurmountable problems that this current spec change introduces
can be resolved.

I welcome your researched and detailed response. 

JF

Received on Saturday, 28 January 2012 04:58:23 UTC