The first consideration is: do you really? If you can, having text next to your icons is proven over and over again to be the most accessible and clearest UX (see Apple’s latest blunder). But if you need to (and I get it, sometimes you need to), Sara Soueidan and Scott O’Hara have a pair of articles that nicely lay out all the options and present actual research on this topic.
- Sara Soueidan: Accessible Icon Buttons
- Scott O’Hara: Contextually Marking up accessible images and SVGs
If you just want to be told what to do, I’d go for the just use some text in the button approach:
<button aria-expanded="false" id="menu-trigger">
<svg viewBox="0 0 32 32" width="32px" height="32px"
aria-hidden="true" focusable="false">
<!-- svg content -->
</svg>
Menu
</button>
Sara says There is no One Way to Rule Them All, but it does seem like you really need to use actual text inside that button and either hide it or override it somehow. SVG alone has no rock solid way to provide an accessible name to a button or link.
Funny how long this has been a tricky pattern to get right.
I’m sure that including an
aria-label
on thebutton
element is a possible way to go in keeping it looking nice but also accessible. I’d argue though that you should always include text to reduce the cognitive load of users wherever possible.I agree, I think it is best to include some descriptive text in the button. You can always wrap the text in a span tag and then visually hide it with a screen reader only class. That way if the site fails to load CSS or the user just wants to see the plain HTML without CSS or JavaScript the browser will still display the text in the button.
What about the title attribute on the button?
Wouldn’t that be the perfect use case for it? It provides a “tooltip” if the user isn’t familiar with the icon and gives screen readers a meaningful title.
RE: Title / Tooptips are not considered accessible:
https://www.w3.org/TR/html/dom.html#the-title-attribute
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/title
And should not be relied on. That being said, with some searching there are workarounds to make tooltips accessible:
https://inclusive-components.design/tooltips-toggletips/ (your mileage may vary) But my thoughts would be the same as for PDFs only use them when necessary (not just because).
Yes, if you depend on a tooltip. But in the examples made by Sara Soueidan, there would be no tooltip at all.
What I tried to say is, why is the title attribute not even considered as a way to give screenreaders a meaningful label?
The title attribute is not a perfect solution for everyone, but it would help for sighted users with a pointing device. Keyboard users need some additional :focus styles, only touch users will be left out and in the need of a javascript solution.
But as far as progressive enhancements goes, I think the title attribute is the best bet. My only question is, why was the title attribute not tested? Does screenreaders ignore the title attribute (because of seo overuser)?
You single out Apple in your comments about the external articles, but to be fair, Google really pushed the beginnings of the trend in it’s web services long before Apple jumped on board.