RE: ISSUE 30 @longdesc use cases

> This is somewhat circular reasoning. You're saying that it's obviously
> a mistake to link to inside a @hidden subtree because it's disallowed.
>No, I'm saying it's obviously a mistake to link to irrelevant content, and 
>that content inside a block marked by a hidden="" attribute is by 
>definition irrelevant.
>Then I'm saying it's not allowed, so as to help authors using validators 
>to catch this mistake.

This is getting a bit hilarious. 
I thought there was some objection to longdesc content being available to
only AT users. But here I see other mechanisms  being invented to allow
access for AT users to content that is generally hidden. Beats me.
Maybe these proponents do not realize that an AT user may access longdesc
content only if he/she chooses to and does not have to access it every time
tone navigates to the chart / graph. Instead of proposing such retrograde
measures to banish longdesc, one may do well to urge browser makers to
improve support for longdesc- an attribute that has been around for over a
decade. E.g. at user's option make the longdesc content visible.   
Maybe everyone should re-read the HTML4 specs for longdesc and then revisit
the argument against 'longdesc'. Then one may see no problems at all on
second thoughts. By the way, can someone dig out and post the  arguments
against longdesc?
You come up with something new and then AT makers and  browser makers need
to implement it and developers need to learn and understand it and code it
correctly. This takes a while. And there will be two methods in use: someone
will use this new convoluted technique and some will use the longdesc
method. Confusion will be rife and accessibility will suffer.
By the way, does anyone remember the D-link that was in vogue when longdesc
was not supported as well as it is now? Content authors often had a problem
inserting an anchor with "D" as anchor text and users too did not understand
its purpose. 
Why is it difficult to understand that longdesc is an attribute designed to
accommodate the needs of a subset of users. 
Why change something that is tried and tested and works for the user group
it is intended to serve? Really this is not an issue that requires
re-invention. Time and effort will be better spent tackling more challenging
issues. Else circular reasoning will become the order of the day. 
Sailesh Panchang
Accessibility Services Manager (Web and Software)
Deque Systems Inc. (www.deque.com)
11130 Sunrise Valley Drive, Suite #140,
Reston VA 20191
Phone: 703-225-0380 (ext 105)
E-mail: sailesh.panchang@deque.com

-----Original Message-----
From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On Behalf
Of Ian Hickson
Sent: Monday, August 23, 2010 7:55 PM
To: Jonas Sicking
Cc: Joshue O Connor; HTML Accessibility Task Force; HTML WG; W3C WAI-XTECH;
Barry McMullin; Laura Carlson
Subject: Re: ISSUE 30 @longdesc use cases

On Mon, 23 Aug 2010, Jonas Sicking wrote:
> On Mon, Aug 23, 2010 at 4:14 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On Mon, 23 Aug 2010, Jonas Sicking wrote:
> >> >
> >> > Elements that are not hidden should not link to or refer to elements
> >> > that are hidden.
> >>
> >> This, however I don't agree with. Why should this not be permitted?
What
> >> problem is solved by forbidding this?
> >
> > It solves the problem of someone accidentally linking to a section that
is
> > hidden (which they obviously wouldn't do on purpose, since the hidden
> > section is by definition irrelevant, so linking to it would be
pointless),
> > and then realising their mistake when the validator points it out.
> >
> > In your suggestion, the text is not irrelevant. It's very relevant.
> 
> This is somewhat circular reasoning. You're saying that it's obviously
> a mistake to link to inside a @hidden subtree because it's disallowed.

No, I'm saying it's obviously a mistake to link to irrelevant content, and 
that content inside a block marked by a hidden="" attribute is by 
definition irrelevant.

Then I'm saying it's not allowed, so as to help authors using validators 
to catch this mistake.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 24 August 2010 20:52:35 UTC