Re: Revert Request

On 28 January 2012 04:57, John Foliot <john@foliot.ca> wrote:
> 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).

See Silvia's earlier messages in this thread:

http://lists.w3.org/Archives/Public/public-html/2012Jan/0157.html
http://lists.w3.org/Archives/Public/public-html/2012Jan/0138.html

I actively think this whole approach is fundamentally flawed, but
clearly opinions on this vary within the WG.

In my opinion, trying to replicate longdesc functionality with ARIA
could be seen as, at best, a make-work scheme for the website
accessibility industry, and, at worst, an attempt to retrospectively
justify the temple built around duff 1997-era techniques by some
accessibility advocates during the period when W3C WAI accidentally
froze its accessibility advice for 11 years.

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

See the simple solution below.

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

Since this change to the HTML5 spec seems to be just bringing it into
line with what is already specified in ARIA, the core problem here
appears to be the poor quality of the WAI-ARIA 1.0 spec. Unless I'm
missing something, the WAI-ARIA 1.0 spec was written by the people you
regard as subject matter experts.

It seems there are parts of WAI-ARIA 1.0 where no one can agree on
what it actually specifies, or whether what it does apparently specify
is actually possible or even desirable. If we were closely following
W3C process we should probably try to get WAI-ARIA 1.0 rescinded.

However given where we are right now with HTML5, it’s probably better
to go ahead with WAI-ARIA 1.0, get more implementation experience and
then rapidly issue a revised version 1.1 that precisely specifies how
UAs should process ARIA markup.

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

Use CSS to control presentation.

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

This simple solution meets all the requirements:

<a href=foo><img src=pic alt="*the purpose of the link*"></a>

If users need to be able to determine programmatically that the link
is a long description of the image, or authors want to put two links
on one image:

<a href=foo rel=longdesc><img src=pic alt="*a programmatically
determinable long description link*"></a>

<img src=pic alt="*text alternative*" usemap=#map>
<map name=map>
<area shape=rect coords=0,0,100,50 href=foo rel=longdesc alt="*a
programmatically determinable long description link*">
<area shape=rect coords=0,50,100,100 href=bar alt="*on an image that
is already a link*">
</map>

This universal design approach works for everyone, right now, and
doesn’t require changes to accessibility APIs, software upgrades,
browser add-ons, user training, author training, or employing the
services of an accessibility specialist. Unlike longdesc (and ARIA)
this technique currently works in all screen readers, including
VoiceOver, Orca and NVDA, as well as all other AT, including screen
magnifiers, and all browsers.

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

Since nearly everyone agrees we should include ARIA support in HTML5,
it makes sense to include the ARIA functionality the authors of
WAI-ARIA 1.0 clearly believe is essential for AT users, and improve
existing accessibility APIs as required to support that functionality
as Silvia previously suggested, and/or patch it in at the UA level as
Jonas has previously demonstrated with his proof-of-concept code to
make Firefox expose a link pointed to with aria-describedby.

-Matt

Received on Sunday, 29 January 2012 18:16:04 UTC