WAI-Adapt: Symbols Module

W3C Candidate Recommendation Snapshot

More details about this document
This version:
https://www.w3.org/TR/2023/CR-adapt-symbols-20230105/
Latest published version:
https://www.w3.org/TR/adapt-symbols/
Latest editor's draft:
https://w3c.github.io/adapt/symbols/
History:
https://www.w3.org/standards/history/adapt-symbols
Commit history
Implementation report:
https://w3c.github.io/adapt/symbols/reports/
Editors:
(Invited Expert)
(Benetech)
(Invited Expert)
(W3C)
(W3C)
Richard Schwerdtfeger (Knowbility) (Editor until October 2017)
Feedback:
GitHub w3c/adapt (pull requests, new issue, open issues)

Abstract

This specification provides web content authors a standard approach to support web users with various cognitive and learning disabilities who:

The technology described in this specification is intended to be used to programmatically transform the appearance of typical web content including form controls, icons, and other user interface elements into a rendering incorporating an individual user's preferred AAC symbols. The W3C Augmentative and Alternative Communication (AAC) Symbols Registry specification [aac-registry] provides the required mappings between concept values used by content authors and the user's preferred AAC symbol set representation of that concept.

This WAI-Adapt: Symbols Module is a component of the WAI-Adapt series introduced in the WAI-Adapt Explainer document [adapt].

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document was published by the Accessible Platform Architectures Working Group as a Candidate Recommendation Snapshot using the Recommendation track.

Publication as a Candidate Recommendation does not imply endorsement by W3C and its Members. A Candidate Recommendation Snapshot has received wide review, is intended to gather implementation experience, and has commitments from Working Group members to royalty-free licensing for implementations.

This Candidate Recommendation is not expected to advance to Proposed Recommendation any earlier than 15 June 2023.

To comment, please open a new issue in the WAI-Adapt GitHub repository, If it's not feasible for you to use GitHub, send comments in plain text e-mail to: public-adapt@w3.org. Please include your comments in the body of the message, not as a binary attachment which we will be unable to process. Please send comments by 28 February 2023.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 2 November 2021 W3C Process Document.

1. Introduction

This section is non-normative.

1.1 Background

This specification module enables authors to add semantic information about content at the element level, in order to facilitate a more familiar and comprehensible interface for the individual user who requires AAC symbols support. Final renderings — generated via helper apps or 3rd-party tools — are ultimately defined by the user's configuration settings.

The goal of the attribute and values described in this specification is to enable personalized communication and web content interaction for the individual user. This specification includes facilities to:

WAI-Adapt is more fully introduced in our WAI-Adapt Explainer [adapt].

1.2 WAI-Adapt: Symbols Module

WAI-Adapt: Symbols Module is the first part of the WAI-Adapt technical specification, which provides WAI-Adapt and vocabularies that can be used to mark-up web content with additional semantic information, enabling user agents to augment or adapt content to various user-scenarios based on the user’s personalization settings or preferences. The Symbols Module allows authors to enhance web content by providing additional information about the meaning of specific parts of the content. User agents use these semantics to augment or adapt content to the user's preferred symbol set. This helps users with varying needs better understand the content.

1.3 Vocabulary Structure and Implementations

The vocabulary in WAI-Adapt: Symbols Module is constructed of properties and their values. Please see our WAI-Adapt Explainer.

The vocabulary implementation included in this module specification is available at our implementations wiki page.

1.3.1 Properties

Properties are the main units of WAI-Adapt types supported by the vocabulary. A given property supports a specific type of personalization. That property would only be used once on a given piece of content, but multiple different properties could be used on the same piece of content to address different needs.

1.3.2 Values

Values provide the specific WAI-Adapt information for the property. The possible values for each property are elaborated in the definition of the property in the modules. Some properties require the value to come from a predefined list of possible values, others can accept arbitrary strings, and some may accept multiple values. The attribute value may be one of the following types:

ID reference
Reference to the ID of another element in the same document
ID reference list
A list of one or more ID references.
integer
A numerical value without a fractional component.
number
Any real numerical value.
string
Unconstrained value type.
token
One of a limited set of allowed values.
token list
A list of one or more tokens.
URI
A Uniform Resource Identifier as defined by RFC 3986 [RFC3986] It may reference a separate document, or a content fragment identifier in a separate document, or a content fragment identifier within the same document.

Note that the attributes and values in this specification do not override the semantics exposed in the accessibility tree, but rather augment them. In the case of conflict between an element's semantics and the attribute values, validation algorithms should issue a warning but not an error.

Note
Since implementations have not yet been finalized, any examples in this document are illustrative only, and are provided to help in understanding the concept. All examples will be updated once implementation examples are finalized.

1.4 Use Cases and Requirements

The Requirements document for WAI-Adapt describes use cases and requirements which, in turn, are derived from the user scenarios and use cases published in the W3C Note, Making Content Usable for People with Cognitive and Learning Disabilities. This specification module provides one key component to fulfil those requirements related to adapting content to support AAC symbols.

2. Terms

This document uses a number of specific terms related to various cognitive disabilities and related user-needs. Those terms have been defined by the Cognitive and Learning Disabilities Accessibility Task Force. See the COGA Glossary for specific definitions.

3. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY and MUST in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This section is normative.

The content of WAI-Adapt Symbols consists of numeric values for the adapt-symbol attribute for any span of text and taken from the W3C Augmentative and Alternative Communication (AAC) Symbols Registry specification [aac-registry] corresponding to the concept associated with that Registry numeric value. Authors MAY use this attribute in HTML content to enhance the personalizability of the content ad libitum. There is no requirement that all content must be marked with adapt-symbol index values, and there is no minimum.

4. Vocabulary

4.1 symbol

4.1.1 Description

The adapt-symbol attribute identifies the concept for symbols used in AAC devices, etc., for users who cannot process traditional written language. The symbols are an alternative vocabulary, and multiple symbol sets exist today. These various symbol sets are, unfortunately, not mutually comprehensible so the individual familiar with expression via symbol set alpha is unable to understand expressions using symbol set beta. This specification exists to provide a web-based technological mechanism to select appropriate symbols from the set an individual user knows by using the BCI concept index, the current de facto standard for cross referencing symbolic representations among symbol sets extant in the world today.

The adapt-symbol attribute accepts a numeric reference number.

A personalization-aware user agent can then augment or transform User Interfaces by:

  • converting content author text, annotated using numeric values from the BCI concept index into symbols in the user's preferred set,
  • facilitating symbol-set representation by loading and displaying symbols that the user is familiar with, so they do not have to learn new symbols across different applications environments.

Note

It is important to understand that support for the world's languages, and the translation of content from one language into another occurs between written natural languages. At no time is there any expectation of translation among symbols themselves. Such a concept remains undefined. Multiple AAC symbol sets are supported by this specification because users of one symbol set generally cannot comprehend symbols from a different symbol set. Thus this specification facilitates the expression of concepts in the AAC symbol set an individual user knows based on BCI index values as the common concept interchange.

In those natural languages where an expression can differ based on gender and verb tense, more than one BCI index value may be needed to map the expression to a symbol. In such situations content authors should join multiple BCI index values in order to map to a single conjugated symbol by using a plus (+) sign (with no spaces between the BCI index values).

When no individual codepoint exists to express the textual content, multiple BCI index values MAY be conjugated by listing two or more concept index values together, separated only by a plus (+) symbol. The order of multiple concepts should be the same as used in typical speech in the natural language of the content.

The numeric values utilized to map to symbols MUST be published BCI index values. These can be obtained from the W3C Augmentative and Alternative Communication (AAC) Symbols Registry specification [aac-registry].

Note

This specification is focused on allowing authors to make one-to-one mappings from parts of their content to concepts as defined by BCI. The rendering of the appropriate symbols for the user would be handled by the user agent, extension, or assistive technology. It is anticipated that symbol selection for rendering would take the form of a simple look-up.

Whilst this specification is not focused on rendering, here are some notes on the expected process, which may be of interest for authors and implementers.

  • The BCI index value may map to one rendered symbol, or possibly more than one rendered symbol, in the user's chosen symbol set. This is because the user's chosen set may not have a single symbol to represent that one concept.
  • A mapping from a BCI index value to the user's chosen symbol set would exist, enabling a user agent to render one (or more) symbols for that index value.
  • An extensible, standard mapping URI resource utilizing a W3C Registry will be developed for BCI concepts also cross-referencing corresponding symbols in multiple, available symbol sets.
  • Authors should not assume that one index value maps to one symbol—though authors should not need to make any assumptions about rendering, other than ensuring their content can be resized and will reflow, as per WCAG 2.1 Success Criteria 1.4.4 Resize Text and 1.4.10 Reflow.

4.1.2 Examples

Here are some examples using the adapt-symbol attribute.

  1. Symbols for individual words.
    Example 1: Symbols for individual words
    <span adapt-symbol="13621">Cup</span> of <span adapt-symbol="17511">Tea</span>
  2. Symbols used with an image (alt text represented as a symbol).
    Example 2: Symbols used with an image
    <img src="cup.png" adapt-symbol="13621" alt="Cup"/>
  3. Symbols with conjugation. In this example a symbol is used for "her name" for the conjugated Hebrew word, שמה. The plus sign is used with no spaces to join the conjugated values, "her" (14707) and "name" (15691). If the gender is not important, you can just use the value for name (15691).
    Example 3: Symbols with conjugation
    <img src="her-name.png" alt="שמה" adapt-symbol="15691+14707"/>

4.1.3 Characteristics

Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Inherits into Roles: Placeholder
Value: URI

5. Privacy and Security Considerations

This specification adds context information about content to the document, and should not affect security.

Although this specification does not expose personal preferences and personal information, third party user agents or proxy server(s) acting upon our semantic information may need to store personal preferences on how to present content to a specific user. It is recommended that any user agent or proxy server implements best practices to protect all personal preferences and personal information.

Any user agent with user settings are recommended to follow best practices to keep user information secure.

The Privacy and Security Considerations of WAI-Adapt: Symbols Module is also discussed at issue #131.

A. Candidate Recommendation Exit Criteria

The WAI Adapt: Symbols Module specification consists of the symbol attribute that may be added to a page’s HTML at the website’s discretion. A user agent may take suitable rendering decisions based on these attributes.

For the specification to exit Candidate Review status: for the attribute-value in the specification, at least two user agents (or extensions to existing user agents) react to the attribute in an identifiable manner which is suited to the semantics of the attribute.

For clarity, we note:

B. Acknowledgments

This section is non-normative.

The following people contributed to the development of this document.

B.1 Participants active in the WAI-Adapt TF at the time of publication

B.2 Other WAI-Adapt TF contributors, commenters, and previously active participants

B.3 Enabling funders

This publication has been funded initially under contract number ED-OSE-10-C-0067, then under contract number HHSP23301500054C, and now under HHS75P00120P00168. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Health and Human Services, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government. Some of the work on this project has also received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No.780529 and 643399.

C. References

C.1 Normative references

[aac-registry]
W3C Alternative and Augmented Communication (AAC) Symbol Registry. Michael Cooper; Ruoxi Ran; Janina Sajka; Matthew Atkinson; Russell Galvin et al. W3C. DRY. URL: https://www.w3.org/TR/aac-registry/
[microdata]
HTML Microdata. Chaals Nevile; Dan Brickley; Ian Hickson. W3C. 28 January 2021. W3C Working Group Note. URL: https://www.w3.org/TR/microdata/
[rdfa-primer]
RDFa 1.1 Primer - Third Edition. Ivan Herman; Ben Adida; Manu Sporny; Mark Birbeck. W3C. 17 March 2015. W3C Working Group Note. URL: https://www.w3.org/TR/rdfa-primer/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[swbp-skos-core-guide]
SKOS Core Guide. Alistair Miles; Dan Brickley. W3C. 2 November 2005. W3C Working Draft. URL: https://www.w3.org/TR/swbp-skos-core-guide/

C.2 Informative references

[adapt]
WAI-Adapt Explainer. Lisa Seeman-Horwitz; Charles LaPierre; John Foliot; Michael Cooper; Ruoxi Ran; Richard Schwerdtfeger. W3C. 9 June 2022. W3C Working Group Note. URL: https://www.w3.org/TR/adapt/