Re: ISSUE-30 (Longdesc) Change Proposal

On Wed, Oct 28, 2009 at 8:46 AM, John Foliot <jfoliot@stanford.edu> wrote:
> Jonas Sicking wrote:
>>
>> Ah, I guess I misunderstood what you were arguing was different
>> between the two features. I agree we can't always expect authors to
>> put a visible link to accessibility data on the page. Fortunately
>> HTML5 already has a means to deal with this. I'll adjust my examples:
>>
>> <img aria-describedby="desc">
>> <a href="description.html" id="desc" hidden>...</a>
>>
>> is equivalent to
>>
>> <img longdesc="description.html">
>
> No, because 'hidden': "... When specified on an element, (it) indicates
> that
> the element is not yet, or is no longer, relevant..."
> (http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#
> the-hidden-attribute)  Yet the description text is *extremely* relevant,
> so this is, IMHO, inappropriate usage of the hidden attribute, as defined.
>
>>
>> Contrary to what many people seem to believe, at least at mozilla we
>> don't just care about what the cost is to develop our browser, but
>> also what is good for the web.
>>
>> As I illustrated in previous emails in this thread, adding features
>> does not just come with benefits. It comes with significant costs to
>> all parties involved.
>
> Fair enough - however, it's the same cost to advance new attributes like
> <canvas> and <video> as well, right?  If so, why is it acceptable to
> invest the time, money and effort in "... documenting, evangelizing,
> testing, implementing and QAing..." a new element for 'the masses', while
> it is not OK to do so for an accommodation (that *currently exists in the
> HTML4 spec*) that provides value to a smaller market segment?

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

In fact, it only removes value for the reasons that I outlined in the
previous email.

> If you want to argue cost, let's go another way:
>
> 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>
>
> Both allegedly provide the same 'functionality' by your interpretation.
> Example one as a complete, stand-alone file, weighs in at a whopping 125
> bytes.  Example two by contrast is a svelte 82 bytes.  Since an authority
> no less than Google asserts that "...every single byte counts..."
> (http://www.youtube.com/watch?v=FPBACTS-tyg) I would suggest that by using
> @longdesc instead of aria-describedby you will result in a net savings of
> roughly 35% network traffic 'burden' for that one document.

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)

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.


>> For example not having a clear simple message to
>> web authors about how to provide a description for an element, I
>> strongly believe, means that fewer people will do the right thing in
>> providing such a description.
>
> If user-agents had provided real support for @longdesc over the past 10
> years and it was not being used today, you would have an argument.
> Mozilla still does not natively support this HTML 4 attribute today, so
> the cost of non-support from the browsers is equal to or greater than the
> cost to developers and end users. *If* the support had been there for the
> past 10 years, I have enough faith that more developers would "...do the
> right thing", especially in light of the "Standards" movement that was
> spearheaded by Zeldman et al some many years ago.

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?

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

>> The value we receive by obsoleting the longdesc attribute include:
>
> "...Most often, however, it is better to evolve an existing design rather
> than throwing it away." (HTML5 Design Principles:
> http://www.w3.org/TR/html-design-principles/)

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.

>> * Smaller HTML5 spec
>
> Smaller than what?  HTML5 already appears to be the single largest spec at
> the W3C; even with the jettisoning off of aspects of the specification to
> other stand-alone documents it is still huge.  The 'savings' is
> negligible.

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"?

>> * Clearer message to authors for how to make their pages accessible
>
> We can have a clear message on the proper implementation of @longdesc that
> would be simple to understand and deliver upon.

This doesn't address the problem. The problem is having a clear
message for how to provide a description for an element. See my
original email.

>> * Simpler AT tools
>
> ??  AT *today* supports @longdesc - I personally do not think that they
> are going to now remove this support in future versions. Why would they?
> Just to replace it with aria-describedby? Really?

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.

>> * Simpler browsers
>> * Simpler validators
>
> "...consider users over authors(, authors) over implementers(,
> implementors) over specifiers(and specifiers) over theoretical purity."
> (HTML5 Design Principles: http://www.w3.org/TR/html-design-principles/)
>
> Jonas, much of your argument to date has fallen into that final category,
> where-by you are suggesting that with the addition of aria support, we
> can jettison older, less frequently used attributes like @longdesc and
> @summary.  This is both a false premise, as well as contrary to the
> overall design principles of HTML5.

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.

>> * Smaller risks that bugs will make the feature more complex in the
>> future (HTML parsing started so simple, have you seen what a complex
>> mess it is today due partially to bugs that people came to depend on)
>
> It is unclear how removing @longdesc reduces risk here. @longdesc is not
> that complicated to start out with, I am unclear on how content authors
> could insert significant bugs/errors using this attribute.

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

>> * Less time spent on creating a test suite (or if you spend the same
>> amount of time: better test suite)
>> * Smaller risk that authors will conflicting data in the two attributes
>
> ?? I believe you are not giving developers enough credit.

See above

>> * Less time for authors to learn how to make a site accessible
>>
>> In short, the same benefit you get from removing any redundant
>> feature.
>
> *IF* you accept the argument that @longdesc is redundant - which I do not
> (nor do others, so it isn't a slam dunk)

Indeed.

>> The question should never be "why not have this feature in
>> the spec", the question should always be "why should we have this
>> feature in the spec".
>
> @longdesc is an *accommodation* feature that is not replicated with (or
> by) any other existing or freshly minted alternative. It has current AT
> support, continued emergent support from mainstream browsers, and is
> already referenced in many teaching tools that support accessible content
> creation (albeit a smaller class of teaching tools than exists for HTML
> overall).
>
> The real question to me is, why wouldn't you want a specialty attribute
> like longdesc?

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

/ Jonas

Received on Thursday, 29 October 2009 00:18:56 UTC