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