W3C Control To Major Tom

February 23, 2011
CSSquirrel #81: W3C Control To Major Tom

In the past I’ve made it fairly clear that I disagree with a lot of the decisions that HTML5 editor Ian Hickson has made in the past, such as the movement of the WHATWG version of HTML5 into Last Call (well before the W3C has done so, creating an oddball situation where arguably the spec exists in two different states). I felt that he was making a decision to move the spec forward to meet an arbitrary timetable, and not because it was mature enough to deserve that state.

Now that the WHATWG has gone onto its version-free HTML Utopia, leaving the W3C to make sure there’s a benchmark for browser vendors to compare against with what us mere mortals are still calling HTML5, I had hoped that at the very minimum we could rely on a standard that would properly address all the issues before declaring itself an adult.

I was wrong.

Accessibility is an issue that gets me worked up at times. While observing the various battles in the mailing lists of the W3C, it becomes clear that often those most aware of good practices for accessibility are given the least amount of attention by decision makers. Right now we’re witnessing the W3C’s chairs pushing for HTML5 to move to Last Call while ignoring a massive lump of requested data about an accessibility issue.

AKA: They’re moving the spec forward without addressing existing, outstanding issues.

Today’s comic highlights my opinions on that.

It seems that as a result we’re going to end up with a standard that will only address best practice for accessibility as some sort of later patch. This is a load of crap.

For some reason, several smart people think the longdesc attribute is hard to use. So hard to use that we’d best not even bother keeping it in HTML5 as a means to provide alternate text for images to sight-challenged web users.

I’m going to tell you how to do it in a detailed fashion, and you can decide if it’s hard: 1. Put a longdesc attribute on your image with a value that points to a url of a page with a detailed description of the image. 2. At that destination, write the description.

Pretty hard stuff, right? I don’t know if you can remember all that.

This culminated last August as Issue 30, where the working group chairs decided to leave longdesc out due to a lack of data, and they encouraged people to feel free to get more data and approach them again.

In fact, I quote:

This issue can be reopened if new information come up. Examples of possible relevant new information include: use cases that specifically require longdesc, evidence that correct usage is growing rapidly and that that growth is expected to continue, or widespread interoperable implementation.

Laura Carlson took them at their word, creating a research document with over 150 examples harvested from the “wild” and compiled into several use cases, along with relevant local laws and policies from governmental and corporate entities using the attribute.

Armed with a treasure trove of the requested data, she asked the chairs to re-0pen the issue to consider it before Last Call.

Sam Ruby, W3C HTML5 Co-Chair, says “Thanks for all the data. I know I asked for it. But no. Focus on other important stuff instead. Ha ha.” (That might be a bit flavored of a paraphrasing…)

I couldn’t help but read into that an unspoken “Addressing the needs of blind people should take a back seat to getting the spec out the door.”

Class act, guys.

Respond To This Post

Share This Post With Others: |

Category: Comic | Tags: , , , , , , , , ,

24 Responses to “W3C Control To Major Tom”

  1. Hey Kyle,

    As always – I like your take on the situation, even if I don’t agree with it in this case. I think you’re reading too much into what Sam was saying. Nobody wants to tell the visually impaired to take a back seat, especially since almost every one of us will be in that position in our elder years.

    The accessibility issues for HTML5 can range from a “complete mess” (and Canvas and WebGL) to “not that bad”. I think that we can all agree, however, that there isn’t enough work being done on the accessibility stuff and the reason for that is because, quite frankly, accessibility is the last thing on most people’s minds. The people that care deeply about it are few and far between. The ones that are not visually disabled are in addition, amazingly compassionate people who should be lauded for the work that they do.

    That said, you’re being a bit too harsh on the HTML Working Group Chairs. I think they’re being as fair as they can be given that pre-LC issues were requested to be submitted many months ago. Laura has done a great job, along with all of the other HTML Working Group accessibility folks, of putting forward a strong proposal. There is still room for @longdesc to be discussed – there will be more than one Last Call for HTML5, I can almost guarantee that.

    Even assuming that @longdesc fails to be placed back into the HTML5 spec, all is not lost. RDFa could just as easily be used to provide accessible descriptions. In fact, I would argue that RDFa would be a far better mechanism than @longdesc:


    <a about="http://www.cssquirrel.com/blog/2011/02/23/w3c-control-to-major-tom/" rel="a11y:script" href="/comicscripts/script81.htm">accessible version</a>

    That’s something that nobody is going to be able to take away from the Accessibility community, and it will work across many other markup languages like: SVG, HTML4, HTML5, XHTML1, ODF, and ePub. Why not expend effort pushing that forward instead of @longdesc?

    PS: It’s no mistake that RDFa is a powerful tool for providing accessibility – that was by design. Semantics and accessibility walk hand-in-hand.

  2. > “While observing the various battles in the mailing lists of the W3C, it becomes clear that often those most aware of good practices for accessibility are given the least amount of attention by decision makers.”

    Do you think proper, real-world accessibility experts like the Royal National Institute for the Blind are aware of good practices for accessibility? What do they say about using longdesc?

    “Note: we don’t recommend the use of the LONGDESC attribute because it isn’t available to users without screen readers. The long description should be made available to everyone who can’t process information conveyed in images, whether or not this inability is sight related. ”

    Background and guidance – RNIB Surf Right [Word Doc] downloadable from
    http://www.rnib.org.uk/professionals/webaccessibility/downloadarea/Pages/download_area.aspx

  3. I believe that the work that Laura is now doing is excellent[1]. I truly wish that a fraction of that work had been done before in the first 2.5 years this item was tracked. It would have made my life easier.

    That’s water under the bridge now. We are on the cusp of reopening this issue based on this new information[2]. I truly believe that the new information is there, we are just dotting our eyes and crossing our tees at this point.

    Once reopened, we are committed to resolving the issue before progressing to Candidate Recommendation. In fact, should there be a second last call, we are committed to resolving this issue before we proceed to our second Last Call. So yes, if reopened (which appears to be likely), it will be resolved in time for HTML5.

    Amicable resolution prior to proceeding to (our first) Last Call is still a possibility. The only thing the chairs have declined to do is to set a deadline of March 22nd[3] for people to evaluate this new data and provide counter proposals. This is something the chairs are in consensus on. At this point it would require intervention by W3C staff in order to change this. Laura has indicated that she is not going to pursue that path[4].

    Beyond that, all I will say at this time is that if this is an issue that you feel strongly about, I encourage you to participate.[5] When I said resolved above, I mean decided based on the actual information and objections that are actually presented. If you have something to add and chose not to do so, then I am fully prepared to assume that you are willing to live with the outcome of this process, whatever they may be.

    [1] http://lists.w3.org/Archives/Public/public-html-a11y/2011Feb/0170.html
    [2] http://lists.w3.org/Archives/Public/public-html/2011Feb/0390.html
    [3] http://lists.w3.org/Archives/Public/public-html/2010Sep/0074.html
    [4] http://lists.w3.org/Archives/Public/public-html-a11y/2011Feb/0180.html
    [5] http://www.w3.org/html/wg/#join

  4. @mattur It shouldn’t surprise me to see you once again trying to spread your FUD around. For those who may even think that the RNIB is formally opposed to the @longdesc attribute, please note that one of the contributors to the change Proposal was Marco Ranon, Senior Web Accessibility Consultant – Royal National Institute of Blind People (RNIB). Ya, that guy.

    Instead of trying to continually obfuscate the issue, how about you tell us all how you would solve the 8 Use Cases put forward without using @longdesc, and meeting all of the other requirements. Do something useful for a change.

    @manu Your proposed solution does not meet one of the Use Case requirements: that the URL to the image be Programmatically Determinable to the image. It also fails the requirement that “A default visual indicator of the long description on-screen is unacceptable due to the author’s aesthetic principles.” – a point our current host CSSquirrel has eloquently stated in the past.

    Now a few facts:

    This is an issue that was initially logged in 2008, and it is not a “bug”. The deadline for pre-Last Call bugs was October 1st 2010 with a cut-off to escalate bugs to Issues by Jan 22, 2010. “Issues” require Change proposals attached to them by today, February 23rd. Last Thursday morning, the Chairs announced to the Accessibility Task Force that the @longdesc issue (Issue 30) had missed the January deadline for bugs. However, the situation surrounding @longdesc is that it is not a “bug” (there is no bug in the bug-tracker for this) – it is, in fact, an Issue with a disputed resolution. This scenario was not addressed in the Time-line to Last Call document, and so at the very least, there was a procedural hole. However, to now state that this issue will be discussed AFTER Last Call is offensive, antagonistic, and sends a very bad message that, as Kyle notes, accessibility issues can take a back-seat to meeting an arbitrary time-line.

    The reality today is that @longdesc is being used by authors, is present in numerous authoring environments (in both editors and CMS solutions), and is being supported by numerous specialized as well as (some) mainstream user tools today – and will continue to be so into the future (tested and confirmed last week: IE9 beta plus JAWS exposed the @longdesc attribute and link to the tester, and delivered exactly the functionality prescribed by HTML 4.01).

    Further, adding the @longdesc attribute to an image in an otherwise conformant HTML5 document still functions for all of these tools today, with the sole exception being that conformance checkers register an error: this conformance error however does not reflect in *any* impact on an end-user accessing @longdesc content from that HTML5 document via AT, or even via the limited visual renderers available (i.e. plug-ins or other). There is technically no reason to make @longdesc non-conformant.

    Should Firefox, Safari, Chrome and Internet Explorer do a better job of exposing @longdesc to sighted users? Sure. Should VoiceOver do something useful with @longdesc? I think so (if for no other reason than @longdesc is conformant in HTML 4.01). But even if these tools choose to ignore some of their users, other tools can and do successfully support @longdesc today – we should not let perfect be the enemy of good.

    Reinstating @longdesc into the HTML5 specification is primarily an editorial decision, as the reality today is that @longdesc is in our midst. Wishing it away with the stroke of a pen is both a perverse fantasy, as well as creates a real disservice to those users who today choose to access this accommodation when present, or author it in HTML5 for the benefit of users who desire it.

  5. re: “to now state that this issue will be discussed AFTER Last Call is offensive, antagonistic, and sends a very bad message”

    As someone who deals with Lawyers on a daily basis, I feel compelled to ask: “have you ever thought to take up a profession as a lawyer?”.

    I don’t dispute that there was a hole. It is never possible to prepare for all possible eventualities. That being said, I will note that nobody asked for a clarification, nor did anybody give us a heads up before the January 22nd deadline that there was an intent to re-escalate this issue. Had the new information been provided by January 22nd and the change proposal provided by February 23rd, I am confident that we would have accepted that arrangement.

    As it is, we are now planning on requiring change proposals at the same time as the new information is provided[1], closing that loophole.

    Meanwhile, John, if you are inclined to pursue this, please contact Mike Smith.

    [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=11447#c3

  6. @john: Fair enough, RDFa can address all of those a11y use cases – here are three examples:

    Use Case: Link the image to the accessibility script in a way that is visible on the page (sometimes I look at the scripts that Kyle puts together, just to see how he does the translation from a visual form to a textual form).

    <a about=”/images/comic/cs081.png” rel=”a11y:script” href=”/comicscripts/script81.htm” >accessible script</a>

    Use Case: Directly link the image to the script in a way that is not visible on the page.

    <img src=”/images/comic/cs081.png” rel=”a11y:script” resource=”/comicscripts/script81.htm” />

    Use Case: Link the image to the script in the HEAD of the document because the author doesn’t want to “clutter” their document w/ extra markup.

    <link about=”/images/comic/cs081.png” rel=”a11y:script” href=”/comicscripts/script81.htm” />

    All three of these use cases are programmatically determinable and all three of them express the same semantic information – they give authors more choice than @longdesc. Not to say that you shouldn’t fight for @longdesc, but you can do so much more with a11y with RDFa.

    For instance, Doug Schepers (SVG dude) and I were talking about semantic-a11y enabling comics (“semantically”, get it- ahaha-*clears throat*), where you could describe each panel in SVG. So, if Kyle did the strip above in SVG instead of PNG, he could do something like this:

    <polygon about=”#sqrl” property=”rdfs:label” content=”CSSquirrel in a white space suit, wearing a light-blue bubble helmet.” …
    <polygon about=”#moon” property=”rdfs:label” content=”A white 1/4 crescent moon.” …

    He could even embed the entire transcript in the comic itself.

    Food for thought.

  7. @Sam

    …nor did anybody give us a heads up before the January 22nd deadline that there was an intent to re-escalate this issue.

    You’re having fun with us right? To suggest that you as one of the Co-Chairs had no idea that there was work afoot to re-escalate this issue, and that there was a strong desire to do so prior to Last Call is ludicrous. Do I really need to publicly parade the volumes of emails (both public and private) that have been exchanged about this topic since the day the chairs announced their initial decision?

    For the Record, there are exactly 307 public emails associated to Issue 30, 47 after the August 2010 decision. More specifically, you were copied on an email dated January 18th, 2010 that spoke SPECIFICALLY about this very topic. Further, it was recorded in the January 13th minutes of the Accessibility Task force’s weekly conference call that there would be a request being put forward. To suggest then that this came “out of the blue” with no prior indication is an insult to those involved, and to all those following this issue. If you were unaware of these facts, it is not because anyone was not forthcoming about them.

    Call me a lawyer, or call me something else, however these facts pretty much speak for themselves.

    As to pursuing Process issues with Michael Smith I, like Laura, choose not to do so. The legacy of how the chairs handled Process in HTML5 will be all yours to own.

  8. @John Foliot:

    Perhaps you should ask Marco why he’s contributing to a campaign to keep a technique that his employer recommends against using in their formal guidelines.

    Programmatic determinability is a means to an end – to make it perceivable to the user. See WCAG2 techniques for other options, or read the RNIB Surf Right doc referenced above.

    I’m not impressed with Laura’s document. I’ve only spot checked a few bits, but there’s some rather partial presentation of evidence.

    For example the IBM examples are listed under “No Forced Visual Encumbrance or Default Visual Indicator” but actually present text links in plain view.

    The Linux foundation example uses a longdesc on an image that is inside a link, which makes the longdesc inaccessible to Jaws users, so this seems to be pure accessibility theatre. This problem also seems to apply to the other logo examples, though I haven’t checked them all. The Fundacion Sidar logo example has this problem, and the other Sidar example links to a page that isn’t a long description(!)

    Other “No Forced Visual Encumbrance or Default Visual Indicator” examples already provide long description links in addition to the longdesc, eg CSSQuirrel uses a link hidden by CSS. The Hawaii Public Schools example uses a link on the image pointing to the same URL as the longdesc. The Federal Deposit Insurance Corporation and the Interagency Committee on Disability Research both use hidden text links. The Research and Innovative Technology Administration example uses a hidden link on a separate spacer gif. Like I say I haven’t gone through all of them, but there’s some pretty weak examples here.

    I’m not sure why the examples created by you, Chaals and Laura _after_ the decision was made to obsolete longdesc are included – presumably to pad out the numbers. It’s particularly unconvincing since afaict none of you ever used longdesc before the decision, and since they’re on pages you each control you could just use a visible link anyway.

    Some of the laws and guidelines citations seem to be a bit economical with the truth too, eg most are just quoting WCAG1’s “(e.g., via “alt”, “longdesc”, or in element content).” The Illinois guidelines quote continues “… Because longdesc it is not yet supported by most web browsers, it *should not be used as the only method* of providing a full description.” And Durham University also makes this point “Browser support for longdesc is poor except in the most recent browsers. Therefore, *an alternative method of accessing this content must be provided*.”

    So ISTM most of these examples and citations disprove the need for longdesc at all. As I whole, I think Laura’s document is a best effort attempt at making the case for longdesc and deeply unconvincing.

  9. @mattur Here you are: http://www.w3.org/wiki/HTML/ChangeProposalTemplate Feel free to be as thorough as you wish.

  10. John, there is no question that I was aware that there was an intent to ask that issue 30 was to be opened at some point. I merely maintain that at no point prior to January 22 was it clear to me that there was an intent to do so prior to the cut-off for last call.

  11. @sam we can go ’round and ’round on this and we’ll still end up where we are today.

    The January 22 cut-off date was for “BUGS” as clearly written in the Timeline document:

    - Jan 22, 2010 – cutoff for escalating bugs for pre-LC consideration

    (I did not write this text, the Chairs did)

    Issue 30 was an Issue on January 21st 2010, and is an Issue today: it is not, nor was it ever considered, a “bug”. If the intent of the Chairs was to treat the re-opening of an ISSUE as a BUG that fact was never communicated to anyone – had it been so I am confident that Laura et al. could have met that date. You yourself stated in a January 6th email:

    We stated that the issue can be reopened if one or more of these conditions are met. I have already said that I believe that the conditions have been met.

    It would have been an opportune time then to suggest that the Chairs were viewing this re-opening as a January 22 deliverable (bugs) as clearly you were aware that work was nearing completion – you had already seen the research data collected.

    The FIRST MENTION of dates associated to ISSUES was February 23rd:

    - Feb 23, 2011 – every issue has at least one Change Proposal

    That the Chairs now choose to treat an ISSUE as a Bug is something that I have very little control over. To believe that it is a correct assessment however is certainly not something that I have to accept.

    It has been made abundantly clear that many were shocked and dismayed that the initial decision went the way it did, and to feign ignorance that we wanted it back into the Specification prior to Last Call I believes fools very few people.

    Whatever would make you believe otherwise?

  12. @mattur The Surf Right guidelines – which I’ve contributed to – don’t recommend LONGDESC as it isn’t currently implemented by browser vendors in a way that makes the long description available to all users. We believe that a long description may be useful or necessary to a wide range of people with disabilities including low vision, learning difficulties and dyslexia. Currently many browsers only expose LONGDESC to screen readers.

    Having said that, we recognise that the need for a long description could in some cases clash with design requirements and although we don’t recommend it, we are not opposed to LONGDESC, as long as it’s used properly by web authors. In other words when it’s done correctly it doesn’t fail Surf Right tests.

    Until user agents provide full device independent support for LONGDESC, we will still recommend that it isn’t the sole means of finding a long description. However, because we hope that user agents will ultimately get this fixed, we’re prepared to take a longer view so that there is a standard way to provide long descriptions. Then there will be an updated version of Surf Right (we do believe in versioning).

    The correct URI for the change proposal is http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc

  13. First: Thanks for rallying on behalf of Longdesc. It seems to be much more sensible / semantic than aria-de…whatever that is.

    Second: Should there be a spec or recommendation about using absolute urls in longdesc? Chrome doesn’t support the longdesc natively, so I use “inspect element” to get the url – but in the case of the cartoon above, it’s a relative link, and therefore tries to open as “file://”. Granted, I know how to fix the url, and the browser when interpreting properly should give me the option, but it woulda been nice….

    Keep on rockin’

  14. Liked the article, liked the comic, both are spot on.

    Such a simple attribute, and such a passionate audience for its defense. If HTML5 is supposed to be for all communities, why so much heel digging on the part of the W3C? It’s not as if there isn’t multitudes of worst bits in the spec.

    There exists now such a state of confusion about who can do what and when and in what way that I don’t have the greatest hope that anyone other than the browser developers will have much of a say in the final rolled out HTML5: The Gotterdammerung version.

  15. What was worse, though, is that because the concept of deprecation was considered too quaint for Ian Hickson, and therefore isn’t practiced, rather than deprecate longdesc, he just made it obsolete.

    Yet what does deprecation provide us? It provides an alternative. It says, “Don’t use A anymore, use B.”

    The only problem is, we don’t have B. And when people filed bugs to ask for B, the bugs were closed by the co-chairs because they equated it with asking for a return of A.

    http://www.w3.org/Bugs/Public/show_bug.cgi?id=10853

    Absolute twaddle. Inconsistent and dismissive, all wrapped up in confusing, ever changing policies and procedures.

    Nothing about this was handled well. Not one bit of it.

  16. @Bill

    but in the case of the cartoon above, it’s a relative link, and therefore tries to open as “file://”. Granted, I know how to fix the url, and the browser when interpreting properly should give me the option, but it woulda been nice….

    I didn’t know any browsers did that. So thank you. I’ll make a change to the longdesc URLs to be absolute to prevent that issue.

    @Manu – I’m all for redundant methods of access, so I’ll look into what you propose. Thanks! I’ve also considered producing the comic as SVG instead of PNG in the future, although I’m not entirely certain how to transition to that. (Probably would be much easier if I created it in Illustrator, but for some silly reason I use Photoshop.)

    @Sam – In fact, I’m part of the mailing list. Call me cynical, but I’m just of the opinion that a comic has a higher level of impact than anything I’d write in the list would. Especially as a cartoonist and small web studio developer. I’d like to believe that participation in the process for something as large impact as HTML5 can occur both internal and external to the W3C’s mailing list.

  17. In fact, I’m part of the mailing list

    /me goes and checks…

    My records show that you left the group on November 19, 2010, 1:03 UTC

    I’m just of the opinion that a comic has a higher level of impact than anything I’d write in the list would

    Your cartoons definitely have impact. Keep it up. Meanwhile: these are not mutually exclusive options. Based on your tweets, you appear to be tickled by the fact that your cartoons are cited by the proposal. That’s all goodness. I just with that that had been done months ago. It would have saved all of us a lot of effort.

    Oh, and cynicism has a place. If I were inclined to draw cartoons, I would be focusing on different things. After literally years of asking for use cases, we got approximately a dozen words arranged in 7 bullets. Evaluating the evidence that was actually put forward, the strongest objection to the inclusion of a longdesc attribute was found to be the lack of use cases. And we indicates that we would reopen the issue if such were provided.

    A full six months later, and we have our use cases. I’d love for us to be discussing those use cases, addressing the issues that @mattur has brought up, and the alternative that @manusporny has brought up.

    Instead, we are discussing the refusal of the chairs to require that the working group absorb, respond, and produce concrete counter proposals to this new information all in a matter of 4 weeks, and at the same time requiring everybody to proceed with the existing full workload.

    I’ll give you a second to ponder the irony of that in the context of your original post.

    Rest assured that there will be a continual stream of heartbeat documents and forward progress. In the case of longdesc, it is not to late for HTML5, not by a long shot.

  18. Instead, we are discussing the refusal of the chairs to require that the working group absorb, respond, and produce concrete counter proposals to this new information all in a matter of 4 weeks, and at the same time requiring everybody to proceed with the existing full workload.

    …and yet, all other issues that have been on the table (many for months as well) must meet the March 22nd deadline to make it to Last Call.

    I’ll give you a second to ponder the irony of that too.

    What is unclear to many is how a Draft Specification can go to Last Call when it is knowingly not complete – it sounds like you want to move into your new house even if the doors and window have not yet been added. Oxymorons such as First Last Call and Second Last Call simply serve to illustrate how broken the process remains. Having open issues that are contentious and unresolved is not a sign that the specification is mature enough to become a Candidate Recommendation; in fact suggesting otherwise is an act of immaturity: it is nothing more than window dressing and hand-waving.

    I am reminded of a saying I often hear around my work place: you can have High Quality, On Budget and On Time – pick two.

  19. @Marco Ranon:

    Yes, you’ll notice the quote above is an exact quote from the RNIB Surf Right guidelines – which you’ve contributed to. The current HTML5 spec does not recommend using longdesc either, but still requires UA’s to support it as an obsolete feature.

    > “Until user agents provide full device independent support for LONGDESC, we will still recommend that it isn’t the sole means of finding a long description.”

    This was the advice in the previous RNIB See It Right guidelines (2001?) and the advice in WCAG1 (1999), IIRC. One fundamental problem with longdesc is that it is not “robust”, so it requires duplicate functionality to provide accessibility in UA’s which do not support it. Compare aria-describedby.

    > “We believe that a long description may be useful or necessary to a wide range of people with disabilities including low vision, learning difficulties and dyslexia. Currently many browsers only expose LONGDESC to screen readers.”

    Another fundamental problem with longdesc: it is apparently essential that longdesc is invisible to sighted people (see Laura’s CP) and, at the same time, it is apparently essential that longdesc is visible to sighted people who may need it too (i.e. it must be “perceivable” to all). IMHO that aim is, what I’ll politely term, ambitious.

    One solution to this problem would be to take longdesc’s existing (-ish) functionality:

    <a href=”longdescription.html” target=”_blank” style=”cursor:default”><img src=”a.gif” alt=”Press enter for long description”></a>

    …and then remove all the longdesc functionality:

    <a href=”longdescription.html”><img src=”a.gif” alt=”*the purpose of the link*”></a>

  20. I’m not going to write out a long argument but simply give an oppinion (as i think this has been going round and round on the list). Just put the damn attribute back into the spec. Otherwise, go poke your own eyes out .

  21. Jeffrey D. Stark:

    Read the spec http://www.w3.org/TR/html5/obsolete.html#dom-img-longdesc

  22. mattur: 1 word: insufficient

  23. It seems like a waste of time to argue logic or merit when an issue has become “political” – like this one appears to have become.

    The large majority of the leading authorities on accessibility feel strongly that the attribute is important, it would seem to me that this issue should not have been overlooked or left to a later stage in the process.

    We have missed a major opportunity to improve the implementation of the longdesc attribute in user agents and what is being done as action items to address the future of the attribute at present is insufficient.

  24. > “The large majority of the leading authorities on accessibility feel strongly that the attribute is important…”

    No.

    Leading authorities on web accessibility and the HTML A11y-TF all agree that longdesc should be obsoleted (there are disagreements over timing):

    W3C WAI-PF:

    RS: I hate longdesc
    JS: I think we agreed to obsolete longdesc
    JS; existing mechanism (longdesc) is a failure, look at why, build from that
    http://www.w3.org/2009/10/16-pf-minutes.html

    W3C WAI-CG:

    “we believe it is acceptable to obsolete longdesc in HTML5. ”
    http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

    HTML A11y-TF

    RESOLUTION: The group does NOT want longdesc to continue indefinitely although there are some objections
    RESOLUTION: We do want aria-describedby to replace longdesc.
    http://www.w3.org/2010/04/06-html-a11y-minutes

    One day, I’d love to have a real, evidence-based discussion about the best way of making complex images accessible to everyone.