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.
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?
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.
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.
Safari starts to get support for WAI-ARIA.
WebKit, the open source application framework behind Safari and other browsers, announced that they have started to add support for WAI-ARIA on the Gnome mailing list yesterday. They have added global support for the tabindex attribute, and have added support for basic ARIA roles.
This is great news, as all four of the major browsers, Firefox, Opera, IE8, and Safari now have support for WAI-ARIA to some extent.
The Web Content Accessibility Guidelines (WCAG) 2.0 has progressed to a W3C candidate recommendation. The WCAG Working Group are now looking for implementers from a cross-range of websites to help them determine whether or not organisations that have not worked closely with the development of WCAG 2.0 can follow the guidelines.
Candidate recommendation means that the WCAG working group and public reviewers have reached broad consensus that WCAG 2.0 satisfies the working group's technical requirements, and is ready to gather implementation experience. In order to do that, the working group must gather feedback from independent implementations.
In order to demonstrate that all the Success Criteria for a given conformance level can be satisfied within the same site, the WCAG Working Group require at least two independent implementations of every success criterion in the guidelines. They also require at least another four websites that conform at level A, at least another four websites that conform at Level AA, and at least another two websites that conform at level AAA. Implementations should be from organisations that have not been working closely with WCAG 2.0, and from a broad cross-section of websites (web applications, government websites, and so on). The working group are particularly interested in implementation details from websites that include items at risk.
See the intrsuctions for implementors if you intend to submit a website that conforms to WCAG 2.0 at any level. Once you have read the instructions, you should register your intent to submit an implementation through the implementation registration form so that the working group can select a core set of implementations with maximum coverage of the criteria. Questions about the implementation can be sent to team-wcag2-implementations@w3.org.
WCAG 2.0 has been the collaborative effort of many participants working under difficult circumstances. A special thank you should go to the current editors; Gregg Vanderheiden, Loretta Guarino Reid, Michael Cooper, and Ben Caldwell. A special thank you should also go to the previous editors; Wendy Chisholm, John Slatin, and Jason White.
The John Slatin Fund Accessibility Project matches accessibility experts with companies wanting a brief accessibility audit of their websites. In return for the audit, site owners will contribute a minimum of $500 to help fund the medical expenses incurred by John's family during his long illness.
As most readers of this website will know, John Slatin passed away last week after a three-year battle with leukaemia. I've corresponded with John a few times over the years, but sadly, I have never met him. I came close, as I was invited to dinner with John, Sharron Rush, and Jim Allan by Jim Thatcher at last year's CSun conference, but my flight was cancelled because of bad weather.
Despite having never met John, and only corresponding with him a few times, I regard him as a friend. He was patient, courteous, and a brilliant mentor. I learnt a lot from John in just a few email correspondences, for which I will always be grateful. I feel I've lost a friend, and if I feel this way after a few correspondences with John, I can't begin to imagine how painful it must be for John's family, and many close friends. My thoughts are with them.
The John Slatin Fund Accessibility Project has been set up to help fund the medical expenses incurred by John's family during his long illness. The idea is that accessibility experts volunteer a few hours of their time to review websites for companies that contribute a minimum of $500 to the John Slatin fund. Not only does the project help John's family; it helps spread the word about accessibility.
As most visitors to this website have a keen interest in accessibility, I hope you're able to volunteer to this worthy project. If not, please consider signing up for an accessibility review.
Martin Kliehm and I were both very pleased with our core conversation about WAI-ARIA at SXSW. The idea behind core conversations is to formalise conversations that take place in the corridors.
We were very fortunate to have some very knowledgeable people participate, such as Becky Gibson, Shawn Henry, Lisa Pappas, Sharron Rush, Niqui Merret, Michael Stenitzer, Ian Lloyd, and many others (apologies for not mentioning everyone by name). Becky was one of the original architects that developed ARIA at IBM before it was donated to the W3C. Since then, Becky has been working on incorporating ARIA into the Dojo javascript toolkit. Sharron, Lisa, Becky and Susan Gerhart did a panel on Accessible Rich Media the day before, and Becky demonstrated an email client built with Dojo and the accessibility features afforded by ARIA.
After Martin gave a brief overview of ARIA, Becky started the conversation by outlining some of her experiences, which prompted lots of good questions. Nobody, apart from Becky, had actually implemented ARIA in their projects, but we were encouraged that most of the participants were making plans to implement it.
All in all, we had a great time, and it was great to meet so many people with a passion for the web. This was my first time at SXSW, but I hope I'm able to go again. Austin is an amazing city, and the whole festival has a great vibe. Unfortunately, I caught a cold at the end, which turned heavy and has only just started to clear.
Martin Kliehm and I will be holding a core conversation on WAI-ARIA at next week's SXSW called, Get Rich, Remain Accessible. The conversation will take place at the Austin Convention Center on Sunday 9th March between 3:30 pm and 4:30 pm. What aspects of ARIA would you like to talk to us about?
The panels at this year's SXSW Interactive Conference and Festival were decided from the number of weighted votes using a panel picker. Martin and I submitted an idea for a panel, but unfortunately, there wasn't enough interest for our panel idea to be selected. There was, however, enough interest for us to be invited to hold a core conversation.
This is the first year that core conversations have been held at SXSW, so we're after as much advice as we can get on how to prepare for it. The organisers suggest a format of a 5-7 minute introductory presentation that will hopefully stimulate conversation from the attendees. To that end, it would be great if we could have a good cross range of people at the core conversation - from people who have never heard of ARIA, but want to ensure their work is as accessible as it can be, to people that are working on the specifications and early implementers. If you fall into any of these categories, we would really appreciate your help.
The organisers at SXSW also suggest that people holding a core conversation should gather a list of frequently asked questions. WAI maintain a list of Frequently Asked Questions on ARIA, but I was wondering what you would be interested in asking or talking about. Even if you're not going to be at the core conversation, it would be great to hear the type of things you would like to talk about, or what questions you have about ARIA. Hopefully, we'll see you there.
Charles L. Chen and T. V Raman announced an open source framework called AxsJAX. The framework inserts ARIA properties into web applications to make them accessible to assistive technologies.
Charles L. Chen and T. V Raman have developed a common JavaScript framework to enhance the accessibility of AJAX-based applications. The framework is called AxsJAX, pronounced, "Access JAX". Charles came up with the idea after adding ARIA support for Live Regions to Google Reader, which already had very good keyboard support.
Broadly speaking, there are two problems with Web 2.0 applications:
Both of these problems are solved with the W3C's Web Accessibility Initiative - Accessible Rich Internet Applications (WAI-ARIA). Feedback on what has happened is provide through WAI-ARIA's Live Regions, which includes properties that determine the politeness of feedback, and exactly what is reported to the user. Both JAWS and Window-Eyes, the two most popular screen readers, are working on implementing live regions. Fire Vox, the open source talking browser extension for Firefox, already supports live regions.
The AxsJAX framework works by automatically inserting ARIA properties into the DOM, based on design patterns. At the moment, the only Web 2.0 applications that support AxsJAX are Google Reader and Google Search.
There are several ways that the AxsJAX framework can inject ARIA properties into Web 2.0 applications. The cross-browser approach would be to use the AxsJAX bookmarklet. This approach means that the user needs to activate the bookmarklet each time they visit a page that supports the AxsJAX framework.
There is also a GreaseMonkey Mozilla/Firefox script. GreaseMonkey scripts are executed automatically when a page is visited, which means that the ARIA properties are inserted automatically when the page is loaded if the user is using the AxsJAX GreaseMonkey script.
Fire Vox will automatically inject ARIA properties using the AxsJAX framework if the "Use site specific enhancements" option is enabled, regardless of bookmarklets and GreaseMonkey scripts. Charles and Raman are looking to the open source community for coming up with other innovative means of providing enhancements using the AxsJAX framework.
To make use of the framework, you will need a user agent that supports WAI-ARIA, such as Firefox 2.0 or later. You will also require an assistive technology that supports WAI-ARIA. If the assistive technology you are using has a virtual buffer, you will need to ensure that the virtual buffer is disabled - for example, using PC-Cursor mode in JAWS.
Google Reader and Google Search have a set of keystrokes than enhance the experience for assistive technology and regular users alike. For example, n and p may be used to cycle forwards and backwards through the items in the result-set respectively. The AxsJAX framework ensures that the updates are reported correctly to assistive technologies that support ARIA's live regions.
Jim Thatcher noticed some interesting behaviour whereby screen readers announced content in an anchor element that is hidden with display: none. Content hidden with display: none is not usually announced by screen readers, apart from labels for form controls, regardless of the verbosity settings.
Looking into it further, there are certain circumstances where content hidden with display: none is announced by JAWS and Window-Eyes. The circumstances are explained in this article, but it is always better to position content aimed at providing context for screen reader users off-screen, as content hidden with display: none should remain hidden.
display: nonedisplay: nonedisplay: nonedisplay: none
When an element is hidden with display: none, the browser doesn't generate a box for the element; the element is not visible on the screen, and the layout of the page isn't effected by the element. As screen readers are supposed to read the screen, it makes sense that they do not announce content that is hidden with display: none.
Becky Gibson noted a few years back that labels for form controls hidden with display: none were announced by JAWS and Window-Eyes. I had noticed recently that JAWS announces span elements hidden with display: none in anchor elements, but that the span was not announced by Window-Eyes. When I mentioned this to Jim, he sent me files that he was using; sure enough, the content was being announced in Window-Eyes, which was a mystery to both of us.
There are situations where developers might want content to be hidden visually, but revealed to screen reader users. For example, a design might call for ambiguous link phrases, such as "More", where the context is visually evident, but might be lost to screen reader users. To get around this, a developer might do the following:
.context
{
display: none;
}<a href="...">More<span class="context"> about XYZ</span></a>
The problem is that hiding the content with display: none also hides the content from screen readers (more about this later). To get around this, developers position the content off the screen, such as using the following technique:
.context
{
position: absolute;
left: -999em;
width: 1em;
overflow: hidden;
}Using the same markup as above, the contextual information isn't displayed on the screen, but is announced to screen reader users.
display: none
As stated earlier, JAWS announces content in a span element hidden with display: none if it is in an anchor element. This only works with a span element; other inline elements used in an anchor element, such as em, strong, abbr, code, and so on, are not announced in JAWS.
Steve Faulkner ran some tests, and determined that this behaviour was introduced in JAWS version 7.1 and only for Internet Explorer.
display: noneThe content of the span in the markup snippet below is announced in JAWS 7.1 and later with Internet Explorer, but it is not announced in Window-Eyes.
.context
{
display: none;
}<a href="...">More<span class="context"> about XYZ</span></a>
Jim Thatcher had come across a couple of websites where content was hidden with display: none, but was being announced by Window-Eyes 5.5. Playing around with the CSS in Jim's examples, it turned out that the reason why content hidden with display: none was being announced in Window-Eyes was because an ancestor element had a URL set for the background-image CSS property. So if the CSS for the above example included the following rule-sets, the content hidden with display: none would also be announced in Window-Eyes.
a
{
background: url(hidden.gif);
}
.context
{
display: none;
}
I suspect that the reason why this works when the CSS background-image property has a value on an ancestor is to cater for inaccessible image replacement techniques, such as the Fahrner Image Replacement technique explained by Doug Bowman (but not recommended by Doug).
There are a couple of extra interesting points.
background-image property, content hidden with display: none will be announced in Window-Eyes.background-image property on the body element, content hidden with display: none is not announced, unless there is another ancestor after the body element with the background-image property set.display: none does not have to be a span within an anchor element; it doesn't even have to be contained within an anchor element. Complete div elements or anything else will be announced in Window-Eyes if they're hidden with display: none, but have an ancestor that has a value specified for the background-image property.display: none, and has an ancestor with a value specified for the background-image property, it is visible to Window-Eyes, even though it isn't in the browser's natural tab order.
This is very strange behaviour, where points 3 and 4 can cause serious problems for Window-Eyes users. If content has been deliberately hidden from everyone, including screen reader users, Window-Eyes users will be exposed to that content if the background-image property has been set on an ancestor. I can understand JAWS' behaviour of announcing content that really shouldn't be announced when a span element is used within a link phrase, as they're just using heuristics to help their users. The Window-Eyes approach seems a little more reckless, although probably just as well-intentioned. The background-image property is used extensively, and far more popular than inaccessible image replacement techniques. Pages that deliberately hide content from everyone with display: none are broken in Window-Eyes if a value is provided for the background-image property.
Jared Smith asked in the comments whether the results are any different if both display: none and visibility: hidden are used.
JAWS behaves exactly the same when a span element is hidden with visibility: hidden in an anchor element as it does with a span element hidden with display: none.
Window-Eyes doesn't do the same thing if visibility: hidden is used. Content hidden with visibility: hidden is not announced in Window-Eyes, even when an ancestor has a value specified for the background-image property. On its own, visibility: hidden might not be desirable, as it generates a box that effects the layout. Fortunately, using visibility: hidden also works with display: none, which doesn't generate a box, and therefore has no effect on the layout. So issues introduced by Window-Eyes' strange behaviour can be avoided using the two properties together:
.hide
{
display: none;
visibility: hidden;
}Thanks to Jared for coming up with a solution to the problem.
Please note: this article is now out of date. See the following for more details.
The Web Accessibility Initiative's Accessible Rich Internet Applications (WAI-ARIA) roadmap includes a plan for developing the roles and states necessary to make rich internet applications accessible. The accessible properties are added using the namespacing capabilities of user agents that support XHTML delivered as application/xhtml+xml. As Internet Explorer doesn't support this MIME type, it cannot make use of namespacing in the markup. To make up for this, WAI's protocols and formats working group have a document outlining how to add WAI-ARIA roles and states to HTML content delivered as text/html.
The technique essentially serialises the role and state information in the class attribute. HTML user agents don't parse namespace information, but as the DOM API supports namespaces, the role and state information can be inserted with the namespace directly in the DOM so that HTML documents delivered as text/html can use WAI-ARIA roles and states. The protocols and formats working group provide an ECMAScript library to insert the information specified in the class atttibute into the DOM.
class ValuesThe problem with developing rich internet applications in HTML for the web is that HTML (and XHTML 1.x) only has a small set of semantic elements. Assistive technologies communicate information to the user based on document semantics. When developers create custom controls, accessibility problems can be introduced if the controls do not have the correct semantics to inform assistive technology what the control is and what values it has.
WAI's Accessible Rich Internet Applications (WAI-ARIA) roadmap includes a plan for developing the roles, and states and properties necessary to make RIAs accessible. WAI-ARIA does this using the namespace capabilities of XHTML, which isn't supported in HTML. Also, XHTML documents must be served as application/xhtml+xml in order to use XHTML's namespace capabilities; if XHTML documents are delivered as text/html, the user agent will treat it as HTML, and the namespace information will be lost. This means that user agents that don't understand content delivered as application/xhtml+xml, such as Internet Explorer, can't make use of the roles and states defined in the WAI-ARIA roadmap.
A note on WAI's protocols and formats website explains an approach for embedding accessibility role and state metadata in HTML documents (editor's draft). The technique allows content to be served as text/html, which means WAI-ARIA role and state information can be provided for user agents that can't handle content delivered as application/xhtml+xml.
The technique works by specifying role and state information in the class attribute, as the class attribute applies to all elements in the strict doctype, except the base, head, html, meta, param, script, style, and title elements. An ECMAScript library, enable.js, can then used to insert the accessibility information in the appropriate role and state namespaces.
User agents that parse HTML don't parse namespace information, but the namespace information can be inserted into the DOM, as the DOM API does support namespaces. XHTML served as application/xhtml+xml, can use namespace aware methods from the Document Object Model (DOM) Level 2 Core Specification, such as setAttributeNS. Some browsers don't support the namespace methods, and must instead use the methods from Document Object Model (DOM) Level 1 Specification, such as setAttribute, which isn't namespace aware. When using the non-namespace aware methods, the namespace value must be prefixed to the attribute name. So developers could do something like the following to use namespace DOM methods when they are supported, or use the HTML hack to prefix the namespace value to the attribute name:
if (typeof document.documentElement.setAttributeNS != 'undefined')
{
oElm.setAttributeNS('http://www.w3.org/2005/07/aaa', 'valuenow', 3);
}
else
{
oElm.setAttribute('aaa:valuenow', 3);
}
Fortunately, the logic is taken care of in enable.js — all the developer has to do is specify the role and state information in the class attribute, and call the initApp method when the page is loaded, and the initContent method if rich content is added after the initApp method has executed.
class Values
The class attribute accepts a space separated list of class names. To specify role and state information in the class attribute, a class name of axs is used — the values that follow the class name axs are the role and states for the control. This means that a class name of axs should be avoided for general styling by developers using this technique to add WAI-ARIA accessibility information, as it has a specific meaning in the ECMAScript library. The first class name following the class name axs is the role; the rest of the class names are the state information. This means that developers must ensure that all classes used as hooks for CSS selectors, or other programmatic hooks, are placed before the axs class name.
The state information is a key/value pair, separated by a hyphen. The following example shows how the class attribute might be used to set WAI-ARIA role and state information for a slider control:
<input type="image"
src="thumb.gif"
alt="Effectiveness"
id="thumb"
title="Effectiveness, between 0 and 500"
class="axs slider valuemin-0 valuemax-500 valuenow-3">
For states that accept a value of true, the value can be omitted if the state is true, as this is the default value for these states. For example, the following two classes have equivalent values:
class="axs checkbox checked-true"
class="axs checkbox checked"
As the first value specified as a class name following the axs class name is the role, and the rest of the class names describe the state, this means that only one role can be specified using this technique. Using XHTML namespaces, more than one role may be specified. Embedding accessibility role and state metadata in HTML documents states that whilst it is common for there to be more than one state, it's very rare to require more than one role. If more than one role is required, it would be possible by reworking enable.js so that the roles were specified with a separator, such as a colon:
class="axs table:tree ..."
enable.js is a clever solution for creating rich internet applications, but I prefer to use content negotiation and progressive enhancement. For example, instead of starting off trying to define a slider control in markup, start with an element that is semantically as close to the control you're trying to make richer; in this case, a drop-down list: Use content negotiation to determine if the user agent can handle content delivered as application/xhtml+xml: If the user has a script enabled browser, use progressive enhancement to update the drop-down list to a slider control, and use the same keystrokes required to interact with the slider that the drop-down list would use. See the slider control for an example of how this is done in practice.
At this time, the only user agent that supports WAI-ARIA is Firefox (1.5 and higher). Assistive technology, such as JAWS and Window-Eyes, are able to communicate role and state information specified with ARIA, and the situation will get better as more work is put into the specification, and other user agent start to support ARIA. Charles Chen's excellent Fire Vox plugin has added support for ARIA, and Opera are also working on adding support for ARIA. Hopefully, Internet Explorer, Safari, and other user agents also have WAI-ARIA on their radars.
The slider control works as expected in Internet Explorer with JAWS and Window-Eyes because the custom control has an explicit label, and the role is exposed through the alt attribute of the input element.
The img element in the current HTML 5 draft doesn't include the longdesc attribute, and the alt attribute will no longer be a required attribute.
longdesc Attribute
One of the great things about the current HTML 5 draft is that they give plenty of examples of how to specify alternate text for images, although a few of them are misguided. Alternate text should be concise, and a longer description provided with a longdesc attribute if necessary. The incomplete techniques document for the current WCAG 2.0 draft contains the following advice for specifying alternate text on images:
When using the
imgelement, specify a short text alternative with thealtattribute. Note. The value of this attribute is referred to as "alt text".When an image contains words that are important to understanding the content, the alt text should include those words. This will allow the alt text to play the same function on the page as the image. Note that it does not necessarily describe the visual characteristics of the image itself but must convey the same meaning as the image. If the text in the image is more than can fit in a short text alternative then it should be described in the short text alternative and a
longdescshould be provided as well with the complete text.
As the current specification for the img element in HTML 5 doesn't include a longdesc attribute, the alternate text in their very first example is too verbose at 43 words (216 characters). The example would be better if the image was described more succinctly, and the extra information included in the main body text; if text in the main body is undesirable, because it's duplicating the content in the image, for example, then a better technique would be to specify a URI to a longer description using the longdesc attribute. If the final HTML 5 specification doesn't include a longdesc attribute, then authors of accessible material will have to resort to the infamous D-link, deprecated in WCAG 1.0 techniques in favour of the longdesc attribute.
As the longdesc attribute's value is a URI, the resulting page containing the longer description can be marked up with rich structural elements (lists, tables, and so on) to aid understanding, which isn't possible with plain text in an image's alt attribute. The longdesc attribute is useful for creating accessible content without having to resort to D-links, which can detract from the design of a page.
alt Attribute
Another contentious issue with the current HTML 5 draft is that the alt attribute for an image may be omitted completely. The reasoning is along the lines that there are examples of applications where users don't know how to provide alternate text, such as Flickr, and it has been observed that systems make up for this by generating alternate text from the image's meta data. The perceived benefit of not providing alternate text supposedly makes it easier to distinguish between images that have no alternate text, or are part of the critical content. From an article by Lachlan Hunt about why the alt attribute may be omitted:
The benefit of requiring the
altattribute to be omitted, rather than simply requiring the empty value, is that it makes a clear distinction between an image that has no alternate text (such as an iconic or graphical representation of the surrounding text) and an image that is a critical part of the content, but for which not [sic] alt text is available.
I don't understand how a user agent is supposed to differentiate between an image with deliberately missing alternate text, or alternate text that is missing because the author didn't know how to specify alternate text. We all agree that alternate text is essential for accessibility; it's not accidental that the very first requirement from any set of accessibility guidelines is that alternate text is provided for non-text objects.
Providing blank alternate text is something that must be done deliberately, and helps user agents determine whether or not the alternate text is in need of repair, as opposed to just omitting the attribute; of course, there will be scenarios whereby assistive technology will rely on heuristics when alternate text is missing, regardless of the markup - for example, when an image alone is used as the link phrase in an anchor element or part of an image map and empty alternate text is provided. In this case, assistive technology has to present something to the user so that they know what the link is, so will attempt to get the information elsewhere; such as from the title attribute, or in extreme cases, from the src attribute of the image. At least specifying null text for the alt attribute is a definite decision on the part of the author, and not the ambiguous situation of not knowing whether the alternate text was accidentally or intentionally omitted.
Alternate text contains important information about an image that must be included in the structure, even if that information is blank because the image is purely decorative. It is better that purely decorative images are not included in the structure in the first place, but included with CSS. However, there should also be a markup solution to indicate whether or not the alternate text of an image is critical to understand the content - omitting such an important attribute is ambiguous, and doesn't help anyone. Systems that generate poor quality alternate text need fixing, and all authors should be encouraged to provide high quality alternate text.