RE: ISSUE-30 (Longdesc) Change Proposal

Jonas Sicking wrote:
> 
> My argument is that it doesn't add any value to any market segment.
> @aria-describedby already provides the functionality that @longdesc
> does.


Jonas, I'm sorry but that is patently false. Leif and I have offered
samples, explanations and real world scenarios that disprove this mistaken
belief, and continuing to cling to it simply shows intransigence on your
part. They are similar in many ways, and different in many other ways. A
shoe is not a boot, and a boot is not a shoe - yet both are foot-ware.


> >
> > Two examples:
> >
> > 1) <html><head><title>Test</title></head><body><img
> > aria-describedby="1"><a href="1.html"
> id="1">description</a></body></html>
> >
> > 2) <html><head><title>Test</title></head><body><img
> > longdesc="1.htm"></body></html>
> >
> 
> I'll ignore the false math here. (Or show me a real-world document
> that would save 35% in size by using @longdesc over @aria-describedby)


82/125 = 65/100% difference = 35%.  And every byte counts(TM)...
(the examples above 'could' be a real world examples. Copy, paste, save,
compare)


> 
> Yes, @longdesc can produce fewer bytes than @aria-describedby. So
> there is value there. However I would argue that the cost (as outlined
> in previous email) is significantly higher.

Cost to whom?  Certainly not the end user, nor I would argue for most
developers either.


> 
> I'm glad to report that @longdesc support has been in firefox since
> version 1. I even personally put in the support myself. Unfortunately
> Firefox hasn't existed for 10 years. Can I have my faith anyway?

Faith and 'props' to boot, although the 'support' in Firefox is/was
minimal, and far better solved with Patrick Lauke's plug-in.


> 
> Version 3.6 will remove it though due to lack of users using the
> feature.

See, that's both sad and short-sighted.  But it's also your business
decision... (I wonder how this will affect Patrick's plug-in, if at all?)


> 
> This seems like something you should bring up with the WAI group. They
> were the ones choosing to design @aria-describedby by throwing away
> @longdesc rather than evolving it.

WAI is not writing HTML5! (Too bad, as they'd probably do many things very
differently)  

To be crystal clear, nobody within WAI has 'thrown away' @longdesc, and
when the ARIA spec was being developed, aria-describedby was not
envisioned as a *replacement* for the accommodation that @longdesc
provides; however it was noted that it could serve a similar if not
identical function. There was *NEVER* any discussion to abolish or "throw
away" @longdesc as a legitimate solution to a real problem. 

When the ARIA development process began, the HTML landscape as we know it
was very different than it is today: XHTML2 was still being worked on,
HTML5 wasn't really anything (and certainly not within the W3C), and ARIA
was being developed to address issues with DHTML (Dynamic HTML, aka AJAX),
and *NOT* as the cure-all that could be magically intoned over all
accessibility problems like some form of holy talisman.

Using your logic however, let's get rid of <video> and <audio>, and invent
a <media> tag instead... I mean, after all they both require start, stop,
pause, volume control, etc.  Why differentiate? Media is media, right?

> 
> I'm not sure I understand your argument. I'm assuming that it's not
> "the spec is already big, so it's ok to put more stuff into it"?

It seems to me that the only time this argument (spec bloat) comes up is
when it is used against implementing (or rather, continuing) support for
accessibility features - it has been used on @longdesc, @summary, and
headers/id to date.  The size of the final specification should not be
criteria for adding or supporting accessibility accommodations. Period!
That might not seem logical or fair, but neither is being born with a
disability!

> 
> I can't speak for AT vendors since I'm not one myself. However as a
> software developer I'm *always* happy when i can remove code. Bloated
> software doesn't start out bloated. It gets bloated because features
> are only added, never removed.

Tell you what... since <canvas> is not accessible right now, is hardly
being used today, and is not supported in all browsers, let's remove that
from the spec too shall we? No? I thought so...


> 
> This is clearly not the case. In the very email I'm replying to I
> mostly talk about costs other than adding code to the implementation.

Accessibility and accommodation features cannot be judged by cost.  That's
a reality that I wish wasn't true, but is.


> 
> It's clearly complicated enough that most users of @longdesc do not
> use it as specified.

...and the cost there is?  @alt is abused too, shall we ditch that as
well?  Perhaps I missed something, but aren't we trying to develop a
feature rich technology that works for all users, and not some lowest
common denominator digital scratchpad.  People get things wrong all the
time - that in-and-of-itself is not a reason to abandon a useful tool.


> 
> I think I cited plenty reasons in the email you are replying to.

...and I think that I refuted them adequately. We will have to agree to
disagree however, as you seem to be fairly entrenched in your position
(something that I too will freely admit to being). I'm bowing out now and
hope that Chaals' bug-issue is resolved equitably. 

JF

> 
> / Jonas

Received on Thursday, 29 October 2009 01:33:52 UTC