The @longdesc “discussion” just won’t go away. As HTML5 looms closer and closer towards becoming a Last Call document at the W3C, there is a full-court press to ensure that @longdesc remains in the specification. Meanwhile, there have been a rash of blog posts over the past few weeks that have also emerged, and if you are in any way interested in HTML5 development and/or accessibility you likely know how hot it is in this current kitchen.
Over on the W3C mailing list, Tantek Çelik said something that I wanted to drill into a bit further:
In the case of “longdesc” – the content rot scenario is that a web author changes the image (src) to point to something else, but forgets to update the longdesc to point to a new description because it is hidden metadata and isn’t apparent as being “wrong” when the author refreshes the page in their browser to check it.
The longdesc URL itself may still be fully functional (i.e. no *link* rot may have actually occurred).
The result is a new image, with a long description that no longer applies to it. Doesn’t matter for most users, and those that attempt to access the longdesc get inaccurate information.
This got me thinking about how most people author web content today; certainly if you write your code in TextWrangler or Notepad (or like me, clings to Homesite 5.5 despite Adobe no longer supporting it) then perhaps this argument might hold some credence. But honestly, how many web authors today write their code by hand? Certainly high-functioning developers such as Tantek likely still do, but “out there”, the rank and file have long since moved to WYSIWYG tools, from stand-alone applications like Dreamweaver, to embedded editors in CMSes such as Drupal (which I deal with at work), or (like this blog) WordPress.
So I thought I would investigate Tantek’s assertion with regard to WYSIWYG editing tools, complete with screen captures. While this is by no means a complete list, it does cover environments and situations that I personally encounter almost daily, and is, if nothing else, a good representative sampling.
Whether adding an image for the first time, or editing and replacing “image A” with “image B”, Dreamweaver’s Accessibility Attributes dialog box prompt’s for both alt text as well as the location of the longdesc file. Visual indications such as pre-populating the input field with the
http:// protocol, as well as offering an “browse for the file” icon (a file folder) all but ensure that authors both understand that this is not a location for writing an actual text description, as well as facilitates locating the longdesc file. With regard to Tantek’s assertion that authors might miss updating a long description when updating an image, the dialog box makes it pretty hard to *not* at least think about the issue. Like in all things author related, we can’t hold a gun to their head, but Dreamweaver makes it pretty hard to ignore adding and updating longdesc content when the image requires it.
Score one for the WYSIWYG’s
I’m becoming fairly familiar with CKEditor lately, as I am working with a team on campus to integrate it into our instance of Drupal (my division’s web authoring platform). CKEditor is an extremely accessible WYSIWYG tool, and Richard Schwerdtfeger (CTO for Accessibility at IBM) confirmed recently that IBM provided some support and feedback to the CKEditor team to ensure it met accessibility requirements: IBM is now using CKEditor extensively in many of their web-based tools.
With CKEditor, when replacing “image A” with “image B”, you literally remove the initial image, and then via the dialog box add a new image, at which point all of the tabs are once again presented to the author. Activating the dialog box on an existing image (to perhaps make an adjustment to the alt text) preserves all of the current other associated attributes, including the link to the long description file. In other words, if you change an image, you start from the beginning, if you change attributes of a current image, all other attributes remain fixed at their current values.
Since the “Long Description URL” input is under the Advanced tab (rather than on the “Main” tab) I guess there is a chance that some authors might miss out, but given the other common attributes that are edited from the Advanced tab, I would suspect that likelihood is fairly small.
While I can’t give full marks, score another one for the WYSIWYGs.
The ability to add @longdesc clearly indicates that it is requiring a “link” although again, like CKEditor, there is no “browse to locate” the html file containing the longer description. TinyMCE functions very similar to CKEditor, preserving settings when any individual attribute is edited, but completely removing all data if/when you choose to update the actual image, in direct contrast to the assertion that updating an image results in a long description that no longer applies to it.
There are a number of other embeddable WYSIWYG editors out there that provide support for the @longdesc attribute (such as XStandard, screen capture shown here)
Despite this minor point however, it seems that the embeddable WYSIWYG editors are doing a good job of managing the accuracy of the long description files.
Unlike the other WYSIWYG editors I reviewed, this plugin leverages the fact that WordPress, like virtually all CMSes today, writes content directly to a database, and uses those entries plus some common templates to create ‘pages’ on the fly. The plugin prompts authors to add a Description as part of the image insertion process, but then takes the description and creates a separate ‘page entry’ that can be referenced as a longdesc file. It generates the following code directly in the editor:
<img src="http://john.foliot.ca/wp-content/uploads/2011/05/wordpress.png" alt="[Screen Capture: the WordPress image dialog box]" longdesc="http://john.foliot.ca?longdesc=421&referrer=371" width="400" height="310" class="alignright size-full wp-image-421" /> <a id="longdesc-return-421"></a>
Since the description data is just another database entry associated with the image, it is always directly associated to that particular image. Another advantage is that the image (and related data fields) are now part of the CMS’ ‘Gallery’ – should an author choose to reuse this image on another page, all of the associated date remains with it as well, an important Use Case previously identified (for example the Logo).
Of all of the testing I have done, this is perhaps the most intelligent and useful solution I’ve encountered to overcoming the initial assertion that
…a web author changes the image (src) to point to something else, but forgets to update the longdesc to point to a new description…, since the long description is directly and visually linked to the image at the authoring stage – authors have to specifically ignore the description in the image dialog box to break the association noted above.
There is no doubt that in the early history of longdesc on the web, when authors wrote HTML in vanilla text editors, the chance that they would miss updating long description text when updating images was a real potential problem. However in the decade or so since the introduction of longdesc (in HTML 4.0), WYSIWYG editors have looked at this problem, and developed solutions to address it. While some developers will continue to hand-craft their HTML the “old fashioned way”, moving forward more efficient and intelligent authoring solutions can and will provide authors with the tools they need to do their jobs correctly, and preserving accurate long descriptions, even today, is one of those problems that has workable solutions. Suggesting that longdesc is flawed because the possibility that
The result is a new image, with a long description that no longer applies to it however does not stand up to scrutiny. It’s a problem already solved.