RE: ISSUE-30 (Longdesc) Change Proposal

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?  

Longdesc is nothing more than a URI associated to an image that links to a
longer description: the link goes into the DOM and is available to AT and
other UAs to use as required - it has AT support now, and as Opera has
shown, is simple to implement within the UA - so simple in fact that even
when the 'native' UA does not provide explicit support, third-party tools
can step into the void: https://addons.mozilla.org/en-US/firefox/addon/273


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.

So using @longdesc saves you network bandwidth, which equals money - it's
leaner, meaner, greener. <smile>

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

Any feature, be it an element or an attribute, that does not have broad
user-agent support is doomed to wither, as developers today, as in the
past, (for the most part) simply by-pass contentious development practices

(for example many aspects of CSS 2.1)
- it's bad enough today (for example) that they have to still arm-wrestle
with *that* v6 browser that refuses to die.  However, if something as
simple as adding longdesc="foo.html" to complex images provided real,
dependable, stable support across all browsers today, I think you would
see a lot more usage. We are at another of those chicken and egg impasses,
and in that regard I argue for caution.

> 
> 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/) 


> * 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.

> * 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.

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

> * 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.


> * 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.


> * 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. 


> * 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)

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

JF

Received on Wednesday, 28 October 2009 15:47:20 UTC