W3C Candidate Recommendation Snapshot
Copyright © 2018-2023 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
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].
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.
This section is non-normative.
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].
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.
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.
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.
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:
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.
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.
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.
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.
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:
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].
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.
Here are some examples using the adapt-symbol
attribute.
<span adapt-symbol="13621">Cup</span> of <span adapt-symbol="17511">Tea</span>
alt
text represented as a symbol).
<img src="cup.png" adapt-symbol="13621" alt="Cup"/>
<img src="her-name.png" alt="שמה" adapt-symbol="15691+14707"/>
Characteristic | Value |
---|---|
Related Concepts: | microdata [microdata], SKOS Core Guide [swbp-skos-core-guide] and RDFa [rdfa-primer] |
Used in Roles: | All elements of the base markup |
Inherits into Roles: | Placeholder |
Value: | URI |
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.
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:
While the WAI-Adapt standard stipulates HTML value/attribute markup codes for use by page authors, implementations to meet exit criteria are focused on rendering of the markup.
For user agents (or extensions) rendering a given attribute, all values for that attribute must be supported.
The results of testing are made available in a separate implementation report.
This section is non-normative.
The following people contributed to the development of this document.
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.