Author Skill Sets

Use Cases Demonstrate People of Limited Skill Set Use longdesc

The primary actors in use cases 1, 2, 5, 6, 7, 8, 9b, and 10 are not skilled developers but content authors, namely a:

These use cases demonstrate that people of limited skill set use HTML's longdesc. It offers a solution for run of the mill content authors/web designers whereas other solutions do not. Obsoleting longdesc would strip a useful mechanism from authors of limited skill set who are using it to improve accessibility.

Need for Simplicity

Complexity confuses and leads to errors. This is especially true when complexity is imposed directly on run of the mill content authors/web designers. longdesc is simple. As Kyle Weems illuminated,

are we going to pretend that using longdesc is difficult? Yes, people may use it wrong without some correction, but simply saying "Hey, put a URL there," is not complex at all

The Association of American Publishers (AAP) concurs. In regard to their production processes and quality assurance the AAP has provided first-hand testimony to the working group stating,

The longdesc attribute is easy to code.

As a rule, the more complex the markup pattern, the more likely authors are to make mistakes when implementing it. We should strive to find the simplest markup pattern that satisfies requirements.

Need for Support Tools

Without WYSIWYG authoring tools run of the mill content authors/web designers authors would be disenfranchised. They rely on tools to author and test long descriptions.

It has been well established that numerous WYSIWYG web designer authoring tools support longdesc. An array of tools exist to author longdesc and to check that the longdesc works.

Authors rely on tools to test long descriptions. Two browsers (Opera, iCab) natively support longdesc link testing (three if we count Home Page Reader which is currently still in use in Japan). longdesc has a growing arsenal of extensions, configurations, and plugins that are used for testing including Jim Thatcher's powerful long description favelet, which provides universal functionality of longdesc in browsers such as Chrome, FireFox, Internet Explorer, and Safari.

No tools for other solutions such as aria-describedby/hidden exist to allow authors to create and test long descriptions.

Indeed, authoring tool vendor Vlad Alexander has provided first-hand testimony stating,

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.

He confirmed on July 5, 2011 that,

As an authoring tool vendor, we will not be supporting ARIA for content in XStandard, and I cannot see that many other tool vendors will support it either. Implementing ARIA for content does not make business sense for authoring tool vendors, because the non-technical content authors who buy our tools will find it far too complex to use, and because using ARIA for content does not produce better results than existing accessibility features.

Need for Educational Material

A longdesc support base exists in the form of authoring documentation, tutorials, books etc.

No evidence exists that substantial ARIA documentation or tutorials are in place and ready to educate developers. In fact, on June 18, 2011 Paul Irish said,

Most developers have no idea how to implement ARIA. The W3C Primer that looks like a spec is just.. laughable.. not at all appropriate for a web developer audience.

This situation has not changed. On June 1, 2012 Paul Irish repeated that statement,

Most developers have no idea how to implement ARIA. The W3C Primer that looks like a spec is not at all appropriate for a web developer audience.

In contrast a longdesc support base already exists in the form of authoring tools, tutorials, books etc. These longdesc support materials will live on.

Training Budgets Limitations

In today's economic climate new training for run of the mill content authors/web designers is seldom an option leaving these workers with existing skill sets.

Training budgets for organizations such as libraries have been slashed, for instance,

In today's economic climate new training for run of the mill content authors/web designers is seldom an option leaving these workers with existing skill sets.

Different Techniques Require Different Skills

Pitting ARIA and longdesc against each other is counter-productive to accessibility. It should not be an either/or situation.

ARIA

A different skill set exists between JavaScript library/app developers and the run of the mill content authors/web designers e.g. advanced skill set versus basic skill set. One group may learn ARIA to develop "Accessible Rich Internet Applications" the other will use basic HTML to put up a web page or a web site.

As Cliff Tyllick has said, it is unlikely that many content creators or web designers will learn ARIA (something not native HTML). They already feel like they've learned far more than they should have to know under their job description. And in many cases, their supervisors agree. Cliff goes on to say,

And the use case for needing this to be inherent to HTML5 is simply this: Many people who put content on the Web have training in nothing more than html. If you call any technique by a different name - whether it's Java, AJAX, or ARIA - they will not learn it. So if the means for attaching this information to an image is not within html, they won't use it.

Content creators/basic authors should not be forced to read another large spec besides HTML5 to make content accessible. These authors may know basic HTML and be willing to put in longdesc for complex images but most are not going to delve into other specs. ARIA is not an option for them. If content is to be made accessible by both groups of authors we need both mechanisms.

It is recommend [Freedom Scientific 2012 (doc file)] that Web page authors,

read the ARIA best practices guide carefully before adding ARIA markup to their pages.

Most basic content authors are not going to learn two languages to make images accessible. When accessibility is not relegated to a separate spec but integrated into the host language, it is viewed as a mainstay rather than as an afterthought or add-on. Educators have a hard enough time teaching HTML, and an even harder time teaching the need for accessibility (and the means to address those needs). Pile on yet another layer and the difficulties will increase exponentially.

ARIA is powerful technology. If HTML5 forces ARIA upon basic content authors in order to make content accessible, what these authors will end up doing with it is unknown. Encouraging people who don't intend to learn ARIA thoroughly to dabble in it could have unintended consequences. For instance, make a counter a live region - disaster - but it seems logical. Mark a section of your page as an "application" because to you it is an application - seems great. But if you don't handle every keyboard command - it's another disaster.

Two types of authors are recognized, differentiated, and provided for separately by other standard organizations. For example, in 508-255 Refresh (ANPRM) the Access Board provides Chapter 5 for document authors and Chapter 4 for app developers. They state,

Advisory 501.1 Scope. The provisions of this chapter apply to electronic documents, which are mostly static, read-only, non-interactive electronic content. Examples include Word files, PDFs, PowerPoint presentations, Excel spreadsheets, and simple web pages (which do not contain Flash). However, electronic documents may also contain interactive content, such as hypertext links, buttons, and form elements or fields. All of these elements are covered in this chapter. Electronic content covered by this chapter includes most non-paper documents and web content, regardless of format.

This chapter is oriented towards document authors, rather than developers.

Provisions relevant to more robust user interaction, including scripting, are found in Chapter 4 (Platforms, Applications, and Interactive Content). Additional requirements for audio and video content are found in Chapter 6 (Synchronized Media Content and Players).

Both advanced developers and the run of the mill content authors/web designers deserve to have suitable tools at their disposal for providing long descriptions. Both need to be provided for. Anything else is a false choice. It would be discriminatory if only ARIA skilled developers are able to publish an accessible image on the Web.

ARIA Adds Needless Complexity

As Christian Heilmann stated,

If you dive into ARIA you will realise very quickly that it is a lot of work, hard to understand concepts and above all a lot of code to write. Instead of having accessibility as an integral part of HTML5, we have to deal with two parallel standards. One to achieve things quickly and move the web from documents to applications and another one to keep it available for everyone out there. This is not a good place to be in. Accessibility happens when you embrace it from the very start.

The fact is that it is far more complicated for ordinary authors and designers to author hidden relationships than provide a simple link via a longdesc attribute.

No one would want redundant text on-screen, as it would state what is visually evident. So to use aria-describedby, a person would have to write the content, then hide it, and then reference the hidden text with aria-describedby using hidden relationships. That's so burdensome that surely even the most enthusiastic ARIA supporter should realize that the longdesc attribute is far more efficient.

Vlad Alexander thoroughly explains in the article Is ARIA for content doomed to failure? how the aria-describedby technique is far too complex. The capacity for author error is great. Likely errors include but are not limited to:

The potential for confusion is rife especially for ordinary content authors and designers and the result is that accessibility will suffer. In fact even ARIA experts have gotten ID naming wrong and publish incorrect ID examples in the W3C WAI-ARIA 1.0 Authoring Practices specification.

The aria-describedby/hidden technique is complex. Longdesc is easier to understand and put into practice. No evidence has been presented that authors will get aria-describedby correct more often than longdesc.

Cascading Style Sheets

Requiring authors to use CSS to hide the indicator when longdesc already does this natively, not only adds needless complexity, page weight, and inconsistency, it also is error prone and disenfranchises authors of limited skill set.

The Association of American Publishers (AAP) has attested that piecemeal, workarounds for not forcing a visual encumbrance creates complexity, inconsistency, and unreliability. In particular they point out that hiding long description link text visually,

would require custom CSS or scripting. The mechanism for hiding the link would therefore differ product-to-product, making browser extensions or features to show the links more complex to code and less reliable for users.

CSS rules such as img{border:0;} for a long description link on an image is a needless, circuitous kludge. Older native HTML syntax is simple. Requiring CSS would add page weight and slow pages. Authors have voiced these facts. For instance, on October 13, 2011, Barry Kintner beseeched the HTML working group:

Please do not drop recognition of older (simpler) HTML vocabulary. I find far too many people are over-using CSS etc - not really knowing or understanding the needs of the visitor...

I find I've been able to re-create business web pages - with all functionality retained - that are 60-90% smaller in file size, by using so-called 'older' standards. Retain all the old codes that had been usable before (from 3.2-4.x).

The repercussions for ordinary authors of HTML5 having to resort to CSS was pointed out on February 19, 2012 in Bug 16026. It states that HTML5 is,

unnecessarily biased towards integration with CSS, and is considerably more complicated and thus incredibly inaccessible to most average casual users of the web.

Hiding long description indicators and descriptions with CSS adds needless complexity and is error prone. The potential for confusion is rife.

Even authors versed in CSS have problems hiding long description indicators with CSS in a manner that is accessible. As explained in my objection to the "Keep the longdesc attribute for the img element deprecated" proposal, the declaration display:none is hidden from screen readers. Not many authors know that fact. They use it to hide long description link text and it does not work for their target audience. For instance, Snowdon Award Scheme, and Zew have mistakenly used display:none for long description link text indicators. However, this common mistake was mitigated in these examples because they also used longdesc, which works.

Another example of an inaccessible CSS technique is using visibility:hidden. This declaration should not be used for content that is to be read by screen readers because it hides content from them. Daegu Metropolitan Office of Education is an example of an organization mistakenly using this technique. Fortunately they also used longdesc, which does work.

Hiding long description indicators and link text with CSS would especially place an undue burden on authors of limited skill set. They will not know how to use CSS let alone know which techniques may be accessible and which definitely are not. With longdesc this is not an issue because it is natively free from a visual encumbrance. This technique is an inefficient, inelegant, and clumsy "hack" that not only adds needless complexity, confusion, page weight, and inconsistency, it also is error prone and disenfranchises authors of limited skill set. All told, it would result in less accessible content.