got nerdsniped yesterday, in the process of trying to determine what the Capital C Correct way to implement the following UI is, in both a semantically correct and accessible way:
Success
seems pretty straightforward, right? an icon, and some text next to it. how hard can it be? i mean, i just did it right there. surely it can't be that difficult.
turns out the actual specifications are surprisingly vague on this.
so we've got a little status thingy, with a checkmark icon and the text "success". combine all that with the green colouring and it's pretty clear to a sighted user that this is meant to represent some sort of successful action. we can do that with some markup like this (with styles omitted, for simplicity):
<img src="...">
<span>Success</span>
and that's all well and good. but what about users with vision impairments, that rely on a screen reader to tell them about what's on screen? surely we should make sure they have a good experience on our site too. if we use the same snippet as above, a screen reader will read that UI out to the user as:1
Image. Success
hmm. that's not bad. it gets across that this is a success status, which is good. but there's that "Image" at the start that's not really necessary. sure, there's an image there, but that's not important - we care about the "Success" part, not the "Image" part. can we fix that?
an initial attempt might be to reach for the trusty ol' alt attribute. that should really be there, anyway - the HTML spec states that an img without an alt attribute should be treated as "might be a key part of the content, and there is no textual equivalent of the image available", which is not what we have here. maybe something like...
<img src="..." alt="Success">
<span>Success</span>
how does that read?
Success image. Success
huh. well that's worse. not only did we not get rid of the unwanted "Image", we now have a redundant "Success" in there as well. how can we make screen readers skip over the image?
going back to the HTML spec, there's some useful guidance in there for this situation:
In some cases, the icon is supplemental to a text label conveying the same meaning. In those cases, the alt attribute must be present but must be empty.
ok, let's see what that gets us...
<img src="..." alt="">
<span>Success</span>
Success
neat! that's pretty good, reads out what we want it to read. and it looks perfectly fine on the page, too. but can we do any better?
with alt="", that leaves us with an image that doesn't have an accessible name. granted, screen readers also won't focus that image, so as far as the screen reader is concerned, it doesn't exist - you don't really need to worry about an inaccessible icon getting read out to users. however, no accessible name still isn't good, right? indeed, according to WCAG 2.2, that would be a failure - the icon doesn't have a text alternative, there's no text programmatically linked to it. so we should probably make sure the icon and the text are linked.
according to WCAG Technique ARIA102, we can use aria-labelledby with an ID of an element somewhere else providing a label to use as an accessible name. neat! so, something like...
<img src="..." alt="" aria-labelledby="success-label">
<span id="success-label">Success</span>
if we use firefox's super handy accessibility devtools panel, we can indeed see that the image now has the accessible name "Success". awesome! now we have a fully standards-compliant, accessible UI, that provides a good experience for both users that view the page's visual content, and users that utilize a screen reader.
...right?
Success image. Success
fuck.
turns out that if you give an image an accessible name, screen readers treat that as if that name was in the alt attribute. makes sense, since that's pretty much what alt is doing under the hood. so maybe we shouldn't be setting an accessible name for the icon? it displays perfectly fine to both users, anyway. don't fix what aint broke, y'know?
it's just weird that this seems to violate WCAG as it currently stands. although, the Non Text Content success criterion does have this little carveout:
If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.
where "pure decoration" is defined as:
serving only an aesthetic purpose, providing no information, and having no functionality
i mean... a checkmark icon does provide some information, right? the checkmark is telling the user "yeah! success! the thingy was successful!". granted, it is redundant - the text "Success" right next to it does the same thing, and the green colouring helps to emphasize that "successful" vibe (for users without colour vision impairments, at least). but the checkmark is still a useful indicator - the icon is another visual prompt to promote the "Success" message of the textual prompt. i don't think this icon would fall under this category. maybe it does? idk.3
and besides, what good is a standard if the standard provides shit results, anyway? who cares if this is, strictly speaking, a WCAG violation - trying to fit to the WCAG guidelines in this scenario results in a suboptimal experience for users accessing the page with a screen reader, so like... fuck it??? just break standards and go for what actually works best in practice. not like this is the first time WCAG criteria turned out to be a bit shit. either the standards didn't define this correctly, or screen readers are implementing the standard wrong, or i'm just missing something buried deep within the bowels of the standards - in any case, it seems like the readers could do with a bit of extra clarity.
anyway, for posterity's sake, here's the snippet that produced the best results for both users:
<img src="..." alt="">
<span>Success</span>
sigh. a11y ain't easy. makes sense, "easy" doesn't have 11 letters. but "complicated" sure as hell does.
-
for the purposes of this post, i'll be testing with Orca, since i'm on a linux machine. results may differ across screen readers, such as JAWS, NVDA, or VoiceOver.
-
a quick sidenote - if you haven't got the WCAG Quick Reference bookmarked, do it now. this is a great resource to reference if you ever find yourself asking "how do i do xyz in a way that meets accessibility standards" or "what should i be checking to ensure my page is accessible", this has got everything you'll need - success/failure criteria, implementation guides, and more.
-
all of this chost is based on what i've been able to find in WHATWG HTML, ARIA and WCAG specifications. it's entirely possible that i've missed something here. if you know something i don't, please drop a message in the comments. i would love to be proven wrong on this one.
