Ambiguity of the term "character" and its impact on internationalization and testability

[murata2makoto]

The term “character” as used in accessibility-related specifications (and Draft Definitions of the Text and Wording subgroup) raises a fundamental concern. In the context of Unicode, character is a highly nuanced and context-dependent concept, and it cannot be assumed to correspond to a unit that users perceive, read, or manipulate as a single entity. Treating character as a self-evident unit introduces ambiguity at the normative level and undermines the technical soundness of the specification.

Unicode itself explicitly distinguishes between encoded units and user-perceived text. A single unit that users experience as “one character” may consist of multiple code points, as in the case of combining character sequences, surrogate pairs, variation selectors, or emoji sequences. This distinction is formally documented in Unicode Standard Annex #29: Unicode Text Segmentation
https://www.unicode.org/reports/tr29/

which defines both legacy grapheme clusters and extended grapheme clusters precisely because earlier assumptions about characters proved inadequate. The existence of these two models already demonstrates that “character” is not a stable or self-explanatory concept even within Unicode.

However, even extended grapheme clusters are explicitly defined as a segmentation heuristic, not as a definitive model of user perception or comprehension. They provide a lower bound for avoiding incorrect splitting of encoded text, but they do not capture higher-level, language-dependent textual units that are directly relevant to accessibility.

This limitation is particularly evident in documents using CJK scripts and ruby annotations. In such contexts, a base ideograph and its associated ruby annotation may together form a single meaningful unit for reading, navigation, comprehension, or text-to-speech output. Treating these components as independent “characters” can fragment information that users naturally and legitimately process as a whole. Unicode grapheme clusters do not and are not intended to model such relationships.

As a result, accessibility requirements that rely—explicitly or implicitly—on the notion of “character” face a twofold problem. First, they fail to specify whether character refers to a code point, a legacy grapheme cluster, an extended grapheme cluster, or something else entirely. Second, even if grapheme clusters were assumed, they remain insufficient for capturing accessibility-relevant units in many non-Western writing systems.

It may be argued that, by “character,” the specification intends to mean a user-perceived character. This clarification does not resolve the issue. User-perceived character is not a defined term in WCAG, Unicode, or any referenced normative specification. Without an operational definition, the phrase merely replaces one undefined term with another. The critical question therefore remains unanswered: what is a user-perceived character, and how is it determined in a testable and interoperable manner?

Accessibility specifications must be implementable, testable, and interoperable across languages, scripts, platforms, and assistive technologies. Reliance on an undefined notion of “character”—whether qualified as “user-perceived” or not—fails to meet these requirements. This is not a matter of editorial clarity but a substantive defect in the conceptual foundation of the specification.

Unless the term character is rigorously defined or its use reconsidered, accessibility requirements risk being formally correct while practically indeterminate, particularly for users of non-Western scripts. This objection concerns the validity of the specification as a global accessibility standard, not the choice of any particular technical remedy.

[murata2makoto]

As an additional clarification, the concern raised in this issue is directly aligned with both the Unicode Character Encoding Model and the W3C Character Model.

The Unicode Character Encoding Model, as described in Unicode Technical Report #17, treats a character as an abstract element of the character repertoire, distinct from its encoded representation (code units or code points) and from its rendered appearance (glyphs). This model explicitly allows a single unit that users perceive, read, or manipulate as one textual entity to be composed of multiple encoded characters, such as combining character sequences, variation selectors, surrogate pairs, or emoji sequences.

This distinction is further articulated for Web specifications in the Character Model for the World Wide Web, which cautions against the unqualified use of the term “character” and emphasizes that specifications must clearly distinguish between encoded units and higher-level concepts that users perceive or interact with. The document explicitly warns against assuming that “character” corresponds to a user-perceived or user-manipulated unit.

Building on these character models, Unicode Standard Annex #29 defines grapheme clusters and other text segmentation units as purpose-dependent, algorithmic constructs used for specific operations such as cursor movement, text selection, or boundary detection. These constructs are explicitly not normative definitions of user-perceived characters.

In this light, the issue raised here is not about the correctness of Unicode segmentation algorithms, but about the normative use of the term “character” in accessibility-related specifications without specifying the intended level of abstraction. Such usage risks conflating distinct layers of the Unicode and W3C character models and introduces avoidable ambiguity.

[xfq]

As an additional clarification, the concern raised in this issue is directly aligned with both the Unicode Character Encoding Model and the W3C Character Model.

Please note that we are no longer maintaining this document. For updated information, please see https://w3c.github.io/bp-i18n-specdev/#characters

[alastc]

@murata2makoto wrote:

In the context of Unicode, character is a highly nuanced and context-dependent concept, and it cannot be assumed to correspond to a unit that users perceive, read, or manipulate as a single entity.

In general, definitions in WCAG are not intended to match or replicate other technical specs. If that were the intended meaning it would be linked to and explicit. WCAG does not assume text is unicode.

WCAG doesn't define "character", but I think the most relevant use is in the definition of text:

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

In this context, the dictionary definition is what we'd refer to (e.g. "A written or printed symbol or letter").
Characters are also used in relation to keyboard presses that result in character input.

For accessibility requirements we need to distinguish written language from other type of information. We are not trying to split characters, we are not worrying about grapheme clusters, what matters for the accessibility requirement is whether the user perceives text (visually and/or programmatically).

Second, even if grapheme clusters were assumed, they remain insufficient for capturing accessibility-relevant units in many non-Western writing systems.

Could you expand on what an "accessibility-relevant unit" is and how it would apply in accessibility requirements? Historically WCAG hasn't tried to split things down to the character level. It has tried to be technology-neutral and use requirements that are not specific to that level. E.g. Something conveyed visually is also conveyed programmatically. It feels like that flexibility should allow for any orthography, but perhaps I'm missing something.

The critical question therefore remains unanswered: what is a user-perceived character, and how is it determined in a testable and interoperable manner?

I'm not sure why that is a critical question? The type of requirements we would have are more like: When there is user-perceivable written text, then it must do X. (E.g. be programmatically available, or the size must be manipulable, or it has sufficient contrast.) That users can perceive the text is enough for our purposes. In fact, if we tried to use a technical definition that would create loop-holes, as people could hide "text" in image formats.

Unless the term character is rigorously defined or its use reconsidered, accessibility requirements risk being formally correct while practically indeterminate, particularly for users of non-Western scripts.

Having read the issue several time, I still do not understand why there needs to be a definition of character or what issue it causes for non-Western scripts. I think the missing bit is how it would affect the accessibility requirements or testing of those requirements.

In the context of the requirements that reference "text", I'm really struggling to see how the use of "characters" is an issue.

• § 2.1.2.7 Visual information identified talks about "onscreen text" within video content.
• § 2.1.3 Non-text alternatives non-text isn't text, so not relevant.
• § 2.2.1 Text appearance There are lots of potential i18n issues here, but it is based on the perception of visually rendered text, it does not distinguish types of characters.
• § 2.2.2.1 Text detectable is asking for programmatic detection.
• § 2.2.2.3 Text appearance not relied on is asking for style properties to be programmatically available.
• § 2.2.3 Clear language is based on language used rather than types of character.
• § 2.11.1.3 Conversational support available is asking for both text and speech formats to be available.
• § 2.12.2 Control text is asking for user-manipulation of (all) text.

What matters for these requirements is that there is written language presented to the user, not what makes up the characters.

Would it help to add a note to the text definition saying something like:

the term "characters" in this definition is not referencing Unicode, it means user-perceivable characters presented by the content in any format.

I think there is a big risk of us talking past each other, so I'd welcome input from anyone who can see both angles and try to bridge the gap.