- From: John Foliot <jfoliot@stanford.edu>
- Date: Wed, 28 Oct 2009 08:46:36 -0700 (PDT)
- To: "'Jonas Sicking'" <jonas@sicking.cc>
- Cc: "'Charles McCathieNevile'" <chaals@opera.com>, <public-html@w3.org>
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