Exception for use of symbols as visible label in regard to 2.5.3 Label in Name

[mbgower]

Another consideration for what exactly should be considered relevant when figuring out success for meeting 2.5.3 is the use of symbols on buttons and icons.

An example would be buttons in a rich text editor. In github, these buttons include "AA", "B", "i", an open double quote and a set of coding brackets ("<>").

Although I question the wisdom of some of the accessible names for these buttons assigned through aria-label such as "Add bold text, <ctrl+b>", I think it is nonsensical that "AA" should be required as the accessible name.

Another example would be where someone has used a ? or ! symbol as a button label. I think it is defensible that "More information" and "Caution" are not only more meaningful alternatives but should not result in a failure of 2.5.3. (This is leaving aside the question of whether the use of the symbol alone as a label is a good design decision.)

I am going to propose that the use of symbols or character keys employed as symbols should be excluded from consideration as part of the visible text label for the purposes of meeting 2.5.3.

[mbgower]

"Symbolic text characters" in 1.4.5 Images of Text also addresses questions about use of text characters as symbols and the notion of the characters not forming a sequence that expresses something in human language:

A form allows users to enter blocks of text. The form provides a number of buttons, including functions to style the text and check spelling. Some of the buttons use text characters that do not form a sequence that expresses something in human language. For example "B" to increase font weight, "I" to italicize the text and "ABC" to check the spelling. The symbolic text characters are included as gif images which do not allow the text characteristics to be changed. The buttons have text alternatives.

[mraccess77]

Interesting -- I think it's saying that these aren't text for the purposes of SC 1.4.5. But admitted these examples in the understanding are not clear which in the bullet list is a example pass and what is an example fail. I tend to recall that when this discussion came up with other symbols before they weren't considered text and so greater than would not be text either and thus not subject to 2.5.3. This makes some sense because it's not the name we want but the meaning. For example a triangle for a play button -- we don't want the acc name to be triangle -- but instead play. we don't want to pipes to be "pipes" but instead "pause".

[alastc]

Indeed, I would not have considered those examples as 'text' (as defined in WCAG), so perhaps adding a similar disclaimer to 2.5.3 from 1.4.5 is in order. I believe you're updating this at the moment @mbgower?

There is a gap, I.e. what should the accname of those symbols be so that people can predict it, but that's best dealt with at a (localised) best-practice level rather than guidelines.

[mbgower]

The discussion in #592 is relevant to this topic as well. @alastc there makes the point that the definition of "text" hinges on the characters "expressing something in human language"

sequence of characters that can be programmatically determined, where the sequence is expressing something in human language

Since 2.5.3 states

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

the argument is that the text must have meaning (i.e., be words), and where text is used symbolically or as a crude replacement for a visual cue, such as ">" intended to mimic the visual appearance of a conventional play button arrow, it is not in fact "expressing something in human language"

[mbgower]

@mraccess77 can you please correct this in your comment

I think it's saying that these aren't text for the purposes of SC 1.4.3.

I believe you mean SC 1.4.5.

[mbgower]

@mraccess77

There is a gap, I.e. what should the accname of those symbols be so that people can predict it, but that's best dealt with at a (localised) best-practice level rather than guidelines.

I don't think I'd technically describe that as a gap. If we are saying that ">" is not text, then a control labelled by it does not in fact have a visible text label for the purposes of 2.5.3, and so can have any appropriate string for its accessible name. I'm going to suggest as a piece of guidance that what the symbolic text represents -- which is normally its function -- should be its name. So for the various examples in this issue:

• play (or "next"; I've seen the ">" used for that as well)
• bold
• italics
• heading
• quote

[mbgower]

Okay, here's a similar question. What about mathematical symbols?
A>B or 5-3

I think I'd argue that when used as part of a mathematical expression, punctuation has 'human language' expression and the name should match the label.

[mbgower]

Similarly there was a question about whether the name for a label of "5-3" could be "five minus three". I think my comment would be 'why not make it the same string and save yourself the headache?' Converting the label to a name perceived by an author as being more useful seems risky. Some may agree with it; others may not. I do know an non-visible English name may potentially cause issues with Internationalization, where using the visible mathematical expression would not.
Giving it a description (via title or whatever) of "five minus three" may be useful to some users, but that is not a requirement of 2.5.3

[alastc]

I don't think I'd technically describe that as a gap. If we are saying that ">" is not text, then a control labelled by it does not in fact have a visible text label for the purposes of 2.5.3

I didn't mean a gap for 2.5.3, but an overall gap in accessibility for people using voice input, i.e. how do they know what the accname of a symbol is?

So it's a gap in that there is nothing covering symbol usage in controls for voice input. (One that would ideally be filled by voice input have a feature to overlay the names of controls via a simple command.)

I think I'd argue that when used as part of a mathematical expression, punctuation has 'human language' expression and the name should match the label.

I agree with that, and would hope that voice input would deal with it, there are certainly commands for punctuation and symbols.

[mbgower]

This was addressed in updates to the Understanding Label in Name document, which was updated via #614