W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2013

RE: UNS: RE: UNS: Re: WCAG considering amending F65 to NOT fail missing ALT text if title or aria-label is present

From: Adrian Roselli <Roselli@algonquinstudios.com>
Date: Tue, 26 Nov 2013 14:25:42 +0000
To: Janina Sajka <janina@rednote.net>
CC: Steve Faulkner <faulkner.steve@gmail.com>, David MacDonald <david100@sympatico.ca>, HTML Accessibility Task Force <public-html-a11y@w3.org>, WCAG WG <w3c-wai-gl@w3.org>, "public-comments-wcag20@w3.org" <public-comments-wcag20@w3.org>, Gregg Vanderheiden <gv@trace.wisc.edu>, "kirsten@can-adapt.com" <kirsten@can-adapt.com>
Message-ID: <0CB063710346B446A5B5DC305BF8EA3E2DECCF1F@Ex2010MBX.development.algonquinstudios.com>
(being brief at the top to not drag this off topic, but I want to honor Janina with a response; my @alt feedback below)

> From: Janina Sajka [mailto:janina@rednote.net]
 [...] 
> So, I cannot accept that "the community" is being excluded by W3C
> discussion, such as we are now conducting regarding alt and its several ARIA
> alternatives. Rather, what is happening is that we, the participants of this
> dicussion are being denied your views. You've taken them off list and have
> not shared them here. Why? You say you have two followers. There are
> more people CC'd on this email (and on your email) than that. Why would
> you write substantive concerns to two followers but neglect to share them
> here?

The "two followers" comment was tongue-in-cheek. My fault for being too casual on that. As for the rest, I defer to Léonie's feedback, it's better written than mine would be.

> If your answer is that you've shared them on the WCAG list, may I point out
> that this conversation was broadened beyond that list this past Friday? Surely
> a pointer to such a WCAG posting would be a reasonable consideration for
> those of us not reading the WCAG list?

I am not on the WCAG list. Frankly, after a year of participation in the W3C, I don't even know where to look to make that happen. I will poke around on my own time.

> I did read your blog. I have several responses I'd like to make, but I also want
> to honor the others here in W3C who are considering this question now, so I
> will not respond on your blog. If you will post your concerns here, I will
> respond to you then. My responses will suggest certain factual errors and
> certain assumptions I would challenge.
> Interested? I think others would be as well.

I never have a problem stating my opinion on the lists, though I do like to massage them a bit first (the blog post was helping me do that).

The bullet points in the blog post came from David MacDonald's post on Friday [1]. Half of that post is just a recap of the current situation.

As for 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.

This doesn't necessarily create a problem on its own, but presenting authors with so many options can muddy the waters and create accessibility issues as David outlines in his email this morning [2].

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.

For the argument that it is 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.

For the argument that a 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.

For the argument that 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!).


1. http://lists.w3.org/Archives/Public/public-comments-wcag20/2013Nov/0005.html
2. http://lists.w3.org/Archives/Public/public-html-a11y/2013Nov/0087.html
Received on Tuesday, 26 November 2013 14:26:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:32:54 UTC