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

Re: 48-Hour Consensus Call: InstateLongdesc CP Update

From: Joshue O Connor <joshue.oconnor@cfit.ie>
Date: Tue, 18 Sep 2012 09:23:53 +0100
Message-ID: <50582F99.6050905@cfit.ie>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
CC: John Foliot <john@foliot.ca>, Steve Faulkner <faulkner.steve@gmail.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Silvia Pfeiffer wrote:
> On Tue, Sep 18, 2012 at 5:55 PM, Joshue O Connor<joshue.oconnor@cfit.ie>  wrote:
>>> Note that we need to be careful to
>>> pick something that also works on devices that have no mouse.
>> I would suggest that by and large the a11y community is aware of that.
> I don't think @longdesc has a problem with being exposed in
> screenreaders or other accessibility tools (once, of course, it is
> handed through from the browser).

Yup, and really lots of AT is mediated via the browser, even those for 
switch users, non-mouse users etc.

> I think the real problem is that of having a visual encumbrance for
> sighted users and that we don't know what that would be.

Right - that touches on my points below.

> One suggestion was to add it to the context menu. This, however,
> relies on a mouse or an alternative means of opening the context menu,
> which is often not available in e.g. mobile devices.

Opening a context menu via a UA should be a case of revealing the 
attribute to the UA ad defining in the UA what it should do when it 
encounters the attribute. The UA just needs to flag to the user the 
presence of the @longdesc in the first - in a way that suits the users 
needs - then how it is triggered should also largely be defined by a 
user set of preferences, options etc.

> I was just trying to point out that there are non-accessibility
> related requirements, too.

Good points Silvia and I appreciate them. Your points are timely as they 
touch on something else that does need to be addressed in this 
discussion. Just who is @longdesc for?

1) For people who are blind and VIP
2) For people with cognitive impairments who will benefit from a long 
descriptor to aid comprehension.
3) Everyone

Is it 1), 2), or 3)? Or a combination?

I may of course have missed a few groups but the point I am making is 
that there are different implementations for each use case. I also 
*don't* agree with having a poor solution potentially designed for 
'everyone', that doesn't successfully meet the needs groups such as 
blind or VIP.

So I would rather that we did one or two use cases correctly rather than 
play lip service to Universal Design (as I have a fear that *may* be the 
case). Not that I have a problem with UD but, as Chaals said there have 
been lots of clever people on this issue for years without a successful 
resolution - so no disrespect to anyone here (as we live in hope of 
revelation do we not?).

So my preference is to satisfy the needs of blind, VIP, people with 
cognitive impairments - in that order.


Received on Tuesday, 18 September 2012 08:24:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:30 UTC