Summary
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.
Author: Gez Lemon
Contents
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.
Category: Accessibility.
[html5-alt-text-authoring-tools.php#comment1]
Excellent article, Gez. Incredibly cogent insight and penetrating logic. It is a great relief to have the truth spoken and the real issue brought to light. Thank you.
Posted by Laura on
[html5-alt-text-authoring-tools.php#comment2]
Believe me, we're not going to need to worry about authoring tools conforming to HTML5 to make any claims about HTML5's success. That would be like claiming Coca Cola is successful because there are many recycling centers for Coke bottles. We have far more ambitious and direct goals.
Nor is it likely that the many people who are arguing for the current text in the spec all have a vested interest in a non-accessible authoring tool. I know I don't, at least.
We truly do believe in research, hard data, and analysis, rather than hypotheticals; and we truly do believe that evidence suggests that what we are arguing for is going to improve the accessibility of the Web. I'm sorry you think we are acting in bad faith.
Posted by Ian Hickson on
[html5-alt-text-authoring-tools.php#comment3]
Ian Hickson wrote:
Where is the evidence?
Posted by steve faulkner on
[html5-alt-text-authoring-tools.php#comment4]
Good article Gez. On one level, this is about the author and educating them about quality alternate text, and not about the tools themselves.
On another level it seems that you are right that in order for certain tools to be compliant with the new HTML 5 specification the requirements for conformance are to the relaxed, for whatever reason. Maybe in order to ratify(??) bad tools, or tools where it is difficult or not desirable (as it may impede on ease of use or be unwieldy) to provide proper @alt descriptions in the first place.
The issues of the much vaunted need for more research and evidence to back the case of the necessity for @alt being mandatory is a straw man (as you would say). The logic for this should actually be apparent to many of those who wish to relax the need for @alt to be mandatory, as it is in XHTML, in the first place. No one will ever upload images with no graphical content.
However, having @alt as an optional value *may* not be a show stopper as there are other mechanisms that can be used to provide descriptions rather than @alt (a la WAI-ARIA).
I am concerned though about triggering poor heuristics in legacy UAs but again my concerns are well documented in the HTML 5 WG.
Posted by Joshue O Connor on
[html5-alt-text-authoring-tools.php#comment5]
Yes. That's why HTML 5 doesn't give authors any choice in the matter; to be valid HTML 5 you must, if possible, provide alt text. Also, the alt text must be appropriate.
This goes much further than HTML 4, specifying lots of particular situations and explaining what alt text would be appropriate for each one.
That's misleading, in the sense that it is required in all cases where it's possible. It isn't 'optional' in the sense of the author being able to opt whether to use it or not; if an author has a choice then she must use it, otherwise the document isn't valid.
The only situation in which alt can be omitted is when providing good alternative text would be impossible; there is no point in the spec mandating something which is impossible.
For general 'webpage creation' tools where a user manually creates each page, what you say is true. And in these cases failing to provide alt text would yield invalid HTML 5.
However consider a bulk photo uploader, which takes a batch of many photos from a camera and uploads them to a website. It would be good if users would enter appropriate alt text for each image, but clearly many users won't (and, in the case that the photographer is himself blind, may not be able to).
The HTML 'author' in this case created a generic 'template' page, into which the (alt-less) uploaded images are inserted.
Good; we are in agreement about all of that.
That doesn't follow. If I run an image gallery site then I want to write valid HTML. Why should some of my pages be invalid because my users use bulk-uploading software? That's making my pages (I am the author of them) invalid for something that's out of my control.
But in this example neither the tool (my gallery website, which does allow alt text to be provided) is broken, nor is the author of the HTML (me) not caring about accessibility.
There is another. I want Flickr to serve valid HTML 5. Therefore I want it to be _possible_ for Flickr to serve their pages as valid HTML 5.
In particular, if Flickr have some broken mark-up (nothing to do with the <img> element) somewhere in their templates I want them to care about it being valid HTML 5, to be able to validate their pages, and for them to be receptive to people pointing out validation errors. However, if it's _impossible_ for their pages to validate they may dismiss HTML 5 as something which can't apply to them, and ignore the whole thing.
Given how much good there is in HTML 5 it would be a shame for sites or authors to ignore all of it just because there's one part which it's impossible for them to comply with.
The solution is to have 2 levels of compliance: HTML 5 first, and then additional accessibility requirements on top of that (WCAG). Then Flickr pages can be conforming HTML 5, but not conforming to accessibility requirements.
Not in the bulk-photo-upload case.
Not in my case -- I want HTML to be successful because of the improvements in brings.
Not in my case -- I have no interests in any authoring tools.
We already have WCAG. Why do we need HTML 5 to subsume it? We should be pressing for sites to be HTML 5 + WCAG compliant, rather than risking people thinking that 'just' being HTML 5 compliant is "good enough" and that necessarily makes your site accessible to all.
Posted by Smylers on
[html5-alt-text-authoring-tools.php#comment6]
Hi Josh,
The only mechanism in WAI-ARIA that could help provide an alternative for an image is
aria-labelledby, and that is only workable in certain edge-cases, as the content needs to be present on the page so that it can be referenced. As I mention at the start, there are scenarios where is it both possible and desirable to use a labelling mechanism, but they are rare edge cases. These edge cases do not negate the requirement for analtattribute, as that is the mechanism we're using to provide alternative text.Why isn't the
srcattribute optional? Thesrcattribute isn't optional because it's required to provide the embedded image; without it, the structure is incomplete. People who cannot see the image depend on the alternative text so that the image is perceivable; without it, the structure is incomplete. In the same way the structure isn't complete if thesrcattribute isn't provided, it's not complete if thealtattribute isn't provided.Posted by Gez on
[html5-alt-text-authoring-tools.php#comment7]
Hello Smylers,
If alternative text isn't provided, the structure is incomplete. If the structure is incomplete, it should be considered invalid. As a markup language, HTML5 should be concerned about structure, rather than lowering integrity constraints to cater for poor tools, authors, or both.
In which case, the structure is incomplete.
Because the structure is incomplete. If most of your users bulk upload content without the proper structure, then your site should quite rightly be considered invalid. If you write valid markup and have responsible users, your site would be considered valid with a few invalid pages from irresponsible users.
I also want Flickr to serve valid HTML 5 - the difference being that I care about the integrity of the structure.
The features themselves will sell HTML5. There is no reason to break integrity constraints to try and get people to use HTML5. But I'm grateful for your honesty in confirming that, at least from your personal perspective, the real reason to break the integrity of the data is to help ensure the uptake of HTML5. I don't think you need to be concerned, as HTML5 has lots of exciting features, but time will tell.
Posted by Gez on
[html5-alt-text-authoring-tools.php#comment8]
Hmm, in many cases the img is followed by a text description anyway, such as
[img]
My cat domino
It would make sense to omit the alt attribute for this image, as it'd just be a duplicate of the surrounding text.
Then again, an empty alt attribute says "Yes I'm standards-aware, but this image doesn't need a text alternative".
However, as soon as authoring tools put in empty alt attributes on the behalf of authors (who aren't standards aware) to achieve validation, the meaning of an empty alt is lost.
Posted by Jake Archibald on
[html5-alt-text-authoring-tools.php#comment9]
Jake said:
Authoring tools shouldn't put in empty alt text on behalf of the author; the author should decide what the alt text is, not the authoring tool. If the author doesn't provide any text, including null alt, then the authoring tool shouldn't include the alt attribute at all, as it's unknown. The meaning of null alt text isn't lost, and the meaning of a missing alt attribute isn't lost; the former means the image isn't important, the second means the author hasn't provided alt text.
Posted by Gez on
[html5-alt-text-authoring-tools.php#comment10]
Agreed, so should @alt should be optional in the spec or should authoring software refuse to save a valid document unless the developer provides alt text or specifically says the image has no relevent text alternative?
Posted by Jake Archibald on
[html5-alt-text-authoring-tools.php#comment11]
Gez writes:
That's begging the question; by definition, in HTML 5 <img> _will_ be complete without any alt text if it would've been impossible for the author to know what's in the image
Possibly. Structure seems a rather nebulous concept for HTML 5 to be concerned with, compared with the desires of users, authors, and so on. HTML 5's success will be in pages being interoperable, accessible, etc -- concrete things experienceable in the real world -- not in it having nice structure.
Why?
Do you think it's wrong to offer a service which can bulk-upload images straight from a camera without a (sighted) human having looked at them to provide alternative text?
Surely HTML should be about _how_ content is marked up, not passing judgement on what's a valid website?
"Invalid" should be a criticism of the mark-up, not of the business model.
Quite. That's exactly the correct output for the software to generate in that circumstance. Doing so is exactly what the HTML 5 spec says to do. In other words, doing so is conforming with the standard. So why would we want to label something that conforms with the standard as being invalid?
Such output would conform with HTML 5 but not with WGAC.
Posted by Smylers on
[html5-alt-text-authoring-tools.php#comment12]
Gaz writes:
In a typical webpage being generated by hand whatever the software does (alt="", or no alt) is invalid HTML 5, because HTML 5 mandates providing alt text for this case.
But if alt is always required that risks being mis-interpreted as meaning the only thing which can be checked mechanically (there must be an alt attribute, whatever that is), leading to authors preferring tools which provide alt="" (because that apparently generates valid HTML).
And that in turn creates a worse user experience for those who rely on alt text.
Posted by Smylers on
[html5-alt-text-authoring-tools.php#comment13]
Hello Smylers,
Our different points of view hinge around the fact that you don't believe that structure is important for a markup language, and so are prepared to compromise the structure to encourage the uptake of HTML5. I disagree with both of those points, which I've already gone over in the article, and subsequently in the comments.
To summarise, I do believe structure is important for a markup language. I believe the structure isn't complete if alt text isn't provided, as it isn't perceivable to some people (in the same way that src is a required attribute, or the image wouldn't be perceivable). Alternative text is required to maintain the integrity of the structure.
Posted by Gez on
[html5-alt-text-authoring-tools.php#comment14]
Another way to comprehend the structure paradigm and why the structure requires both src and alt:
src is to sighted users
as
alt is to some users with disabilities
Omit the src attribute and sighted users have no content.
Omit the alt attribute and some users with disabilities have no content.
As Josh O Connor stated before on the wai-xtech list, it would be akin to uploading blank images with nothing in them.
It would also be akin to saying that because people take bad photos, the src attribute should be optional. Do we need a research study on bad photos on the web too?
Posted by Laura on
[html5-alt-text-authoring-tools.php#comment15]
So if we are to understand this statement, and take it for what it says, the HTML 5 Specification will rely on the honor system when it comes to conformance or compliance. I am quite curious to know of any other Technical Specification or Standard which uses a similar means to ensure accuracy. Are the authors writing a Standard or a Wish List?
The editor and the other authors involved with the Draft have yet to put forward a credible instance when an 'author' *cannot* provide alternative text (save when using a flawed authoring tool), but have put forward instances when an 'author' may not *want* (or care) to do so.
... where 'good' is neither defined nor clearly understood. What makes 'good' alt text? One might just as well ask what makes good Chili (where the number of personal recipes and Chili "cook-offs" suggest that the answer to either question will never be qualified)
You are not the author of the content, you are simply the host. Are they your photos? Did you take them, do you own them, do you have *any* claim to the content beyond the fact that your system is being used to archive and display them? This is a false premise to start from, sorry.
Then how can you claim success when the most fundamental accessibility issue on the table back-peddles to becoming an "option"? This is success?
To be very clear, I am trying hard to understand the needs of those who claim that simply stuffing in @alt does nothing, and as I have previously written [http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/0393.html], I can understand that perspective. I have further gone on to suggest that 'alternatives' to @alt should be considered as we continue to discuss this issue, but I, like most accessibility advocates remain convinced that a 'web document' that contains nothing but <img> should be non-conformant, and I further suggest that in this instance the image (not the page) simply not render.
Posted by John Foliot on
[html5-alt-text-authoring-tools.php#comment16]
I don't think this is necessarily the case. I believe a more correct statement is:
Image data plus the surrounding context is to sighted users
as
Alt attribute value plus image data plus surrounding context is to some users with disabilities.
In other words, there is no reason that accessibility software has to rely on alt and nothing but alt. It could, if it truly wants to add value, perform some image analysis of its own (or analysis of the filename, etc). The fact that current such software doesn't isn't a fundamental law or anything.
The issue is that historically alt text is treated as authoritative: if there is an alt attribute, that's what the accessibility software should present. It's not clear whether performing image analysis on images with an alt attribute would produce better results than just using the alt attribute. It _is_ clear that if an image is not "structural" (i.e. it's just eye-candy), describing it produces a worse user experience for some users with disabilities. So there needs to be a way to mark such images; currently alt="" (empty string) is commonly used for that. Hence if accessibility software wishes to present images it needs to restrict itself to ones that have @alt values other than "".
Within that constraint, accessibility software could just ignore nonempty values of alt and rely on its own processing, but as I said it's not clear that this will usually give better results. So relying on @alt in that case will likely continue, so discouraging garbage @alt is important.
Which means authors need to be encouraged to NOT put alt="" (empty string) on images that actually matter, nor to put a garbage value in. The question is how to encourage them to do that while also encouraging them to produce valid HTML5 markup. Whatever solution is proposed (and I'm not advocating one here) needs to advance all three things. Some people feel that requiring @alt encourages alt="" or @alt with garbage values. You clearly either feel that it doesn't, or that encouraging those is OK. I can't quite tell from your post.
Posted by Boris on
[html5-alt-text-authoring-tools.php#comment17]
Well, then, I guess we can just invent a unicorn and be done!
It is as clear as the nose on your face. Image analysis is not and will likely never be a panacea, because it doesn't solve the fundamental problem that @alt does.
Images on the web are used to express the author's intent. Very rarely, if ever, are they unambiguously expressive of one idea by themselves.
Let's say I post an image of a house. And further, that some image recognition system recognizes it as a house. Would you know what my intent is in posting it? No. Maybe it's intended as a link to the homepage. Maybe it's a picture of my house. Maybe the house isn't the focal point, but that it is of a certain architectural style, or contains some other detail that, while I could express it in a few words, the average viewer would not be able to decipher. (This is also the reason newspapers caption all of their photos.) This disambiguation is what alt text is for, and @alt would be different in each of these cases, for exactly the same image.
Now take that problem, and multiply it by the number of images available on the web. Do you see why people who are concerned about accessibility aren't exactly thrilled with this line of reasoning? It may look great when you're so focused on the primacy of validation, but this argument is completely out of sync with the realities of implementation.
Posted by Matt May on
[html5-alt-text-authoring-tools.php#comment18]
No, of course not. Should pages that don't conform to the HTML 4 spec not be rendered? Of course not. Has the XHML model of not rendering a page that may have a minor infingement worked in promoting best practice? In truth I am asking rather than being rhetorical
The web would break if the pages that did not conform to how the specification is envisaged were no longer rendered. There are plenty of badly written pages in the wild. Even though they are often well written in *parts*.
Badly authored HTML 5 pages will and should be still rendered. The disconnect is often between the ideal and practical. The specification is the standard, as such, an ideal to reach for, and should therefore be an example of best practice this is why discussion like this are so important.
Posted by Joshue O Connor on
[html5-alt-text-authoring-tools.php#comment19]
Smylers said:
I would think the exact opposite is the case. Trying to structure a markup language is far less nebulous than figuring out the desires of authors. Also how can you suggest that the language can ever support the needs and desires of authors without a definite structure? Also there is nothing nebulous about a person with a disability trying to navigate unstructured content. The experience is very real and definite for them and not positive. Nothing nebulous or undefined there.
Therefore a cohesive structure is the beginning of any good design. You would not create web applications and interfaces without designing your menus or navigation? These are all structural, and HTML 5 is to supply the toolkit that expands the semantics available to describe these structures in a more advanced way.
With all due respect, it seems very strange to me to imply that the success of HTML 5 is down to its interoperability and accessibility, two very important considerations that in my book are as a result of good structure, and then somehow suggest the two things are not related.
Posted by Joshue O Connor on
[html5-alt-text-authoring-tools.php#comment20]
Matt,
Snide sarcasm is the easy way out, sure. So is not doing anything and griping about how doing it would be hard.
Did I claim it would be? I'm saying it would be better than missing or garbage alt text, but that the problem is knowing whether the alt text is garbage.
I would like to point to this part again:
Alt attribute value plus image data plus surrounding context is to some users with disabilities.
I'm not saying it's an easy problem. I'm saying it's an easier problem than getting Nephew Bob to put alt text on every image he uploads to Flickr. And much easier than affecting the image-posting behavior of Great-Aunt Molly.
Note that I'm not saying that alt text is useless. Quite the opposite, until AI gets a heck of a lot better than what we have now. That's precisely why we want to make sure that incorrect alt text is NOT present.
The main argument seems to hinge on whether the "it will cause bogus alt text to appear in cases where one could extract useful information" issue will affect more images than the "it will cause no alt text to be placed on images where it could be placed and where no information can be extracted" issue. I have yet to see hard data either way. But I would like to point out that "cases where one could extract useful information" is a strictly increasing subset of cases as time goes on, whereas pages are rarely edited: once bogus alt text is out there, it's out there. So in the long term (how long is a good question), the former issue will affect more images than the latter.
Maybe it's just me, by the way, but none of this seems as clear-cut as some people (including yourself) appear to think it is. I do appreciate the fact that you're somewhat more civil about it than some others, though.
Posted by Boris on
[html5-alt-text-authoring-tools.php#comment21]
No, it's not. The Flickr Defense is not a sufficient criterion for making @alt optional across the board. Take a look at an average Flickr image page. There are 65 images, total. Number of images that Flickr can't provide alt text for? One. Previous and next images should have "previous/next image" alt text; all the rest should have meaningful alt, or "" because they're decorative. And all the author would have to do to make that last image accessible is to edit the title, and have that flow through to @alt. Done.
If they don't do that, it's not on Flickr to guess. WCAG 2 even allows Flickr to explain that it isn't responsible for alt text in user-generated content. This is _not a problem_. Certainly not one that warrants a change in HTML. And not one that the accessibility community is asking HTML5 to solve by itself.
But the Flickr Defense is just one of several red herrings that keep coming up here. Another is the AI argument. It's been researched for many, many years in accessibility, and it's still nowhere near ready to be used by people with disabilities, by any account. Keeping in mind that accessibility is where we've seen the first everyday applications of text-to-speech OCR, and voice recognition, among many, many other technologies, this is a salient detail. It's not that it's hard, or that it hasn't been considered. There isn't any indication that it will _ever_ be broadly applicable.
Standards need to exist in the world as it is today. There is no room for conjecture.
Posted by Matt May on
[html5-alt-text-authoring-tools.php#comment22]
It's interesting that you say this. Usually changing computer behavior is orders of magnitude easier than changing societal norms. What makes this case special?
No one is proposing making it optional across the board, for spec-compliance purposes. As you point out, the Flickr page is not compliant with the proposed HTML5 text. But it could be, with a tiny effort.
Sadly, that's not how many tools behave. If there were no guessing going on, there would be no problem with always requiring an alt attribute.
I'm the only one who's made the argument so far that I've seen, and I only did it once before this blog. That's an interesting definition of "keep coming up".
Note that there are people working on image recognition (not full AI) right now, with some success.
And allow for it as it will be two years from now (though perhaps not ten years from now). The whole point of a standard is to affect how things will be done from now on... If it were only about things that already are, no one would care: they already are.
Posted by Boris on
[html5-alt-text-authoring-tools.php#comment23]
Because this is a case where human intelligence is called for. Computer behavior is not an acceptable substitute, and may never be.
It doesn't matter. Optional is optional. Unless you want the _validator_ to determine whether each missing alt is compliant. In which case, you've inherited responsibility for figuring out which ones are intentional, and which ones aren't.
I've already said it once: the absence of semantics is not the semantics of absence.
I don't think I was clear enough. According to WCAG 2, sites like Flickr can exempt themselves from responsibility for alt text, where they don't have it. They don't have to guess. If the author doesn't create alt text, it is the author's problem.
Yes. Some. A little. In narrow domains, of questionable utility to the task at hand. The researchers present every year at accessibility conferences, alongside the speech recognition people who assure us that continuous speech recognition is _almost_ ready for prime time. Except they've said it for over 30 years now, and still, I can't even talk to my TiVo.
Image recognition is a quantum leap in difficulty from OCR or speech recognition. And it _still_ is incomplete for the purpose of replacing @alt in everyday application.
Bookmark this quote, and return to it in 10 years. If image recognition is in common usage as a replacement for @alt, to the extent that @alt doesn't need to be written on arbitrary images, I'll give you $100. I'll even put that up on longbets.org. (Heh. Even if I lose, we win!)
Posted by Matt May on
[html5-alt-text-authoring-tools.php#comment24]
Okay. Rather than blow up Gez's comment area, here's my take on the whole charlie foxtrot:
http://www.bestkungfu.com/archive/date/2008/05/alt-and-the-flickr-defense/
Posted by Matt May on
[html5-alt-text-authoring-tools.php#comment25]
Dana,
As Al Gilman, Chair of the W3C Protocol and Formats Working Group (PFWG) [1] has said:
[1] http://www.w3.org/WAI/PF/charter200612
[2] http://lists.w3.org/Archives/Public/public-html/2008Feb/0082.html
Posted by Laura on
[html5-alt-text-authoring-tools.php#comment26]
I think it boils down to what is the motive for people to actually include the alt description? Unless there is some significant issue with rendering or formatting, developers are still going to leave it out. If nothing else, many coders are just lazy, uniformed or just plain don't care about the "few" who actually need that description to move around the web efficiently. It's not a big enough issue to get the attention it deserves.
Jim
Posted by JIm on
[html5-alt-text-authoring-tools.php#comment27]
I think the sentence
in the current HTML 5 draft simply fails the W3C's quality assurance requirements, because "possible" is a subjective term (what is possible to one person may be impossible to another). If I understand the W3C document "Variability in Specifications" correctly, this would be a "discretionary item": http://www.w3.org/TR/spec-variability/#optionality.
Even discretionary items need to be well defined, which is not the case for "possible" in the current HTML 5 draft.
The Specification Guidelines in the W3C QA Framework advise specification authors to
Rationale:
(See http://www.w3.org/TR/qaframe-spec/#constraints-gp.)
It needs to be shown that the phrase "[w]hen it is possible for alternative text to be provided" meets these guidelines. I don't believe it does.
Posted by Christophe Strobbe on