Image alt Exception Change Re-Re-Re-Requested

HTML5 logo — I am the 'alt,' not the 'title' This post is an unexpected follow-up to my post Image alt Exception Change Re-Re-Requested (note one fewer “re-”) from June 2012. Back then, some had called into question the need for alt attributes to be required and ubiquitous on all img tags.

Well, guess what — alt is back under review.

The Web Content Accessibility Guidelines (WCAG) working group is reviewing (and soliciting feedback on) changes to determine how a page may fail WCAG Guideline 1.1 Text Alternatives, which outlines how a page uses the alt attribute for images. This also means changing the techniques authors may use to pass Level A validation for WCAG SC 1.1.1.

To simplify, the discussion is centered on allowing authors to omit alt if the author uses aria-label, aria-labelledby, or title attributes. For example, the following three examples would all be valid:

<img src="fox.png" title="Photo of a fox reading aloud from a book.">
<img src="fox.png" aria-label="Photo of a fox reading aloud from a book.">
<img src="fox.png" aria-labelledby="FoxPic">
     <p id="FoxPic">Photo of a fox reading aloud from a book.</p>

David MacDonald has already captured the arguments for and against that are already being bandied about, which I reproduce here:

Arguments for the Change

Arguments against the Change

Where You Come In

You don’t have to be a part of any standards body to weigh in with your opinion. You can leave comments here and I will happily carry them back to those discussing this (even if I don’t agree). You can also let me know on Twitter or you can let Steve Faulkner know, as he is one of the HTML editors.

My Opinion

It is my understanding that ARIA was intended to cover the gaps where HTML didn’t already have elements or features to enable accessibility. Moving to supplant an accessibility feature that is widely understood and broadly supported with one that most web developers don’t understand seems like a step backward, especially when that specification should fall away in time.

There is also the case to be made for the current status of WYSIWYG editors and code generating features of CMSes. It’s taken more than a decade, but for the most part they have support for alt. It seems unlikely that these tools will implement logic to exclude alt when there are valid aria- or title attributes, so they will probably still include alt regardless.

Revisiting HTML elements and attributes is warranted and should be part of the process. We’ve removed oddities such as hgroup and re-instated valuable bits like time. However, I am not sure why alt seems to get an annual review when it has clear history and use cases.

My very quick responses to the arguments outlined above:

Alternatives to img work in assitive technology

I am not an AT user, so I cannot address this other than to say that it is my understanding that the alternatives work inconsistently across AT whereas alt has a far more consistent experience.

ARIA says these attributes should get an accessible name

That may very well be the case, but should itself doesn’t require it.

Easier to teach aria-label on everything, rather than requiring a label on form fields and alt on images

I think there is a false dichotomy here. In modern development shops, the team making forms isn’t necessarily the one placing images. Labels have a clear functional association that mirrors desktop software experiences. Alternative text for an image is not a label, though sometimes it may be considered such. This also implies the label element itself may be replaced with aria-label, which isn’t the point of ARIA.

Missing alt can fail an entire page

As far as I am concerned, if your entire page fails accessibility validation because of a missing alt, then that is a valid failure. It stands to reason that some items should fail regardless of how perfect the rest of the code may be. Softening the failing power of alt can be a separate discussion, but allowing it to be bypassed seems like a blanket solution. I can’t imagine an entire new building is considered accessible even though there is no ramp to bypass the front steps.

Since HTML5 allows a figure/legend combination to bypass alt

This goes back to my original resistance to allowing any exceptions for alt. I worried that any exceptions would be used as a wedge to ultimately tearing down alt. As such, I don’t consider this a valid argument. If anything, it should be used as an argument to re-examine the value of making exceptions for alt and perhaps rolling them back (counter-suit!).

Related (on this blog)

Update: November 27, 2013

It is possible for W3C non-members to post their opinions/thoughts to the Accessibility Task Force list (one of the lists where this being discussed). Source:

All the info you need to respond (reproduced here):

Update: March 11, 2014

Today the W3C posted to its blog WCAG Techniques for image text alternatives, which reviews some of what’s above. To distill it down:

The result of these two changes is that the Working Group is recognising that authors need and want to use ARIA attributes. Given the evolving level of accessibility support the group then decided to:

  • Allow the responsible use of ARIA attributes for images when accessibility supported (by no longer failing images using aria attributes even if they do not use alt also).
  • Stop short of fully recommending only the use of ARIA attributes on images (by not including a sufficient technique that would encourage this practice).

Update: April 8, 2014

The SSB Bart Group asks the question, Is the Alt Attribute Dead?, and ultimately suggests that no, it is not. As developers, we should keep on using it as it’s a simple aid that we don’t need to complicate with the latest changes. However, SSB Bart does remind us of the following order in which the HTML Accessibility API exposes alternative content:

  1. Use aria-labelledby
  2. Otherwise use aria-label
  3. Otherwise use alt attribute
  4. Otherwise use title attribute
  5. If none of the above yield a usable text string there is no accessible name

Update: April 15, 2014

Steve Faulkner outlines the divergent requirements between WCAG 2.0 and HTML 5 in the post Short note on alt in HTML.

12 Comments

Reply

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.

Graham Armfield
Coolfields Consulting

Anonymous; . Permalink
Reply

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.

Reply

Hi Jared,
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:
http://www.w3.org/WAI/RD/2011/metrics/paper7/

Reply

The tail WCAGing the dog? :)

Reply

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.

Reply

I do no agree with the proposal for reasons Adrian and Jared have written above.

Reply

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

Reply

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).

Reply

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.

@dboudreau

Unknown; . Permalink
Reply

"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…

In response to John Brandt. Reply

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.

Reply

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.

Grant Broome; . Permalink

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>