Over a million developers have joined DZone.

HTML5 Alternative Text, and Authoring Tools

DZone's Guide to

HTML5 Alternative Text, and Authoring Tools

· Web Dev Zone ·
Free Resource

Learn how to add document editing and viewing to your web app on .Net (C#), Node.JS, Java, PHP, Ruby, etc.

There is still strong debate about whether or not the alt attribute should be a required attribute for the img element in the HTML5 draft  on the W3C's XTECH mailing list . The argument is currently focused around what authoring tools should do when the author doesn't provide alt text.

Integrity of the Data Structure

When images are delivered without a text alternative, the image will not be perceivable by some users, such as blind screen reader users. Without a mandatory mechanism to provide a text alternative, the structure is incomplete, as it cannot be perceived by some users. The mechanism for providing alternative text in HTML at the moment is through the alt attribute.

Al Gilman, Chair of the Protocols and Formats Working Group , pointed out that in general, content intended for the end user should be in element form , rather than specified in attributes. This is, of course, correct, as it's possible to structure data in elements so that the user has some control in how they interact with that content, whereas delivering the content in a text string has obvious limitations. But there are no plans to rework the structure of HTML for a more robust mechanism of providing alternative text for images, so we're stuck with the current system of using an alt attribute, with a few edge-case where it is possible and desirable to use a labelling system instead of using the alt attribute.

Whether we stick to the current system of using an alt attribute, or re-engineer HTML so that it uses a more appropriate mechanism for providing alternative text, the one thing that is clear is that alternative text must be mandatory, or some people will not have access to information. The current thinking is that we should use an alt attribute for specifying alternative text in HTML5. At this point in time, the alt attribute is still not a required attribute in HTML5, meaning that the structure may not be perceivable to some users, yet the structure can be considered valid; surely, that is an oxymoron?

Authoring Tool Quandary

The argument put forward by most members of the HTML5 working group for making the alt attribute optional is for when an authoring tool doesn't have anything useful to use for the alternative text. The concern is that the authoring tool will populate the alt attribute with junk in order to conform to HTML5. This argument is fundamentally flawed for one simple reason: assuming the authoring tool allows authors to provide alternative text, it would be the author that has failed to conform — not the authoring tool.

When an authoring tool doesn't have anything useful to put in for the alt text, the tool shouldn't put anything in. A good authoring tool will check for missing alt text and offer to assist the user in repairing the content. If an author is adamant they're not going to provide alt text, there is no requirement that says the authoring tool should provide it in place of the author. In fact, it's just the opposite, as the authoring tool could not possibly know the author's intent. In this scenario, the authoring tool should not include the alt attribute at all, and the resulting markup should be considered invalid. It should be considered invalid because it is inaccessible, and not perceivable by some people. If the tool allows alt text to be provided, then the tool would be considered compliant (on this particular issue), even though the resulting markup would not be compliant, as the user chose not to make the content compliant.

It doesn't make sense to break the integrity requirements of the structure in order to cater for broken authoring tools or authors that don't care about accessibility. The only obvious benefit of making the alt attribute optional with the img element is that authoring tools that don't allow people to provide alt text, or authors that don't care about accessibility, will be conformant without having to do anything.

Researching the Problem

Some members of the HTML5 working group suggest researching the importance authoring tools place on conformance , so that this argument can be settled rationally. The rationale being research the real issue, and then discuss whether or not the alt attribute should be mandatory or optional.

I'm all for research, but in this particular instance, the research is more misdirection and a delay tactic. Why is research needed? A compliant authoring tool already allows the user to provide alt text. Without research, we know that compliant authoring tools care about standards (or at least providing an alt attribute for the img element). We also know that if an authoring tool doesn't allow the author to provide alt text that they don't conform to any known standard at the moment. If these authoring tools don't conform to any standards now, where is the requirement for research? No one needs to contact the vendors of non-conforming authoring tools and ask them how important standards are to them, as the answer is obvious by the fact they make it impossible to adhere to HTML 4.01, XHTML 1.x, WCAG, and so on. It's painfully obvious that non-compliant authoring tools just don't care. There is no need for research on this particular issue, other than an excuse to indefinitely put the issue on hold.

I suspect the real issue is that some members of the HTML5 working group want authoring tools to conform to HTML5 so they can demonstrate how successful HTML5 is, or they have a vested interest in an authoring tool that doesn't conform to WCAG — not the other way around.

Original Author

Original Article Written By Gez Lemon

Extend your web service functionality with docx, xlsx and pptx editing. Check out ONLYOFFICE document editors for integration.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}