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

RE: 48-Hour Consensus Call: InstateLongdesc CP Update

From: John Foliot <john@foliot.ca>
Date: Mon, 17 Sep 2012 16:20:28 -0700
To: "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>
Cc: "'Joshue O Connor'" <joshue.oconnor@cfit.ie>, "'Steve Faulkner'" <faulkner.steve@gmail.com>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>
Message-ID: <008601cd952b$08438ef0$18caacd0$@ca>
Silvia Pfeiffer wrote:
> 
> The thing is: if you read the HTML4 spec, there really is nothing
> stated about how the UA is supposed to expose it.
> http://www.w3.org/TR/html401/struct/objects.html#h-13.2
> 
> 
> If we re-introduce it into HTML5, we need to be quite clear about how
> this has to be implemented. Otherwise we will fall into the same trap
> again.
> 

The problem there Silvia is that we are constantly being told that HTML5
does not prescribe UI, that is the role of the Browser Vendors. Yet, as you
correctly note, until we have a standardized way of doing this, nobody is
going to do anything.

Catch 22.


Over the years, I have offered numerous suggestions on how this might look
(to the point of bribing a developer with a bottle of Port to knock out a
PoC), and we even have something of a pseudo-standard behavior that has
emerged.  

For "interaction", the path that has emerged is that the interaction be
found in the contextual menu. This is how Opera supports @longdesc today,
how the Firefox plugin that Patrick Lauke built works, and how Sean Hayes
outlined in his MSDN blog post:
http://blogs.msdn.com/b/accessibility/archive/2011/03/25/configuring-interne
t-explorer-to-handle-longdesc.aspx - I believe this makes a lot of sense, as
the longer textual description is in fact contextual to the image, so a
context menu seems logical to me. I will also note that the last time I
spoke with James Teh (NVDA) about this topic, and asked him if NVDA could
support an interaction model like this, he responded affirmatively.

The "discoverability" piece is slightly more complex, but it seems that if
we do not want to force authors to include a visual encumbrance (history: D
Link), then that encumbrance must be end-user initiated or moved to the
browser Chrome (TellMeMore extension for Opera by Chaals). I've also chatted
with a developer about putting that notification into the address bar, but I
also note that this is a limited solution, and would be a bit of a barrier
to low-vision users that use screen magnification. I was also asked about
the scenario where "the browser" had no Chrome to speak of.

After giving this some thought, I proposed that it be a two-step affair. The
first is that it would be a user-configurable setting in the browser
preferences (checkbox: indicate the presence of longer textual
descriptions), and I could accept the default setting of off. However, if
selected, then I suggested that the browser 'paint on' an overlay indicator,
in a fashion similar to how the Android Dolphin browser places a
semi-transparent overlay in the bottom right corner:
(http://cdn.androidtapp.com/wp-content/uploads/2009/12/Dolphin-Browser-Viewi
ng-AndroidTapp-Mobile-Website.jpg) While it does cause a "visual
encumbrance", it is one that the end user would choose to accept based upon
the benefit derived.

I don't mean to suggest that these are "The Answers(TM)", but they are my
personal thoughts borne from numerous hours of discussion and exploration
around this subject.  

If the HTML5 WG is prepared to accept that a certain level of UI in fact be
prescribed in the spec here, then I think that would be an overall net
benefit.  The question is, do the Browser Vendors accept that suggestion?

JF
Received on Monday, 17 September 2012 23:21:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 17 September 2012 23:21:03 GMT