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, 2013
All 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.
0 comments:
Post a Comment