I'm with you Adrian, I see no need to loosen the requirement for the alt attribute.
The alt attribute is well supported in browsers and all AT that I've come across. I can't speak for all CMS platforms but with WordPress it's easy to place alternate text on an image in a page or a blog post. I expect Drupal etc are similar.
The support for ARIA attributes is not consistent and sometimes missing – even in modern versions of AT eg. Talkback on Android.
For me the argument about it being easier to use aria-label as it can be used across elements other than images is irrelevant. If someone is going in at the attribute level they're going to be technically savvy enough to differentiate between alt attributes and labels. There are a lot of semantic HTML elements, but no-one is really suggesting grouping all those together into just one element.
Re the issue of a page failing because one alt attribute is wrong or missing… Well, like you I think that's fair enough. When I'm testing websites for accessibility there is almost always a lot of things that are done right. But the very nature of an accessibility test or review is to point out where there are issues – so they can be fixed. Fixing one alt attribute is probably going to be an easier fix than some other things.
That said, I always do try to mention good stuff about a website in my reports too. I like to think it can avoid an audit report seeming very negative.
First, I'm curious how we got to this point. Why has nobody considered the implications and harmonization of years-old W3C specifications (two of which are accessibility-specific) that prescribed techniques that directly resulted in a WCAG failure until now? That the working group is seemingly caught off guard and in argument over this is a bit alarming.
Second, to partially answer that question, it seems that recent updates to WCAG techniques documents simply reflect the current state of AT support, rather than best practice and requirements for optimal accessibility. WCAG is simply becoming a codification of "what works today" versus "recommendations for making Web content more accessible" (sentence one of the WCAG 2.0 document).
This leaves innovators of ARIA, HTML5, and tomorrow's technologies in a state of confusion regarding WCAG conformance until the working group deems that we've crossed some nebulous threshold of support and thus modifies failures to reflect this. But this doesn't happen until AFTER it's widely in use and, by definition, already supporting accessibility. This means a site that has zero accessibility issues due to modern (or not so modern) technology can fail WCAG today, then pass tomorrow based on a failure/techniques definition change. If WCAG is truly about recommendations and guidelines, it needs to be more forward looking than this.
In short, WCAG is increasingly skating to where the puck is, not to where it will or should be.
And this bring me to my third point, the working group needs to at last determine whether a failure as defined in techniques documents absolutely results in a failure at the normative WCAG level. I've asked several working group members this question and received varying responses ranging from "A page can have many failures, yet still be conformant if it meets the normative success criteria in other ways." to (as expressed just today by a former WCAG editor) "FAILUREs are things that are ALWAYs failures." So, which is it? Until this question is resolved, one cannot know the implications of modifying (or not) any failure language.
And finally, regarding the F65 change itself… at this point, it's mostly irrelevant. My preference would be no or little change. But this is just one of many places in which ARIA and HTML5 techniques conflict with WCAG techniques and failures. Modern, dynamic web accessibility, I believe, can no longer be defined in such simplistic ways – by drawing a techniques/failures line in the sand, so to speak. End user accessibility just doesn't work that way. WebAIM's recommendations will not change – "Make things accessible to your users in the technologies they use, using HTML first, then ARIA, etc. to enhance and support that accessibility when necessary." If followed, and if the page meets the normative WCAG success criteria, whether the page matches increasingly complex and conflated WCAG techniques and failures doesn't really matter.
I can't speak for the entire WCAG WG, just as one of its members. You mention someone told you that "a page can have many failures, yet still be conformant if it meets the normative success criteria in other ways". This is correct only for failures of Sufficient Techniques – hence the disclaimer at the botttom of each Technique that the success criterion might be met some other way.
The Failure techniques (Common Failures) however have no such disclaimer, so a positive test (i.e., a failure instance is found) technically means the page fails WCAG conformance. (However, there is now a paragaph even here saying somewhat vaguely that Techniques are merely informative, which invites the thought that an implict disclaimer is in place even for Failure Techniques).
Having said all that, I think the whole dichotomy of pass/fail is not really helpful for making relevant accessibility assessments (and I repeat this is my personal opinion, not the WG position). There are even Failures as modest F32 ( using spaces to control spacing within a word) – one such word, one i s somewhere, would technically fail the entire page. Also the tests in many Techniques leave ample wiggle room for testers – it often depends on how you (or your organisation) operationalize the test in a WCAG Technique whether you arrive at a pass or fail judgement.
As to the question of modifying the Failure F65, the rationale here is to avoid the situation where a page is fully accessible for a captive audience (using modern browsers and AT) but must be failed according to F65 due to the lack of an alt attribute. Since every test has to reflect the level of accessibility support of the intended audience, this also means that Sufficient Techniques may fail in some cases (public websites) and pass in others (captive audiences, company intranets). If the idea of Failures is still that a positive test means that the page universally fails, it is therefore correct to include all conceivable options of passing the SC (e.g., using aria-label or title where this is safely supported) even if this weakens the Failure Technique and even if this will often be read as an implict invitation to abandon alt for less well supported attributes.
I believe the Byzantine ramifications of fiddling with these Techniques just show that the pass/fail approach is increasingly at odds with the realities of modern dynamic web design. We (Tiffany and I) have tried to make the argument here:
The tail WCAGing the dog? :)
I don't see any problem that should be solved. The alt-attribute is widely known and widely ignored. What about a seldom known attribute? Does anybody think this will be implemented in lightspeed, because it is new?
The standards body should care about real problems not imagined ones. It could be possible that nobody accepts them as intelligent and well-minded people in the future if they discuss already finished discussions again and again.
I do no agree with the proposal for reasons Adrian and Jared have written above.
FYI to all so far, I updated this post with details on how to communicate directly with the Task Force mailing list, even as a non-W3C member. It's at the bottom of this post or you can just go to: http://www.w3.org/WAI/PF/html-task-force#communication
For those following along, the W3C has just answered my primary question by clarifying that a techniques failure (F65, for example) does not always mean a failure of a success criteria, and thus WCAG itself – http://lists.w3.org/Archives/Public/w3c-wai-gl/2013OctDec/0202.html
This certainly makes things much easier as it allows innovation and accessibility via new technologies (such as ARIA) without fear of becoming WCAG non-conformant in the process… at least until there are enough WCAG 'failures' in the wild that result in accessibility support (whatever that means) that the W3C changes the failure language to then allow that technique.
Regardless, the technology being used must be 'supported'. It would be wonderful if the WCAG definition of accessibility support were made intelligible, but I think most people get the idea of what it means.
This clarification also means that the change to F65 is of less importance. If someone uses aria-label today as an alternative for an image, they would match the F65 failure, but could still claim conformance. This doesn't mean this is a good idea, but at least one can innovate and still claim conformance regardless of what a techniques failure indicates.
While not among Adrian's arguments, a primary concern for me is that aria-label (and to some extent title) is screen reader specific and would leave many other users (primarily those that disable images) with an inaccessible image and functionality (if that image has a function).
I am also very strongly against the idea. Alt attributes are the foundations of accessibility and no other solution out there today provides the same level of reliability and benefits from the same level of support from user agents and assistive technologies alike.
"Until such time…" all images on web pages are simply decorations and irrelevant, we need to continue to identify all images with alternative descriptions. After 10 years of beating the drum to get content creators to "add ALT descriptions," I think a lot of folks are finally "getting it." Changing a simple, logical methodology for achieving more accessible web content at this point in time will NOT result in greater compliance and, as others have stated, will potentially create more confusion and even LESS compliance.
PS: Kinda of ironic that I have to fill out a CAPTCHA to post this comment…
Seriously, there was a CAPTCHA? Even logged out of my Google account I don't see a CAPTCHA, though it does prompt me for my linked social account of choice in order to allow the post (and I have not posted from another account). Sorry, man.
I'm also at a loss as to why this is even being discussed. The whole idea of swapping something as robust and widely understood as alt text for an unfamiliar and obscure concept is ludicrous. If you don't want your page to fail because of a missing alt, then use one. Is there a suggestion that using ARIA would be easier? I find myself introducing developers to ARIA all the time as a by-product of testing.
I believe that the damage done to accessibility when some developers start thinking and promoting the idea "I don't need to use alt anymore" will be felt by a lot of people for a very long time.