Image alt Exception Change Re-Re-Re-Requested
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
- These alternatives on the
img element work in assistive technology; - The ARIA spec says these attributes should get an accessible name in the API;
- They say it’s easy to teach beginner programmers to just always use an
aria-labelon everything, rather than requiring alabelon form fields andalton images; - They feel that F65 is overly strong since it can fail the entire page for a single missing
alt(regardless of the validity of the rest of the page), and they would like to soften it to allow those other valid elements to carry the page; - HTML5 allows a
figure/legendcombination instead ofalt, so they feel WCAG will have to change F65 regardless in order to allow afigurewith alegend, and that helps open the door to this discussion.
Arguments against the Change
aria-label,aria-labelledby, andtitle, are not really suitable attributes forimgalternative text because they imply a label or title, rather than alternate text, so they are not semantic equivalents;titleis not well supported;- Some feel that the ARIA spec is not in any way suggesting these as replacements to
alt; - ARIA instructs authors to use native HTML where possible, and they could not come up with viable use cases for omitting
alttext; - There are hundreds of millions of dollars invested in current evaluation tools and methodologies, and this would represent a major departure from one of the most basic accessibility conventions, one that is almost as old as the web and is the “rock star” of accessibility;
- It could cost a lot of money to change guidance to developers and muddy the waters on a very efficient current evaluation mechanism;
- When the
figure/legendcombination is supported by assistive technology we can amend F65, but that is a different issue and the semantics of this construct are OK for text alternatives, rather than thearia-label,aria-labelledby, andtitleoptions; - It may cause some confidence problems to WCAG legislation because it represents a strong loosening to a fundamental Success Criteria, an unnecessary change that doesn’t help the cause of accessibility, but just complicates things;
altis better supported;- The
alttext appears when images are turned off; - Initial twitter feedback from the community is strongly against changing this failure.
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)
- Image alt Attributes Not Always Required in HTML5, April 19, 2011.
- More on Image alt Requirement in HTML5, May 2, 2011.
- Image alt Exception Change Re-Re-Requested, June 11, 2012.
- Still Guessing on Accessibility, January 31, 2013.
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:
@patrick_h_lauke anyone can mail public-html-a11y, it just may take some time to show up on list http://t.co/sFe84xMDio :) cc @stevefaulkner
— Mark Sadecki (@cptvitamin) November 27, 2013@chaals @patrick_h_lauke @w3c all a11y TF moderated emails are being redirected to the list as quickly as they can, w/in minutes of posting
— Mark Sadecki (@cptvitamin) November 27, 2013All the info you need to respond (reproduced here):
- E-mail discussions taking place on the HTML Accessibility TF’s W3C mailing list, public-html-a11y.
- Weekly (or less frequently, as needed) HTML Accessibility TF teleconferences with minutes distributed to HTML Accessibility TF mailing list (archive);
- Sub-group teleconferences with minutes distributed to HTML Accessibility TF mailing list;
- The HTML Accessibility TF Wiki.
- The HTML Accessibility TF may use Web-based surveys instead of email to poll group opinion.
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
altalso).- 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:
- Use aria-labelledby
- Otherwise use aria-label
- Otherwise use alt attribute
- Otherwise use title attribute
- 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
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
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 . 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.
Leave a Comment or Response