Description for Icons

[MarcHaunschild]

In Germany we earlier had a test, that demanded textual description for icons, but there were a lot of people (a11y specialists) who criticized this test, because it differed from international rules (wcag, of course).
So the test (BITV-Test for those who know it) changed over the years to get closer to what is actually written in wcag. Although this makes sense, I think we lost a few things that were important for people with certain disabilities.
The reason for a textual description for icons is quite easy: I can't think of a single icon, that everybody would understand. Just take the icons here in this editor: a capital "A" and a bigger capital "A" together on one icon can stand for making texts bigger (or smaller), they mean nothing to people, who can't read, who don't know the latin alphabet or don't see at all. For those, that do not see, there is an aria-label - but what about the broad majority that is able to see? I would never have guessed, that it stands for "Add header text".
To make this short: I think there must be a textual description to make icons like these accessible to everybody.
These buttons here on the top of the editor are not accessible for people using a touch screen or a keyboard and there are not accessible for speech input (and don't have to, because SC 2.5.3 "Label in name" don't addresses graphical buttons, although they of course are user interface components. I think this should be changed also).
I think this is a problem for many people, not addressed by the WCAG yet and I suggest adding it in a future version.

[alastc]

For those that use a mouse there is a tooltip style additional-text, and for those using a screenreader they have labels.

The current gap is that those icons are not focusable without a screenreader, so people using switch access, other keyboard-like inputs or a touchscreen (without a screenreader) cannot access the tooltips.

Whether making them tab-able is a good idea in this case is debatable, as these buttons are short-cuts to typing in markdown. I suspect it would be more hassle to shift-tab back up to the buttons, select one, and then tab back down compared to just typing in the markdown.

However, I'm sure there are other examples where a toolbar is necessary for the usage. The other counter-point is that if a toolbar like this were to add the text as visible by default, that toolbar would not work. You could not fit in the text and icons without making the toolbar less effective at it's core purpose.

So I think the form of SC that could be added (given what else is already there), is something like:

a visible text equivalent for icons is available.

We'd probably need to define icons as something like:

A non-text representation of a function or discrete piece of information, such as a printer representing the 'print' function or a green tick representing 'complete'.

Techniques could include:

• Have text next to the icon.
• Include a pop-over that is compatible with mouse, keyboard and touch inputs (that also meets Content on Hover or Focus).

Does that meet the need?
Also, do you know of any good examples?

[LJWatson]

A note to caution against techniques that recommend using the title attribute or SVG <title> element for this purpose. Neither would be permissable under 1.4.13 Content on Hover or Focus because they're not dismissable, but it's worth mentioning for the avoidance of future problems.

[awkawk]

@LJWatson the popup on title is permissible because of the exception:
Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.

[LJWatson]

Thanks @awkawk. Tooltips still represent a problem though, so exemptions not withstanding, I don't think we should be recommending the title attribute or SVG title element in this context.

[detlevhfischer]

SC 2.5.3 "Label in name" don't addresses graphical buttons, although they of course are user interface components. I think this should be changed also

@MarcHaunschild In these cases, it is unclear what speech input users would be expected to speak. Would they say "Click i", "Click b"? Would the expand to "click italics" or "click bold"? I think the exception stated in the 2.5.3 Understandig text that "text should not be considered a visible label if it is used in a symbolic manner, rather than directly expressing something in human language" is the right way to go. So I am not sure what kind of change you would suggest.

[alastc]

Hi @LJWatson, no one had mentioned title-based tooltips, and I specifially mentioned 1.4.13 in the example technique.

We were using the github style buttons as example, which use a non-title based tooltip that would be fine if it were focusable without a screenreader, and also met 1.4.13. Which is to say not fine at the moment, but conceptually could be, and you'd need some method of adding text without impacting layout.

[LJWatson]

@alastc commented:

no one had mentioned title-based tooltips, and I specifially mentioned 1.4.13 in the example technique.>

No-one suggested anyone had mentioned them.

Title based tooltips are a common way for people to solve this problem in the wild, particularly with SVG icons; I'm just cautioning against us encouraging that practice.

[MarcHaunschild]

@detlevhfischer
My example of the RTE appears to be a tough one. Originally I thought about a Button to change sort order from ascending to descending or a printer symbol on a button to send a page to the printer.
So what I had in mind was more or less the demand of earlier BITV test.
Making a complex component like the rte accessible to input by speech has more challenges than just visible texts for icons, I have to admit - for example choosing text by voice...
Anyway I think a visible text for icons should be mandatory and I like the suggestion from @alastc :

a visible text equivalent for icons is available.

with the usual exception "unless it is essential to be without text" for example in a game, where somebody has to guess what a shape is standing for.

[MarcHaunschild]

Does that meet the need?

Yes, I like it a lot!

Also, do you know of any good examples?

You mean something like this (a real life website with icons and texts next to them):
https://www.bildungsserveragrar.de (german)

Or a tutorial, best practice example?

[DavidMacDonald]

I've drawn up a proposal here
https://docs.google.com/document/d/1HzSsCGelWfz_Z-M7NyUzJOvl1A1kAStyl8epYdpZhoA/edit?usp=sharing

[alastc]

Just to update: We worked through David's proposal in various ways, and really struggled to get a good enough coverage of common scenarios.

For those with access the survey results are here, but the nub of the issues was:

It is relatively easy and useful to provide the extra information in a desktop context (with mouseover), but the techniques used to do that don't necessarily work for touch-screens, and sometimes actively make the interface worse.

Considering four scenarios:

1. An active icon (e.g. button) with mouse usage.
2. An inactive icon (e.g. label for something) with mouse usage.
3. An active icon (e.g. button) on touchscreen.
4. An inactive icon (e.g. label for something) on touchscreen.

Applying a mouse-over style tooltip for scenario 1 is straightforward, but then on a touchscreen (3) you can't get the information without activating the control or needing to tap-twice (which is flaky). That is not a desirable approach in general.

Overall, we couldn't find a way of making that work as a (potentially legal) requirement across different sites & devices.

Some good work went into this, I wonder if the techniques could be used as advisory techniques somewhere? In some contexts they would be good to do, just not all.