Rebuilding The Web

1. Posted by Leif Halvard Silli
on Tuesday 2011-04-19 at 00:30:56 PST

Pretty cool. This must definitely go into Laura's research page.

Ideas:

- let the long description page contain the image, so one can see what it identifies = some kind of "recursive description microformat"
- identify the description as a fragment.

2. Posted by Denis Boudreau
on Tuesday 2011-04-19 at 07:40:35 PST

I have my doubts. First, the example you're providing here, to me, is not a good use of the longdesc attribute as this description could very well be provided through a regular alt attribute. Longdesc is meant and - better suited - to provide description for complex images such organization charts, diagrams, data table of financial results, etc. Golden rule being, if you need to structure the description of your image, using longdesc is probably relevant.

While the idea looks interesting, I really doubt authors would bother describing their images so. If they're too lazy or unable to do it with the actual methods, why would they bother doing so through such a service? And what if the same image is copied and linked to from different servers? The description would have to be copied as well, or maybe reinvented completely each and every time. Flawed.

I can barely imagine a situation where an author would need to link to an already existing and described image, unless it was one of it's own. I can't imagine someone going through as catalog either, hoping to find a description for the image he's planning on using. Seems like going through a lot of trouble, just to avoid writing another document which contains the description of the image, don't you think?

4. Posted by David Malcolm
on Tuesday 2011-04-19 at 08:08:39 PST

Longdesc is ideal for associating transcriptions to video. Although subtitling is a viable alternative, longdesc allows the web user the ability to follow the video script at their own pace and or save it separately. If you have an image on a website which would benefit from a description, in my view it should be part of the page - much like a photo caption in offline material.

5. Posted by Catherine Roy
on Tuesday 2011-04-19 at 08:23:48 PST

I admit I was intrigued by this proposal and appreciate the fact that you are genuinely trying to find a solution but I feel this is displacing the problem.

Perhaps I misunderstand how this will work but it seems to me that you are making the availability of image descriptions entirely dependent of a third party service which, to me anyway, seems risky as that service may not always be available or may simply cease to exist at some point for whatever reasons. Also, the interface you provide to produce longdescs is/may just reproduce what should be part of a good authoring tool already.

While this service *may* "make it easier for content authors to use longdesc right now" (although I fail to see what is so hard about writing and making longdesc available natively, even I can do it), I am not convinced this will "offer a seamless transition path that will replace the longdesc feature with a technology that makes it supremely easy to describe images; and ensure that this feature benefits everyone".

Can you expand on those claims ?

6. Posted by Catherine Roy
on Tuesday 2011-04-19 at 08:31:46 PST

Denis Boudreau wrote :

"Longdesc is meant and - better suited - to provide description for complex images such organization charts, diagrams, data table of financial results, etc."

I must disagree. While longdesc is crucial to these types of images if that information is not available in the page somewhere, descriptions such as the one given in the example of the article are relevant as well and many users appreciate the fact that they are available. We must stop seeing the principal users of longdesc, i.e. the blind, as a homogeneous group who do not care about the appearance of things. It is simply not true and you have such people in your entourage. The beauty of longdesc is that users have a choice to access that info or not.

8. Posted by Robert
on Tuesday 2011-04-19 at 11:46:55 PST

Here is a use case. At my college, staff make web pages but don't use longdesc. Volunteer students who don't have access to CMS can describe images with this method.

9. Posted by Catherine Roy
on Tuesday 2011-04-19 at 12:28:28 PST

Vlad, thanks for the additional info. I still think that writing a longdesc and making it available natively is not hard to do. Your description of the steps to do so now via a CMS only prove that the problem is the CMS, whichever one you were basing your description on, and that it needs to make things easier.

As for the rest of your explanation, it is indeed interesting and it can be useful in certain settings and can make great use of crowdsourcing but it does not address the fact that availability of image descriptions are dependent on the availability of a third party service which remains a risky proposition.

I continue to believe that there is nothing wrong with longdesc per se and there is no need to "replace" it. The problem is that people are ill-informed, not well trained, buy into all the misinformation being spread around and/or just do not care enough to go that extra step.

10. Posted by Jennifer Sutton
on Tuesday 2011-04-19 at 12:44:04 PST

It seems to me that this idea fails to address the issue with longdesc in which it's used in ebooks. This idea only addresses the use case of Web-based documentation for people with an always-on connection. I wouldn't consider this idea anything close to a replacement for longdesc.

11. Posted by mattur
on Tuesday 2011-04-19 at 14:42:22 PST

Should we be encouraging "authors to use longdesc right now" when we know it "is not available to all users", and it is "only supported by a limited number of browsers and assistive technology" [1], and even the systemically dysfunctional WAI PFWG [2] apparently wants to obsolete it in HTML6 anyway?

1. http://dev.w3.org/html5/alt-techniques/#hy
2. http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0181.html

12. Posted by carl t.
on Tuesday 2011-04-19 at 15:00:13 PST

@Jennifer Sutton, I assume the at the time of publication of the ebook, descriptions can be downloaded from this service and saved to local files and referenced by longdesc. I don't think anyone said remove longdesc from psudo web formats such as ebooks.

@Catherine Roy, I'm not totally happy with 3rd party services but it's a fact of life on the web. Can anyone say bit.ly?

14. Posted by mattur
on Tuesday 2011-04-19 at 17:21:34 PST

Vlad: Obviously new techniques are not directly comparable to a technique that has failed for 14 years, since they're, er, NEW and haven't FAILED FOR 14 YEARS yet. Use what works, and degrade gracefully.

Authors should ideally put the long description on the same page, or use a normal link to another page with a larger image and the description. See WebAim, RNIB Surf Right or WCAG2 Techniques if you need to get up to speed on methods for providing long descriptions that actually work "right now".

15. Posted by Catherine Roy
on Tuesday 2011-04-19 at 17:54:01 PST

Vlad wrote : "Catherine, I would like the accessibility community to raise and discuss all potential issues and at the same time suggest solutions to address them."

I already stated I do not feel there is anything wrong with longdesc. If others feel differently, then by all means, they should step up and propose something better.

I am still waiting.

16. Posted by mattur
on Wednesday 2011-04-20 at 05:46:15 PST

Catherine, WAI-PFWG has proposed:

http://www.w3.org/WAI/PF/aria-practices/#Descriptions_external

The HTML-A11Y-TF also proposed aria-describedby should replace longdesc.

It's potentially better because it doesn't lock out users with UAs that don't support it (robust) and because the same technique can be used on anything that needs a longer description (common usage and authoring pattern). It's also not polluted with bad data like existing longdesc usage.

In the meantime it's better to use an in-page description or a normal link. Longdesc is just a highly effective way to lock out people with/without disabilities, which you may have noticed is the opposite of what accessibility is supposed to be about.

18. Posted by John Foliot
on Wednesday 2011-04-20 at 22:36:59 PST

@mattur

STOP SPREADING LIES! For somebody who has contributed exactly *ZERO* to the HTML5 Accessibility Task Force, you have absolutely no idea what is happening within that Task Force. Regurgitating months and even year old data-points simply proves how little you really care about this issue - you simply want that the WHAT WG perspective "wins" some little power-battle, and who cares about the impact on end users.

Your claims:
1) "is not available to all users", and it is "only supported by a limited number of browsers and assistive technology"

The URL referenced by @longdesc is a unique DOM node in the DOM tree, as any DOM inspection tool, in *ANY* browser will confirm. GUI browsers however have for the most part chosen to ignore the needs of the alleged sighted users who would require longer textual descriptions (a point often asserted, but never actually proven). Users choose the tools they used based upon the features afforded them by those tools - if a tool does not satisfy their requirements, they will choose other tools, or modify the tools they have to meet their needs. For sighted users who require what most users would consider redundant information (the value of the @longdesc long description), they can use Opera or iCab, download and install the now years-old Firefox plug-in, or tinker with the Internet Explorer to modify their tools to meet their needs.

If the majority of sighted users and authors truly believe that access to text that most would consider redundant is a crucial feature of their browser then they should be communicating that to the browser vendors, and voting with their feet - if Chrome (for example) refuses to support @longdesc then stop using Chrome - I have. The problem is *NOT* the attribute, it is the disregard and neglect from the GUI browsers. The same holds true for Voiceover and NVDA - it is those tools that have chosen to support or not support a decade's old attribute: regardless of the fate of @longdesc in HTML5, other documents and document formats (HTML 4.01, XHTML1.1, epub) will continue to have @longdesc as a valid and conformant attribute. Place the blame for any current 'issues' squarely where it belongs - the user-agents.

Finally, as for what the Task Force is actually advocating for, I will point you to the current proposed Draft Text, which will be part of the Final Change Proposal submitted to the Working Group: http://www.html5accessibility.com/tests/img-longdesc.html#long.

2) "even the systemically dysfunctional WAI PFWG [2] apparently wants to obsolete it in HTML6" (with a link to an email written by Sam Ruby, who is NOT a member of WAI-PFWG) - but hey, let's not let facts get in the way of a good lie.

Sam was not on the call from which those minutes emerged, however I was (go ahead, check the minutes, I wrote them). Sam's assumption was wrong, a point that was immediately corrected by Laura Carlson:

"> The general thrust I gather from these minutes is "we need more time to
> properly deprecate longdesc". If that indeed is the case

It is not the case. I guess you didn't read the last part of my
message."
http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0182.html

(Cont.)

19. Posted by John Foliot
on Wednesday 2011-04-20 at 22:37:34 PST

As a member of the newest sub-group within the Accessibility Task Force (from which those minutes emerged), I can state unequivocally that the raison d'etre; of that group (identified as [text] for want of a better name) is to ensure that emergent Change Proposals and Formal Objections for the reinstatement of @longdesc, @summary, (and now likely addressing the mess that the recent @alt decisions have wrought) are carefully and robustly set out, based on consultation and internal consensus - in short, bullet-proof responses.

Matthew Turvey (@mattur) can continue to try and assert that WebAIM, IBM, RNIB and Ian Hickson's mother all tell authors to avoid @longdesc like the plague, but those assertions have been addressed and disproven so many times I tire of repeating them here.

Suffice to say, Matt continues to troll the web, looking for an opportunity to continue to spread LIES and FUD wherever he can, because, well, he simply believes that he knows better. Believe him, of believe the multiple active members of the Accessibility Task Force quoted above: Laura Carlson, Steven Faulkner, Gregory Rosmaita, and myself.

20. Posted by John Foliot
on Wednesday 2011-04-20 at 22:38:31 PST

@vlad
"HTML-A11Y-TF pushes to use ARIA in places where it does not fit. They refuse to acknowledge and discuss the shortcomings with using ARIA to replace longdesc (and alt for that matter)."

This is not exactly true. Early into the @longdesc discussions (2009), there was a general thought that *IF* a number of identified short-comings to aria-describedby could be resolved *THEN* an evolution that saw @longdesc fade away (deprecation) could be entertained. Deprecation, not instant obsolescence!

There is a powerful aspect to having ARIA contain a function that replicates what @longdesc does, as ARIA is author-language agnostic, and so we could re-use this function in all authoring languages (think SVG for example) - authors could re-use these same attributes/functions in multiple languages rather than having to re-learn accessible techniques for each new language that content creators choose to use. I honestly believe that looking to improve ARIA (including, perhaps crafting a robust replacement for @longdesc) is a worthwhile endeavor, and early, tentative discussion on this has actually already started. I encourage you and anyone else reading this to participate in those discussions, so that collectively we can get the best solution we can work out.

However, this effort should not be rushed, or expected to instantly replace @longdesc, but rather work in concert with existing solutions. Evolution, not revolution!

One key aspect, and a point previously noted by @catroy earlier on this thread, is the end user option of consuming or not consuming of the longer description. I have often likened it to the difference between glancing at an image (@alt) and studying an image (@longdesc); and the absolute requirement that the second category remain a user-choice, and not a 'force-fed' data consumption. I can confirm to you that all of the active members of both PFWG and the a11yTF are in agreement and understanding of this key distinction, which is why they are actively working toward having @longdesc re-instated into HTML5.

Regarding the shortcomings you pointed out, the a11yTF and PFWG are already aware of them (and more), and in fact they are documented both in Laura Carlson's work, as well as PFWG's.

22. Posted by mattur
on Thursday 2011-04-21 at 09:28:11 PST

John Foliot:

> STOP SPREADING LIES!
> Your claims:
> 1) "is not available to all users", and it is "only supported by a limited number of browsers and assistive technology"

Er... those are direct quotes from Steve Faulkner's "HTML5: Techniques for providing useful text alternatives" document. Take it up him with him if you think he's spreading lies, but I'm inclined to think he isn't, because he's a proper accessibility expert and not a blithering idiot.

23. Posted by mattur
on Thursday 2011-04-21 at 18:40:28 PST

John Foliot:

> 2) "even the systemically dysfunctional WAI PFWG [2] apparently wants to obsolete it in HTML6" (with a link to an email written by Sam Ruby, who is NOT a member of WAI-PFWG) - but hey, let's not let facts get in the way of a good lie.

Sam's email, *referring* to some PFWG members *apparently* discussing obsoleting longdesc:

"The general thrust I gather from these minutes is "we need more time to properly deprecate longdesc"."
http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0181.html

Laura did indeed reply to his email, missing the point entirely like you just did, and Sam was kind enough to clarify for her:
http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0183.html

24. Posted by John Foliot
on Thursday 2011-04-21 at 22:29:56 PST

@vlad,

I think you are missing an important point. I am in total agreement that today ARIA does not have a function that replicates @longdesc, and none of the current ARIA options can replace @longdesc's functionality. HOWEVER, having identified those short-comings, we can certainly look to add that functionality to the ARIA suite, allowing authors of other web-related languages to now have that functionality as well. We cannot remain stuck in time, we need to be forward thinking as well. *IF* we can develop a solution that meets the requirements that PFWG worked on (requirements currently met by @longdesc), then those new solutions can work in concert with existing solutions as we see a forward evolution.

As for your personal interpretation of how and what @alt is for, you are entitled to your opinion, but the overwhelming majority of those involved in the W3C web accessibility effort don't see it your way.

HTML 4.01 defines alt this way:

"For user agents that cannot display images, forms, or applets, this attribute specifies alternate text. The language of the alternate text is specified by the lang attribute.

Several non-textual elements (IMG, AREA, APPLET, and INPUT) let authors specify alternate text to serve as content when the element cannot be rendered normally. Specifying alternate text assists users without graphic display terminals, users whose browsers don't support forms, visually impaired users, those who use speech synthesizers, those who have configured their graphical user agents not to display images, etc."

HTML5 defines alt:
"...the value must be an appropriate replacement for the image...in general, alternative text can be written by considering what one would have written had one not been able to include the image."

WCAG 2.0 defines alternative text here:
"1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose (except under certain defined circumstances)."

Equivalent purpose - not "a way to make surrounding content comprehensible". If you believe that this is incorrect then the way to change it is to work within the W3C and seek consensus that it needs to be re-defined. This is how it works, not arguing that everybody else is wrong on your blog, no matter how sincere you are (something I do respect) or convinced you are right. You are just not going to affect change that way.

26. Posted by John Foliot
on Friday 2011-04-22 at 22:48:46 PST

OK Vlad, go for it.

Make all of the browsers do exactly what you tell them to do - I am sure they are waiting for your call as we speak. Translate your guidelines and rules into all of the languages that they need to be translated into, from French to Russian to Chinese, Spanish, Norwegian, Portuguese, Korean, Italian.... Convince every government on the globe that Vald's way is the better way, big business and academia too while you are at it.

HTML5 is not complete, and yes, right now there remain problems. A number of smart and hard-working people are working together to try and get things set right. But it is not an autocracy, where somebody named Vlad or Ian gets to write the rules, and everyone bows down to those rules - there is nobody walking down from the mountains with tablets in hand here. There is no King.

Your current frustration is well founded, and you are not alone. I just finished 4 hours of time-consuming volunteer effort fighting to improve the accessibility of video for HTML5, and I know what it takes to effect change, and trust me it is more than writing blog posts and quoting Joe Clark, a well known outsider who burns more bridges than can be built in a lifetime.

But hey, maybe Joe will help you - until one of you disagrees with the other, and then what? We can have Joe rules and/or Vlad rules, and you can both duke it out convincing the browsers that yours is the better way forward, because one of you thought it up, or knows better than the other. Perhaps Mattur will help you with @longdesc... oh wait, he disagrees with @longdesc, so maybe we should all just follow his rules instead - maybe he can get them translated faster than you can, who knows?

You see the problem here? The more voices you have at the table, the more points of view you have, so it's not as simple as saying, do it this way, because it's smarter/better/righter. You need to prove it, and build consensus and support around it, so that *most people* agree with whatever it is you are advocating - and at some point you will never reach unanimity on every data-point, so they might hold a vote and choose to "ignore your objections" (maybe because you are the only one, and you've not managed to convince anyone else, or simply enough people, you are right). That's called democracy, and you know what they say about that - it isn't perfect but it's the best we got.

You can't do it alone, and you are delusional if you think they are all going to come to you seeking the way forward. If you want to effect change, you need to go where the action is happening, you can't sit there and expect it to come to you.

But Good Luck trying.

28. Posted by John Foliot
on Sunday 2011-04-24 at 01:20:05 PST

Vlad,

You really do need to do a better job on your history, you have this so wrong on so many levels.

I believe you tried to do this a few years back when you wanted Ian removed. Ian then banished you from the mailing list for 2 weeks.

At the W3C, Ian is the editor. The End. The effort behind HTML5 at the W3C is overseen by the 3 current Chairs: Sam Ruby (IBM), Paul Cotton (Microsoft), and Maciej Stachowiak (Apple). Prior to that it was chaired by Chris Wilson (Microsoft) and Dan Connolly (W3C). Ian did in fact remove my ability to post to the WHAT WG mailing list for a 2 week period, but since 2007 when the HTML5 effort moved into the W3C, I have not participated at the WHAT WG (deliberately).

By the way, I miss the old John because he put principles before etiquette.

Vlad, you don't know me, you have no idea what I do privately towards improving accessibility on the web, and I can be both outspoken and militant when it is appropriate. But I also understand that sometimes more reasoned discussion actually moves things forward in more productive ways, a point you seem to be missing. If all you do is argue and scream at everyone, you end up like Joe Clark - ousted from working groups as being overly disruptive. (And you can do your own research on that Vlad - try looking at WCAG and the PDF standards groups)

Is that what the browser vendors did? Did they say W3C is the place to create standards so we will work within W3C to create HTML5? No. They started WHAT WG in order to give the finger to W3C. And after having forced W3C into working on HTML5, they still continue to work within WHAT WG in order to exert influence over W3C.

In 2004, at the annual W3C plenary (TPAC) a number of representatives expressed concern that the work on XHTML2 was not going to be backward compatible, and that the W3C focus on a document centric semantic specification (XHMTL2) did not match what their users were asking of them (web applications). Despite trying to make their case, they were unable to change the prevailing thought of the day; they subsequently decided to work on these efforts none-the-less. So it was the W3C that actually drove the creation of WHAT WG. After 3 years of working on that effort, Tim Berners-Lee realized as well that the vision that this group was working on was also what the general population was more interested in, and after convening a face-to-face meeting, the sponsors of the WHAT WG effort (Opera, Mozilla and Apple) agreed that the best thing for the overall health of the web was to bring the HTML5 effort back inside of the W3C, given that the W3C represented a number of other invested members, including governments, non-web focused businesses and academia. They agreed, and in 2007 the W3C Chartered work on HTML5.

By the way, that's another characteristic of democracy - equal say in major decisions. But the browser vendors are after all, more equal than others.

Actually Vlad, the corner stone of Democracy is one person, one vote. To get enough votes to advance your agenda (no matter what it might be), you need to engage others and discuss your agenda, and - wait for it - build consensus so that the majority will vote in your direction. That's how politics works.

And I observed how the browser vendors patronize them. How they sap their energy by wasting their time. For example, no one works harder than Laura Carlson and I see how the browser vendors create hoops for her to jump through just to keep her busy.

Again Vlad, this is very skewed point of view. You attempt to paint the browser vendors as some monolithic axis of evil. Having worked directly with members of all the major browser vendor teams, you are so off-base as to be insulting to a group of dedicated and sincere engineers. If you are unhappy with the direction that a browser vendor is moving in, you have a few choices: you can stop using that particular browser (and if enough people did that, the browser would change direction or continue to lose market share), or you can start from either of the two open-source rendering engines (Gecko / web-kit) that drive 3 of the 5 major browsers in the market today (Firefox, Chrome, Safari) and build your own 'better' browser.

AS for Laura's efforts, it is true that she has contributed a lot of time and effort to HTML5, but she is not the only one. If you were active inside of the W3C effort you would also know of the huge contributions made by many others.

Cont.

29. Posted by John Foliot
on Sunday 2011-04-24 at 01:20:51 PST

John, we are on the same side. We want the same end result. But the course you are on is not producing results. The approach I am advocating will generate results and will ultimately give the W3C Accessibility Task Force the powers it needs to make a real change to Web accessibility.

HTML5 is not complete, and there is still a lot of time and work ahead. It is true that there are some current irritants that continue to frustrate the accessibility community, but work on resolving those irritants is ongoing both in the public forum, as well as behind the scenes - you should also investigate the role of the AC Reps within the W3C, and the power that group wields in the larger process.

Working outside of the W3C is not the way - been there, done that. In fact, I was instrumental in the formation of that group (html4all), and continue to host that website, mailing list, and pay to register the domain name each year out of my own pocket (if you want to talk about principles...). While that group was a sincere effort, we simply did not have the critical mass to effect change - and nearly every founding member of that group is now actively working inside of the W3C on HTML5.

Vlad, unless you are prepared to accept these realities, there is nothing to debate. I have repeatedly suggested to you that if you want to make change, join the others with the same goal and do the work where it needs to get done. Not at WHAT WG, not at html4all, but at the W3C - it is the only long-term winning strategy that really stands a chance.

31. Posted by John Foliot
on Sunday 2011-04-24 at 10:12:38 PST

Vlad,

If you have not figured out by now that ensuring access for people with disabilities is a political fight as well, then you are even more naive than I thought. The W3C is not some global Internet police force, that lays down the rules for all to follow, they are a standards body. They can no more force commercial companies to do or not do something than you or I. If you want the ability to force something like that, you need the support and influence of governments... and that's politics. Politics like using the court systems to sue companies such as Target.com, Netflix or Penn State university. Politics, like the US DoJ's recent re-opening of the ADA to address a number of new items that have emerged since the signing of the ADA in the 90's - including digitial inclusion (the web). And when it comes to governments being involved in the workings of the web, they all look to, and support financially, the W3C.

At Apple, we consider it important to make our software accessible to a wide range of users. Some of the reasons accessibility is important to us:

(1) We think it's the right thing to do. We want to make computing usable for everyone.
(2) For sales to the federal government, many state and local governments, and many corporations, procurement rules require meeting certain minimum accessibility standards. Section 508 defines a set of standards that apply to the US federal government for instance: <http://en.wikipedia.org/wiki/Section_508_Amendment_to_the_Rehabilitation_Act_of_1973>
(3) Legislation may directly require support for accommodations for the disabled. One example is the Americans with Disabilities Act; case law indicates that a website may be considered a public accommodation for purposes of the ADA.

For almost any large corporation, (2) and (3) will be important considerations, regardless of how they feel about (1). For Apple at least, we seek to do more than the bare minimum. Our goal is to surprise and delight all users, including those with disabilities.

Outside of the fact that Maciej could be a little less 'corporate shill', his main points stand; points 2 & 3 are the only thing that "force" companies to do something. Even then, companies have a choice: they can stand up to governments (twitter in the wikileaks situation, Google in China), although they do so at their own peril, and with subsequent consequences.

You are right, if the W3C tries to dictate terms that the majority of the browser vendors disagree with they will go do their own thing - that has never been otherwise. All the more reason to work *with* those browser vendors, not against them to educate and build consensus so that they prevail with our requirements. Since governments and other large commercial entities are already aligned with the W3C, that is the biggest argument we have to convince the browsers to remain inside of the W3C.

As for producing new accessibility features: even here you have no idea. It has not been perfect or Pollyanna - something that I think you *expect* - but significant and serious progress has been made, and HTML5 is delivering on making many things on the web more accessible. Not all of these features are fully supported today (and some not at all), but the only way to get the browsers to move forward there is give them a reason to do so: either through political government pressure, or via market forces.

This has become a pointless discussion Vlad - you look at things with your own set of rose-colored glasses. You refuse to work inside of a process you none-the-less expect to force change; you ignore certain realities that exist in the world today, including politics and market forces, and your perception and understanding of what the W3C is and how it operates is very flawed and mis-informed. The work they do, the successes they have accomplished and the process and protocols they follow appears to escape you.

It is not about debating with like-minded people, it is about debating with informed people, and in this regard you seem to be very misinformed. I have tried to help you have a better understanding of the process, history and realities of the W3C; instead you want to argue with those facts and continue to 'blame' the browsers for some kind of evil wrong-doing. You don't want a debate, you want to be right - you don't want to examine the facts and consider them, you simply want to dismiss them and find a bogey man to blame because... I really don't know why: maybe because the way forward is making it harder for you to produce your authoring tool?

As I said earlier, good luck with your ideas: for them to gain traction you will still need to build consensus, except now you are trying to do so in an empty room. Be sure to let us know how that works for you.

32. Posted by John Foliot
on Sunday 2011-04-24 at 12:36:50 PST

maciej's quote BTW can be found here: http://lists.w3.org/Archives/Public/public-html/2011Apr/0537.html

34. Posted by John Foliot
on Sunday 2011-04-24 at 17:49:43 PST

Vlad,

If you have a problem with Apple, talk to Apple - don't drag me or the W3C into the process. Better yet, don't use Apple products - I don't - I vote with my wallet.

You want to work with the browsers, but you expect them to come to your blog to have that conversation. You accuse them of being evil and malicious, then wonder why they don't respond to your invitation.

I didn't take my frustration out on you, I made a comment on twitter. You don't want to hear that? Stop following me on twitter - I'll still sleep fine at night.

I'm stopping now Vlad. It's your blog, and you want to be right. OK, your right. Feel better?

35. Posted by Leif H Silli
on Monday 2011-04-25 at 15:53:35 PST

Vlad, you wrote:

«<canvas> is inaccessible and is now part of all shipping browser versions. Any future effort to make <canvas> accessible will be optional and will only make <canvas> semi-accessible.»

It would be interesting to hear your views on the (in)accessibility of <canvas> one day.