Rebuilding The Web

Articles, advocacy, discussion and debate about the many problems of the Web and the challenges of rebuilding it.

Enhancement to and replacement for longdesc

Regardless of your stance on whether longdesc should be part of HTML, I think we can all agree that the ability to textually describe non-textual objects, such as images, is a desirable feature for the Web. So I would like to propose a way to:

  • make it easier for content authors to use longdesc right now
  • 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

Introducing ObjectDescription service

ObjectDescription is a service via website and API that stores and serves image descriptions. To use this service with longdesc, a user enters a URL to a given image, enters a description for the image, and in return gets a URL they can enter into the longdesc attribute. This reduces that number of steps non-technical authors have to go through at the moment, using WYSIWYG editors and CMS.

When using an API, there is no need for authors to use longdesc. The Web browser sends a unique fingerprint (checksum) of the image to ObjectDescription and in return gets a description, as shown in the following screenshot:

Image properties dialog box. Title and Description fields show a description for an imge. These fields are read-only. An Edit button is below these fields.

The image description can be authored right in the browser:

The same 'Image properties' dialog box as above. The Title and Description fields are enabled and the Edit button is replaced by a Save button.

Through ObjectDescription, anyone can write/edit a description for any image on the Web, and website creators can of course put limits on how browsers use this feature on their Web site.

Best of all, this is a general-purpose application of image descriptions that will benefit everyone. Image descriptions are treated as standalone documents. This means they can be processed by machines such as search engines, and can be included in regular search results. This can increase the amount of searchable data on the Web and yield more relevant search results. In addition, image descriptions can make image searching a lot more efficient.

ObjectDescription is live

This service is up and running at objectdescription.org. Be sure to read the FAQs on the site. Please let me know your thoughts, feature requests and general feedback.

Public comments

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?

3. Posted by Vlad Alexander
on Tuesday 2011-04-19 at 07:56:11 PST

Denis Boudreau wrote: "is not a good use of the longdesc attribute as this description could very well be provided through a regular alt attribute."

Why? What if alt reads "Sidalcea hendersonii"? Or say "Awesome shade of pink" as in this usage:

I generally like blue flowers, but check out the color in this photo:

Awesome shade of pink

Denis Boudreau wrote: "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."

The description is attached to the image through a digital fingerprint of that image. You only need to describe the image once and the description would follow it regardless of the website it is used on.

Denis Boudreau wrote: "I can't imagine someone going through as catalog either, hoping to find a description for the image he's planning on using."

The descriptions can show up in regular search results in say Google. In addition, image search can be based on the actual description of an image rather than file name or alt or image dimensions.

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.

7. Posted by Vlad Alexander
on Tuesday 2011-04-19 at 09:39:29 PST

Catherine Roy wrote: "although I fail to see what is so hard about writing and making longdesc available natively, even I can do it"

Lets walk through the steps required for a user to do this using a WYSIWYG editor and CMS. Let's say John want to write an article.

  • He clicks on the New Document button in the CMS, writes some content, inserts an image and at this point he want to enter a description of the image.
  • So he has to close the image properties dialog box, save the document.
  • Click on New Document button, compose a description of the image, save the document. In some CMS where there is workflow, he would have to publish the document to make it live.
  • Copy the URL to this document if available through CMS (some CMS auto-generate the URL so he would have to go to the Web site to get the URL).
  • Then he would find the original document, open it, open the image properties dialog box and enter the URL to the new document in the Long Description field.

Catherine Roy wrote: "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'.

A unique image fingerprint identifies image descriptions stored with ObjectDescription. For example, a user using longdesc feature is given a URL to use such as:

  1. http://objdesc.org/?H5O4

Behind the scenes, ObjectDescription stores a unique fingerprint and description for the image like this:

  1. c5df419aaaa4a00416c73aaf386f5aa7 = Yellow butterfly with blue spots ....

Now lets say Mary wants to use the same image on her website but does not use longdesc. The browser can send the fingerprint of the image to ObjectDescription API and get the description for the image. So the transition away from longdesc is seamless.

But the real power of ObjectDescription is that anyone can write a description for any image on the Web. Here is one use-case. Jack published an article on his website that contains an image. Jack could not be bothered with image descriptions. Sue reads the article and wants to forward this to her friend who has limited vision and needs an image description. In the browser, Sue selects image properties for the image:

Image properies dialog box. Description reads 'None' but there is a link to 'Write a description'.

She writes a description and saves it:

Image properties dialog box with fields to write a Title and Description.

Sue then send a link to the article to her friend to read. Her friend is then able to access the image description from the browser:

Image proprties dialog box with title and description for an image.

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?

13. Posted by Vlad Alexander
on Tuesday 2011-04-19 at 15:26:35 PST

Catherine Roy wrote "... 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"

Let's come up with a solution to this issue. One possible solution would be to put the domains (objectdescription.org and objdesc.org) in escrow. If the service terminates, the domains would be turned over to organization X that can then find a vendor to continue the service.

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

mattur wrote: "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'"

Using that argument, we should not be encouraging users to use HTML5 features because of limited browser/authoring tool support.

mattur, do you believe that there needs to be a method to textually describe non-textual objects such as images? If so, how would you do this?

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.

17. Posted by Vlad Alexander
on Wednesday 2011-04-20 at 14:40:40 PST

mattur wrote: "The HTML-A11Y-TF also proposed aria-describedby should replace longdesc."

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). Some shortcomings are:

  • It can only point to an image description within the same document.
  • Even though it can point to structured content such as bulleted lists or tables, aria-describedby can only process structured content as plain text. This is because the accessibility APIs that aria-describedby maps to do not support structured content.
  • Authoring tool vendors are likely to find it difficult (or even impossible) to build user-friendly interfaces that use the aria-describedby feature. This is likely to result in confusion and little use of the feature.
  • There is potential for duplicating content for some users because the content is read in place of the image and then again elsewhere in the document.

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.

21. Posted by Vlad Alexander
on Thursday 2011-04-21 at 07:32:46 PST

John Foliot wrote: "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"

A technology that tires to fit everywhere ends up fitting nowhere.

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

@alt/@longdesc cannot work "in concert with existing solutions" because:

  • it makes existing solutions optional
  • complex for users and implementers - this is why we have a 45-page document on how to write alternate text
  • ARIA does not provide equivalent functionality to @alt/@longdesc - all @aria-labelledby and @aria-describedby do is point to content elsewhere in the same document

John Foliot wrote: "I have often likened it to the difference between glancing at an image (@alt) and studying an image (@longdesc)"

I think this is a major part of the problem. The members of the task force still see @alt as a short description of an image and @longdesc as a long description. This is not useful view of these features. If you begin to see @alt as a way to make surrounding content comprehensible when an image cannot be seen and @longdesc as simply a description of an image, then it become clear that ARIA features cannot work in concert with or replace @alt/@longdesc.

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.

25. Posted by Vlad Alexander
on Friday 2011-04-22 at 08:09:23 PST

John Foliot wrote: "Equivalent purpose - not 'a way to make surrounding content comprehensible'."

The spec tells you what the end result should be: an "equivalent purpose". The spec does not tell you how to achieve "equivalent purpose", which can only be done by writing alternate text in context (to fit surrounding content). I believe John Foliot once said, "appropriate alt text must be taken in context" yet this phrase cannot be found in any spec.

John Foliot wrote: "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..."

Let me quote Joe Clark: "There *is* no W3C 'consensus' process. They can simply take a vote to ignore your objections."

John, was it through consensus that @longdesc was removed from the spec? Was it through consensus that @alt was made optional? Was it through consensus that the inaccessible <canvas> feature was added to the spec?

There is no actual consensus. The browser vendors are making HTML less accessible. Through your participation in the process, you are making it appear that the accessibility community condones what the browser vendors are doing.

John, we have tried it your way and I don't see any results. Let's try it my way to make HTML more accessible?

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.

27. Posted by Vlad Alexander
on Saturday 2011-04-23 at 08:05:36 PST

John Foliot wrote: "That's called democracy..."

Having a vote is not a democracy. They had voting in the old Soviet Union but you wouldn't call that a democracy. The only true test of democracy is when the people can peacefully remove existing leadership. 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. By the way, I miss the old John because he put principles before etiquette.

John Foliot wrote: "If you want to effect change, you need to go where the action is happening..."

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.

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.

John Foliot wrote: "A number of smart and hard-working people are working together to try and get things set right."

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.

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.

At the very least, why don't you and I have a debate on the best course of action to make the Web more accessible and let the accessibility community have their say?

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.

30. Posted by Vlad Alexander
on Sunday 2011-04-24 at 07:44:05 PST

John Foliot wrote: "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"

This is not what the browser vendors did. They could not get what they wanted at W3C through one member/one vote, so they started WHAT WG to exert undue influence on W3C. Ian said that WHAT WG serves the role of "an established 'escape hatch' in the hopefully unlikely event of a failure in the W3C's HTML working group". In other words, if W3C does not do what browser vendors want it to do, they walk. Is this what you call democracy John?

John Foliot wrote: "... and - wait for it - build consensus so that the majority will vote in your direction. That's how politics works."

Thanks John for turning accessibility into politics.

John Foliot wrote: "HTML5 is not complete, and there is still a lot of time and work ahead."

HTML is a living standard and it will never be complete. You are playing accessibility catch-up thinking that at some future time accessibility can be added or a feature can be fixed. As soon as a feature appears in the living standard, browser vendors are encouraged to implement it. <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.

John Foliot wrote: "Working outside of the W3C is not the way"

I never suggested that. I want the Accessibility Task Force within W3C to have teeth. You seem to be content to be toothless.

John, normally I would not care what you do. But Web accessibility affects everyone on the Web. Not only are your efforts not producing any new accessibility features, existing accessibility features are being removed. Wake up John!

John Foliot wrote: "Vlad, unless you are prepared to accept these realities, there is nothing to debate."

What? You only debate with like-minded people?

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

33. Posted by Vlad Alexander
on Sunday 2011-04-24 at 14:51:29 PST

Is this the same company that does not have a keyboard shortcut to bring up the context menu in their operating system? Or even something more basic such as a setting to change DPI to increase text size?

Is this the same company that produces a browser that cannot render alternate text? Or even have a way to turn off image rendering?

Is this the same company to which I have repeatedly, since 2005, reported accessibility bugs with plug-ins? I used both Radar (their internal bug reporting system) and email, and was consistently told to talk to the hand?

And is this the same company that I worked for, as a 'vendor' (consultant), building their first online Apple Store, and who reprimanded me for questioning their decision to generate inaccessible PDF receipts instead of HTML?

John Foliot wrote on Twitter: "well, there goes another 4 hours to the W3C, with nothing to show but frustration."

Don't take your frustration out on me. Just like you, I want to work with the browser vendors and I have said so numerous times on this blog. But under current conditions, such co-operation cannot bear fruit. I hope there will come a time when you are receptive to an alternative that is causing you so much frustration.

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.

36. Posted by Vlad Alexander
on Monday 2011-04-25 at 16:33:13 PST

Hi Leif,

I think it is important to understand the role <canvas> will play in future Web apps and why current efforts to make <canvas> accessible will be inadequate.

We are starting to see entire applications being built using <canvas>, including all interactive UI such as dialog boxes. So ARIA cannot be used to make these kinds of apps accessible. Efforts to make <canvas> somewhat accessible by drawing boxes around interactive areas is also not practical for such applications because there is so much interactive UI.

Another type of applications what will come down the road will use <canvas> to draw UI and capture keyboard/mouse movements for apps running on the server. This is similar to X Window System, Remote Desktop Services, Citrix, etc. Just to get an idea of what is coming, have a look at the Amiga Workbench Emulator app. Even though this app is purely client-side, you can see how this can be converted into an X Window/Remote Desktop/Citrix type environment.

I think it is not that hard to see that the future Web will be far less accessible that today's.

Comments are closed for this article.

Main menu

Check out the a11y bugs project that aims to help browser / tool vendors fix accessibility bugs.