Abstract

Personalization involves tailoring aspects of the user experience to meet the needs and prefences of the user. For example, having familiar terms and symbols is key to many users being able to use the web. However, what is familiar for one user may be unfamiliar to another requiring them to learn new symbols. The challenge has been the ability to identify the types of content in a document that should be adapted to the preferred user experience. The introduction of standardized semantics allows web applications to customize the exposure of that content to one that is familiar to individuals based on their needs and preferences. This specification defines standard semantics to enable user driven personalization such as the association of a user-preferred symbols to elements having those semantics. This ensures that users can quickly find familiar icons, such as a help icon, that apply to user interface elements.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. 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 is a First Public Working Draft of Personalization Semantics by the Accessible Rich Internet Applications (ARIA) Working Group. It was initially developed by the Cognitive and Learning Disabilities Accessibility Task Force to provide technology features needed to meet user needs identified in the draft Cognitive Accessibility Roadmap and Gap Analysis [coga-gap-analysis]. It was transferred to the ARIA Working Group for development as a WAI-ARIA 1.1 [wai-aria-1.1] module. Although this was initiated by a task force focusing on the needs of users with cognitive and learning disabilities, it is intended to support a wide variety of personalization use cases.

This is an early draft of the module with a number of proposed properties to support various personalization use cases in different ways. The description and attribute models for some properties are not yet complete. In order to avoid potential confusion with more mature WAI-ARIA 1.1 features, the names of all properties in this specification currently begin with "coga-". This prefix is expected to change in future versions of this specification. A goal of this publication is to obtain early implementation, but implementers should be aware of this and implement in a manner to accommodate the change readily.

Feedback on any aspect of the specification is accepted. For this publication, the WAI-ARIA Working Group particularly seeks feedback on the following questions:

To comment, file an issue in the W3C personalization semantics GitHub repository. If this is not feasible, send email to public-aria@w3.org (comment archive). Comments are requested by 30 June 2017. In-progress updates to the document may be viewed in the publicly visible editors' draft.

This document was published by the Accessible Rich Internet Applications Working Group as a First Public Working Draft.

Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. 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 1 March 2017 W3C Process Document.

1. Introduction§

This section is non-normative.

The goals of this specification include:

This is a proposal to define syntax for adaptable content such as: links, buttons, symbols, help and keyboard. This may be an WAI-ARIA COGA Extension.

Personalization involves tailoring aspects of the user experience to meet the preferences or needs of the user. For example, having familiar terms and symbols is key to being able to use the web. However what is familiar for one user may be new for another requiring them to learn new symbols. Personalization could include loading a set of symbols that is appropriate for the specific user, ensuring that all users find the icons simple and familiar.

Technology holds the promise of being extremely flexible and the design of many systems includes the expectation that users will be able to optimise their interaction experience according to their personal preferences or accessibility requirements (needs).

1.1 Why We Need Personalization§

We need personalization because:

Some users need extra support. This can include:

For this we need standardized terms and supportive syntax that can be linked to associated symbols, terms, translations and explanations for the individual use via an attribute and personal preferences.

For example, assume an author can make it programanticaly known that a button is used to send an email. At at the user end, the button could be renderer with a symbol, term, and/or tooltips that is understandable for this particular user. It could automatically imply F1 help that explains the send function in simple terms. It could be identified with a keyboard short cut that will always be used for send. In addition it could be identified as important and always rendered, or rendered as a large button.

Working examples of how this could be used in practice, with user preferences, are available at https://github.com/ayelet-seeman/coga.personalisation. This is a project to help personalization for any use - including people with learning and memory issues. It is described more at: https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Easy_Personalization.

This project consists of 4 parts:

  1. JSON files for user setting
  2. Proposal for new syntax: (This document)
  3. An HTML page that uses some of the new syntax: https://github.com/ayelet-seeman/coga.personalisation/tree/ExampleWebPage/
  4. Scripts that a web author can use or include that read the user settings in the JSON files and adapt the page for the user needs: https://github.com/ayelet-seeman/coga.personalisation/tree/Script-Options

This is one example of personalization based on semantics. Others may follow. It is also worth noting that the GPII project is working on making user preferences portable which would also enhance this work.

In another use-case we would like to see interoperable symbol set codes for non-verbal people. Products for people who are non vocal often use symbols to help users communicate. These symbols are in fact peoples language. Unfortunately many of these symbols are both subject to copy write and are not interoperable. That means end-users can only use one device, and can not use apps or AT from a different company. An open set of references for symbol codes for these symbol sets however, could be interoperable. That means the end user could use an open source symbol set or buy the symbols and use them across different devices or applications. Symbols could still be proprietary but they would also be interoperable.

1.2 Contextual Personalization§

One important factor in optimizing the personalization of a product or service is to ensure that the personalization is appropriate for the current context of use. For example, settings that will suit the user of a mobile phone in their office or home will not be well suited to that user when they are driving a car. In a home or office, the typical user would probably prefer to send and receive text messages using the keyboard and screen of the mobile phone. However, in the car, voice input and text to speech output would be the most appropriate. In this car context, the profile settings of a typical user might be very similar to those that a blind user would use in all contexts.

2. Important Terms§

This section is non-normative.

While some terms are defined in place, the following definitions are used throughout this document.

Accessibility API

Operating systems and other platforms provide a set of interfaces that expose information about objects and events to assistive technologies. Assistive technologies use these interfaces to get information about and interact with those widgets. Examples of accessibility APIs are Microsoft Active Accessibility [MSAA], Microsoft User Interface Automation [UI-AUTOMATION], MSAA with UIA Express [UIA-EXPRESS], the Mac OS X Accessibility Protocol [AXAPI], the Linux/Unix Accessibility Toolkit [ATK] and Assistive Technology Service Provider Interface [AT-SPI], and IAccessible2 [IAccessible2].

Assistive Technologies

Hardware and/or software that:

  • relies on services provided by a user agent to retrieve and render Web content
  • works with a user agent or web content itself through the use of APIs, and
  • provides services beyond those offered by the user agent to facilitate user interaction with web content by people with disabilities

This definition may differ from that used in other documents.

Examples of assistive technologies that are important in the context of this document include the following:

  • screen magnifiers, which are used to enlarge and improve the visual readability of rendered text and images;
  • screen readers, which are most-often used to convey information through synthesized speech or a refreshable Braille display;
  • text-to-speech software, which is used to convert text into synthetic speech;
  • speech recognition software, which is used to allow spoken control and dictation;
  • alternate input technologies (including head pointers, on-screen keyboards, single switches, and sip/puff devices), which are used to simulate the keyboard;
  • alternate pointing devices, which are used to simulate mouse pointing and clicking.
Attribute

In this specification, attribute is used as it is in markup languages. Attributes are structural features added to elements to provide information about the states and properties of the object represented by the element.

Class

A set of instance objects that share similar characteristics.

Element

In this specification, element is used as it is in markup languages. Elements are the structural elements in markup language that contains the data profile for objects.

Event

A programmatic message used to communicate discrete changes in the state of an object to other objects in a computational system. User input to a web page is commonly mediated through abstract events that describe the interaction and can provide notice of changes to the state of a document object. In some programming languages, events are more commonly known as notifications.

Object

In the context of user interfaces, an item in the perceptual user experience, represented in markup languages by one or more elements, and rendered by user agents.

In the context of programming, the instantiation of one or more classes and interfaces which define the general characteristics of similar objects. An object in an accessibility API may represent one or more DOM objects. Accessibility APIs have defined interfaces that are distinct from DOM interfaces.
Property

Attributes that are essential to the nature of a given object, or that represent a data value associated with the object. A change of a property may significantly impact the meaning or presentation of an object. Certain properties (for example, aria-multiline) are less likely to change than states, but note that the frequency of change difference is not a rule. A few properties, such as aria-activedescendant, aria-valuenow, and aria-valuetext are expected to change often. See clarification of states versus properties.

State

A state is a dynamic property expressing characteristics of an object that may change in response to user action or automated processes. States do not affect the essential nature of the object, but represent data associated with the object or user interaction possibilities. See clarification of states versus properties.

User Agent

Any software that retrieves, renders and facilitates end user interaction with Web content. This definition may differ from that used in other documents.

Widget

Discrete user interface object with which the user can interact. Widgets range from simple objects that have one value or operation (e.g., check boxes and menu items), to complex objects that contain many managed sub-objects (e.g., trees and grids).

3. Semantic Properties§

This Section covers semantic properties.

3.1 Characteristics of Semantic Properties§

Semantic properties have the characteristics described in the following sections.

3.1.1 Related Concepts§

Advisory information about features from this or other languages that correspond to this property. While the correspondence may not be exact, it is useful to help understand the intent of the state or property.

3.1.2 Value§

Value type of the semantic property. The value may be one of the following types:

true/false
Value representing either true or false, with a default "false" value.
true/false/undefined
Value representing true or false, with a default "undefined" value indicating the state or property is not relevant.
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.

The "undefined" value, when allowed on a state or property, is an explicit indication that the state or property is not set. The value is used on states and properties that support tokens, and the "undefined" value is a string that is one of the allowed tokens. It is also used on some states and properties that accept true/false values, when "undefined" has a different meaning than "false".

These are generic types for states and properties, but do not define specific representation. See State and Property Attribute Processing for details on how these values are expressed and handled in host languages.

3.1.3 Taxonomy of Semantic Properties§

Editor's note

Is this section needed for this spec?

Semantic properties are categorized as follows:

  1. General Semantics
3.1.3.1 General Semantic Properties§
The following are general semantic properties used for personalization:
  • coga-simplification

3.1.4 Definitions of Semantic Properties (all coga-* attributes)§

coga-action
@@1-line description
coga-actiontaken
Contains a summary of key actions taken during a step of a process.
coga-alternative
Would be used on an alternative content as an alternative to more detailed or difficult to understand content. coga-alternative can be used on a span, div, link or image that servers as alternative content to it's direct parent element.
coga-concept
@@1-line description
coga-context
Coga-context would let the author give additional contextual information about the content.
coga-destination
The coga-destination attribute provides the context of a link. It should be used on a link element or element with role="link".
coga-distraction
This attribute should be used on non essential, detracting content, so that people who have problems keeping focus can turn them off. An example user experiences would be to hide all distraction content.
coga-easylang
coga-easylang will contain a version of the content that is easier to read and understand. Note that this only works on small sections of text as the easylang attribute does not support full HTML, such as lists and sections.
coga-explain
This attribute provides any information that helps the user anticipate the functionality, such as letting the user know what behavior will trigger an event. This is most important if the mechanism is not standard.
coga-extrahelp
@@1-line description
coga-feedback
This attribute provides immediate feedback that can be shown or spoken when any event is triggered on a control.
coga-field
coga-field provides the context of a text input field such as a text box. It should be used on an input, text a responding role.
coga-helptype
@@1-line description
coga-literal
@@1-line description
coga-log
Contains a label or name for the log that reflects the process or task purpose.
coga-messagecontext
@@1-line description
coga-messagefrom
@@1-line description
coga-messageimportance
@@1-line description
coga-messagetime
@@1-line description
coga-moreinfo
@@1-line description
coga-numberfree
@@1-line description
coga-simplification
@@1-line description
coga-status
Describe whether a step in a process is done, pending, current, or not done.
coga-step
Contains the number of the step in the process or task.
coga-steplocation
Contains a link to the location of the step for editing and review. The referenced location should support editing.

3.2 Simplification§

Requirement: The user must be able to request a way to identify and differentiate between critical features, medium features and less important features. These need to be defined as important from a user perspective in the content. Typically, critical features may be used by many or most users, 90% of the time or more. High important features would be above 60% use. Medium important features would be 20% of users use it 20% of the time . Under 20% usage would be of low importance.

User experience: Based on personalization setting the user can see less options. A sample user experience is available at https://rawgit.com/ayelet-seeman/coga.personalisation/demo/conactUs.html

coga-simplification (property)§

@@1-line description

(formerly coga-importance).

Having the following values: (main task such as send for an email)

Editor's note

I can't figure out from the description here what the intended list of properties are.

  • coga-simplification="simplest". This setting should be used on:
    • Elements that are essential for the key function (from the user perspective) of the page (Example: The send button for an email draft) or
    • Elements that are sometimes critical to a user being able to use the site, such as "save my work" or "emergency instructions" or
    • Elements that are used by over 90% of a user group (such as parents or teachers) use this element most times they use the content

Typically 3 links or buttons would be considered "simplest"

  • coga-simplification="high". This setting should be used on:
    • Elements that are used frequent (Example: The delete button for an email draft) or
    • Elements that are sometimes important to a user being able to use the site, such as settings or
    • Elements that are used by frequently (over 60%) by a user group (such as parents or teachers) use this element most times they use the content
  • coga-simplification= "med". This is the default value.
  • coga-simplification="low". This setting should be used on elements that are rarely used or only used by advanced users. (Example: The terms and services or the archive button for an email draft)
Note

These semantics aid simplification. But what content is most useful to a user varies from user to user. For example, men may be more interested in mens clothing, and may not be interested in the more frequently use womens clothing option. For that reason we may add context for elements that will help the personalization agent select the most useful content for a given user. This is also necessary for reminders (see bellow). RDFa may be the best way forward for this aspect.

It is worth mentioning that a lot of this information is known for personalization of advertisements and content optimization.

Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: token
Values:
Value Description
medium (default)
high
low
simplest

3.3 Adding Context §

Requirement: Having familiar terms and symbols is key to being able to use the web. However what is familiar for one user may be strange for another requiring them to learn new symbols. If a user agent or script knows the context of links, buttons, and other page elements then symbols and text used can be ones that the user understands. This can include:

For that we need to standardize supportive syntax and terms that can be linked to associated symbols, terms, translations and explanations, for the individual, via an attribute.

Example user experience:, if an author gives to a button a role "send" then, without any work by the author, the button could be automatically rendered with a symbol, term, and/or tooltips that is understandable by a particular user. It could automatically imply F1 help that explains the send function in simple terms. It could be identified with a keyboard short cut that will always be used for send. In addition it could be identified as important and always rendered, or rendered as a large button. This would enable a consistent UI experience across applications and websites.

coga-action (property)§

@@1-line description

For example: <button coga-action="undo" >default</button>

The user experience may be simply replacing the text for the term "undo". Note that there is no default value.

Supported Values:

The following could be supported values of coga-action for buttons:

  • compose(default importance = "critical")
  • delete
  • next
  • previous
  • submit (default importance = "critical")
  • undo
  • cancel
  • buy
  • add label
  • move
  • view
  • save (default importance = "critical")
  • send (default importance = "critical")
  • received
  • sent
  • edit
  • reply
  • forward
  • my profile
  • upload
  • close
  • more
  • calendar
  • add entry
  • expand
  • unexpanded
  • open
  • new
  • print
  • settings
  • mode
  • higher
  • lower
Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: string

coga-destination (property)§

The coga-destination attribute provides the context of a link. It should be used on a link element or element with role="link".

For example: <a href="home.html" coga-destination="home" >our main page</a>

The user experience may be simply replacing the text for the term "home" and adding an icon. Based on personalization setting the user can see different icons. A sample user experience is available at https://rawgit.com/ayelet-seeman/coga.personalisation/demo/conactUs.html

It may also position this button to a location on the screen where the user is expecting the home page link. Note that there is no default value.

Supported Values:

The following could be supported values of coga-destination.

  • home
  • contact us
  • our phone
  • our email
  • site map
  • help
  • about us
  • terms
  • tools
  • comment
  • language (English)
  • sign in
  • sign up
  • product
  • services
  • social (provide label )
  • post
  • contactus
  • help
  • chat help
Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: string

coga-field (property)§

coga-field provides the context of a text input field such as a text box. It should be used on an input, text a responding role.

For example: <input type="text" name="fname" coga-field="phone"/>

The user experience may include filling in the field and adding an icon.

coga-field values that would typically be on form controls and would have a user context - for example phone would relate to the user's phone. Note that there is no default value.

Note they can be concatenated such as coga-field="birthdate month"

  • name (corresponds to both first and family)
  • first name
  • family name
  • initial
  • phone (corresponds to a user phone number)
  • cell phone
  • address 1
  • city
  • state
  • country
  • post code
  • phone
  • credit card
  • expiry
  • birth date
  • day, *month *year
  • expiry date
  • todays date
  • credit card code
  • date start
  • date end

coga-field can also give the context for text elements.

coga-field values on text are:

  • our-phone
  • our-address
  • our-email
Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: string

3.3.1 General context§

Requirement: One important factor in optimizing the personalization of a product or service is to ensure that the personalization is appropriate for the current context of use as well as what is relevant for the user. For example a female user with a cognitive disability may need less options, and options that are for men are less likely to be relevant for her and may be demoted to bellow the scroll or placed under a "more option" button.

coga-context (property)§

Coga-context would let the author give additional contextual information about the content.

Coga-context accepts the values of a URI or shortened URI. Note that there is no default value.

<a href="women.html" coga-context="openref:gender#femail">women</a> 

To make this work without an RDF parser we recommend maintaining a list of recommended ontologies.

Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: URI

3.3.2 Should we be using RDFa?§

The context based properties should be convertible to RDFa. (see RDFa Primer) and the task force should create this mapping.

Note that a lot of this can be done using RDFa. However it is easy to change the meaning with RDFa and a very basic parser will misinterpret the result. The coga work needs to be usable by as many authors as possible, and not only those who can implement RDF logic.

Further , personalization setting need to be limited, and RDF can give an unlimited number of potential options which will make the system unusable. (This is unless we create restrictions and controls on an ontology uses - such as mapping to know ontologies.)

For example, in the code below the property homepage does not refer to the home page of the site but of the person being references. Beyond declaring the type of data we are dealing with, each typeof creates a new blank node with its own distinct properties.

<div vocab="http://xmlns.com/foaf/0.1/">
<ul>        
   <li typeof="Person">          
      <a property="homepage" href="http://example.com/bob/">Bob</a>        
   </li>        
   <li typeof="Person">          
      <a property="homepage" href="http://example.com/eve/">Eve</a>        
   </li>        
   <li typeof="Person">         
      <a property="homepage" href="http://example.com/manu/">Manu</a>        
   </li>     
</ul>
				

We may recommend adding RDFA that describe the role of the item (see RDFa Primer):

<div resource="/alice/posts/jos_barbecue">
	<h2 property="title">Jo's Barbecue</h2>
	<p>Date: <span property="created">2011-09-14</span></p>
	<h3 property="creator">Eve</h3>        
	...     
</div>
			

3.3.3 Concept codes§

Requirement: We would like to enable interoperable symbol set codes for Non verbal people. Products for people who are non vocal often use symbols to help users communicate. These symbols are in fact peoples language. Unfortunately many of these symbols are both subject to copy write AND not interoperable. That means end-users can only use one device, and can not use apps or AT from a different company. There are open set of symbol codes for these symbol sets, that could be referenced then they can be interoperable. alternatively wordnet nodes could be referenced. If the users symbols are mapped to the same nodes then users agents will be able to load the user understandable symbol. That means the end use could buy the symbols and use them across different devices or applications. They would still be proprietary but they would also be interoperable.

User experience: AAC users will load symbols that they understand in different applications that are made by a different provider.

coga-concept (property)§

@@1-line description

Supported Values: URL

Note that there is no default value.

Examples:

<img coga-concept="http//wordnet.com/node/girl" href="mygirlsy.bmp/> 
Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: URI

3.4 Potential parts of a page§

Requirement: The following could be extensions for aria landmarks or ePub

User experience: symbols and colors could be used consistently across different content.

Links (such as ePub nav maps) can be automatically generated for people learn via keypoints or examples.

Examples:

3.5 Number free§

Requirement: Not everyone can understand numbers. We therefor suggest coga-numberfree for alternative text for people who can not understand the main content

User experience:

A suggested user experience would be: Numerical concepts could be rendered by the user agent slightly different so that the user knows a number free explanation is available. The user can then mouse over the content and a tooltips would give the number free value

coga-numberfree (property)§

@@1-line description

Supported value : String

Note that there is no default value.

For example:

<span coga-numberfree="almost all">9 out of 10 </span>
			
<span coga-numberfree="hat and coat weather">The weather is 9 degrees</span>
			
Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: string

3.6 Non-literal text and images§

Requirement: Not everyone can understand non-literal text and icons such as metaphors, idioms etc. We need a tag that identifies text or images as non literal and allows the author to explain non-literal text and images to users.

User experience:

A suggested user experience would be: Non literal content could be rendered by the user agent slightly differently so that the user knows that this content should not be taken literally and that a literal explanation is available. The user can then mouse over the content and a tooltips would give the literal value.

coga-literal (property)§

@@1-line description

Supported value: String

Note that there is no default value.

Examples:

<span coga-literal="it is raining hard"> It is raining cats and dogs </span>

User agents can render non-literal text in a different way so that users will know that this is non literal. They can then use a mouse over or other technique to receive the translation.

Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: string

3.7 Explain and feedback§

Requirement:

Some users need additional help. We request an attribute where the author can provide additional information or what just happened.

coga-feedback (property)§

This attribute provides immediate feedback that can be shown or spoken when any event is triggered on a control.

User experience: This can be rendered as text at the top of the page and read immediately. Most users will not want this text rendered and spoken. Other users however will need it to know what has just happened.

Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: string

coga-explain (property)§

This attribute provides any information that helps the user anticipate the functionality, such as letting the user know what behavior will trigger an event. This is most important if the mechanism is not standard.

User experience: This help can be rendered as a tool tip, help link or read when the control or link is read. Most users will not want this text rendered or spoken, but other users however will need it to understand the behavior of the element.

Note that there is no default value.

Examples:

coga-explain="press enter to send the email" 
coga-feedback="your email on birthdays was sent" 

These values will change when the email is sent.

Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: string

3.8 More Help§

Requirement: Some users may need additional information or specifically additional help information. We request additional attributes so that an author can indicate the existence of this additional information.

coga-moreinfo (property)§

@@1-line description

Supported values: URI

Note that there is no default value.

Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: URI

coga-extrahelp (property)§

@@1-line description

Supported values: URI

Note that there is no default value.

Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: URI

coga-helptype (property)§

@@1-line description

Example:

<button type="button" coga-extrahelp="uri2 uri3" >undo</button>

URI 2 may read:

<div id="uri2" 
    coga-helptype="morehelp" 
    coga-hidden="true">
  pressing the undo button will erase all your work on this page. 
  Use this button with care. 
  If you press it by mistake, press control and y at the same time 
  and your answers will come back. 
</div>

<a href="functiongethelp()" 
    coga-helptype="humanhelp" 
    coga-hidden="true">
  I want a person to help me
</a>
<div id="uri3" 
    coga-extrahelp="glossary" 
    coga-hidden="true">
Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: token
Values:
Value Description
automated
dictionary
faqs
glossary
helpform
humanhelp
morehelp
simplified
thesaurus
tooltips
topicsearch

3.9 Potential Features§

The following may not be necessary

3.10 Language type support§

Requirement: Sometimes you may want to provide a simplified version of a section of a page. For example, you may wish to provide a simplified summary of legal document, but still have a longer version for other users. These alternative versions may not be identical in content but maintain the gist of the original content.

coga-alternative (property)§

Would be used on an alternative content as an alternative to more detailed or difficult to understand content. coga-alternative can be used on a span, div, link or image that servers as alternative content to it's direct parent element.

Editor's note

This data model may be too complex, so this property could undergo substantial changes.

Supported values:

  • On text: easylang, explain, more, vocab500, vocab1000, vocab2000, active, literal, numberfree, smallsentences, chunks
  • General: lessoptions. Whitespace, largefont 
  • Images: symbolic , realistic
  • p0, p1, p1, p2, p3 Where p0 are images with true content, p1 is a symbol or illustration that is typically shown with alt="", P2 are extra illustration that most people will not mind such as at the start of a paragraph or option. p3 are for disability centric illustrations that can disturb other people and may be mid sentence. 

Note that there is no default value.

Example:
<div>
  <span coga-alternative="easylang numberfree vocab1000" class="hidden">>
    most people prefer simple text
  </span>
  In studies it was found that only 30% of users prefer long convoluted text 
  with obtuse words and lots of numbers, 
  with 56% claiming there preferred the simplified text , 
  with the remainder unsure or stated it depends on the context.
</div>
Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: token list
Values:
Value Description
active
chunks
easylang
explain
largefont
lessoptions
literal
more
numberfree
p0
p1
p1
p2
p3
realistic
smallsentences
symbolic
vocab1000
vocab2000
vocab500
whitespace

coga-easylang (property)§

coga-easylang will contain a version of the content that is easier to read and understand. Note that this only works on small sections of text as the easylang attribute does not support full HTML, such as lists and sections.

Supported values: String

<span coga-easylang="some text that is easy to read"> some convoluted obtuse text</span>

Where coga-easylang should use as simple well-known words as possible, and active voicing, literal text, small simple sentences. Acronyms and abbreviations should be avoided, unless they are the common way to refer to an item.

Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: string

3.11 Logs

This proposal is to track the tasks that a user has done, so that they can be reminded of them, and return to or fix a task. The suggested syntax should allow the author to transform some of the information into breadcrumbs via CSS, and the user system can read and present more or less information to the user as per their preferences.

Preferably this should be in the header so that the user agent can build a cross application log of user tasks.

Note that there is no default value.

coga-log (property)§

Contains a label or name for the log that reflects the process or task purpose.

Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: string

coga-step (property)§

Contains the number of the step in the process or task.

This can sometimes be implied via the DOM.

Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: integer

coga-actiontaken (property)§

Contains a summary of key actions taken during a step of a process.

Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: string

coga-steplocation (property)§

Contains a link to the location of the step for editing and review. The referenced location should support editing.

An embedded link inside a step can serve the same function as coga-steplocation.

Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: URI

coga-status (property)§

Describe whether a step in a process is done, pending, current, or not done.

Editor's note

Need a better token for "not done", or is that value actually needed given the presence of prending and current?

Editor's note

Not clear how the true and false values below relate to the done/pending/current/not-done values above.

When coga-actiontaken is not null it implies that coga-status is true.

When coga-actiontaken is null it implies that coga-status is false.

Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: token
Values:
Value Description
done @@
pending A step has not yet been completed but is not the current step. It is used coga-actiontaken when has not been used.
current @@
not-done @@
true @@
false @@

3.11.1 Log usage examples§

<div coga-log="booking trip" coga-step="1" aria-label="buy ticket" aria-hidden="true" 
    coga-actiontaken="bought ticket to NY return" steplocation ="uri" />

or

<div coga-log="booking trip" coga-step="1" coga-actiontaken="bought ticket to NY return">
  buy ticket
  <a href="uri">change</a>
</div>

or the step number can be implied by the DOM

<div coga-log="booking trip">
  <div coga-actiontaken="bought ticket to NY return">
    buy ticket 
    <a href="uri">change</a>
  </div>
</div>

3.11.2 Alternative syntax for log§

Note we are considering supporting an alternative syntax such as:

<log name="booking trip"> 
  <step status ="done"> 
    <name>buy ticket</name>
    <actiontaken>bought ticket to NY return</actiontaken>
    <view changepossible="yes">url </view>
  </step>
  <step  status ="done"> 
    <name>hotel</name>
    <actiontaken>booked Sheraton single room</actiontaken>
    <view changepossible="yes">url </view>
  </step>
  <step  status ="current"> 
    <name>car rental</name>
    <view current changepossible="yes"/> 
  </step>
</log>

3.12 Reminders and messages§

Requirement: We require an attribute that enables different users to experience different amount of reminders and messages based on personal preferences. Reminders are a wonderful tool for many people with cognitive disabilities. However too many reminders will be annoying or distracting for some other users. Currently people can turn off distractions such as Skype, and Facebook, across different devices, and then may forget to turn them back on.

These semantics allow for different solutions so that users are able to focus without missing important messages. Users need to manage all distractions by forming a cross application and cross device distraction matrix that manages all distractions in one setting. It is based on a matrix for distractions at the operating system , browser or cloud level. People and users can be clustered in terms of importance or groups. For example, the CEO and your child's care giver could both be considered critical contacts. So even if they do not feel the message is urgent they can sometimes disrupt the user anyway. Some family members and important colleagues can be in another group, friends and extended family in a third group, system messages from the compliance system can be a different group again.

coga-messageimportance (property)§

@@1-line description

Example:

<div role="alert" 
    coga-messageimportance="medium">
  It is your daughter's birthday tomorrow
</div>
Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: token
Values:
Value Description
critical To be critical a message needs to be both urgent and content that the user is very likely to consider important. For example, a system may send a message that it is going to reboot in one minute to install updates.
medium (default) Important messages that needs the user's attention at their convenience. For example, a relatively important chat message.
low A message that does not need time sensitive attention. For example, a typical chat message.

coga-messagefrom (property)§

@@1-line description

Supported values: a string value that identifies the sender of the message. If multiple names are used they can be separated by a coma.

Note that there is no default value.

Example:

<div role="alert" 
    coga-messageimportance="low" 
    coga-messagefrom="lisa seeman, lseeman">
  I posted a new version on GitHub for you to review
</div>
Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: string

coga-messagecontext (property)§

@@1-line description

Supported values: a string value that identifies the location that makes this message relevant. Typical values are "home" and "work". If multiple locations are relevant they can be separated by a coma.

Note that there is no default value.

Example:

<div role="alert"
   coga-messageimportance="low" 
   coga-messagefrom="lisa seeman, lseeman" 
   coga-messagecontext="work">
  I posted a new version on GitHub for you to review
</div>
Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: string

coga-messagetime (property)§

@@1-line description

Supported values: 24 hour date time format. DD.MM.YEAR.HOUR.MM - DD.MM.YEAR.HOUR.MM where the second date is an optional exclusive expiry date.

Note that there is no default value.

Example:

<div role="alert" 
    coga-messageimportance="medium" 
    coga-messagefrom="my calender" 
    coga-messagecontext="work" 
    coga-messagetime="10.02.2017.00.00-16.02.2017.00.00">
  Renew your driving license this week
</div>
<div role="alert" 
    coga-messageimportance="critical" 
    coga-messagefrom="my calender" 
    coga-messagecontext="work" 
    coga-messagetime="16.02.2017.00.00">
  Renew your driving license ASAP
</div>
Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: string

3.13 Distractions§

Requirement: We require an attribute that indicates a distraction so that some users may be able to remove them from content.

coga-distraction (property)§

This attribute should be used on non essential, detracting content, so that people who have problems keeping focus can turn them off. An example user experiences would be to hide all distraction content.

Example:

coga-distraction="moving ad"

Supported values: animations, auto-starting, moving, ad, message, chat , overlay, popup
Auto-changing (logs) third-party, offer ( includes suggestions).

Note that there is no default value.

Note that elements with the coga-distraction attribute should also have a label or accessible name.

Characteristics:
Characteristic Value
Related Concepts:
Used in Roles: All elements of the base markup
Value: token list
Values:
Value Description
ad
animations
auto-changing
auto-starting
chat
message
moving
offer
overlay
popup
third-party

3.14 New Misc.§

Triggers: for emotional support. coga-trigger: violent, racism, etc. coga-keyparts of the page: key points, example, note, warning, external (content), advertisements, (some may be in digital publishing) coga-dates - (cancellation, return)

3.15 Additional WAI-ARIA roles§

Requirement: We may want to add roles for sections a page such as: contact us - for a contact us form 

User experience: symbols and colors could be used consistently across different content.

Nav maps can be automatically generated for people learn via key-points or examples.

Further these sections could be hidden in the normal rendering of a page or rendered the top of page depending on user preferences. The location of these sections can also be changed, based on the user preference, enabling the user to find them easily.

Values:

4. User Settings§

Editor's note

This section is not yet developed. A draft of user settings is available separately.

A. Acknowledgments§

This section is non-normative.

The following people contributed to the development of this document.

A.1 Participants active in the ARIA WG at the time of publication§

A.2 Other ARIA contributors, commenters, and previously active participants§

A.3 Enabling funders§

This publication has been funded in part with U.S. Federal funds from the Department of Education, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR), initially under contract number ED-OSE-10-C-0067 and currently under contract number HHSP23301500054C. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.

B. References§

B.1 Normative references§

[wai-aria-1.1]
Accessible Rich Internet Applications (WAI-ARIA) 1.1. Joanmarie Diggs; James Craig; Shane McCarron; Michael Cooper. W3C. 27 October 2016. W3C Candidate Recommendation. URL: https://www.w3.org/TR/wai-aria-1.1/

B.2 Informative references§

[AT-SPI]
Assistive Technology Service Provider Interface. The GNOME Project. URL: https://developer.gnome.org/libatspi/stable/
[ATK]
ATK - Accessibility Toolkit. The GNOME Project. URL: https://developer.gnome.org/atk/stable/
[AXAPI]
Accessibility Programming Guide for OS X. Apple Corporation. URL: https://developer.apple.com/library/content/documentation/Accessibility/Conceptual/AccessibilityMacOSX/index.html#//apple_ref/doc/uid/TP40001078
[DOM4]
DOM Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/
[IAccessible2]
IAccessible2. Linux Foundation. URL: https://wiki.linuxfoundation.org/accessibility/iaccessible2/start
[MSAA]
Microsoft Active Accessibility (MSAA) 2.0. Microsoft Corporation. URL: https://msdn.microsoft.com/en-us/library/ms697707.aspx
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986
[SVG2]
Scalable Vector Graphics (SVG) 2. Nikos Andronikos; Rossen Atanassov; Tavmjong Bah; Amelia Bellamy-Royds; Brian Birtles; Cyril Concolato; Erik Dahlström; Chris Lilley; Cameron McCormack; Doug Schepers; Dirk Schulze; Richard Schwerdtfeger; Satoru Takagi; Jonathan Watt et al. W3C. W3C Working Draft. URL: http://www.w3.org/TR/2015/WD-SVG2-20150915/
[UI-AUTOMATION]
UI Automation. Microsoft Corporation. URL: https://msdn.microsoft.com/en-us/library/ee684009%28v=vs.85%29.aspx
[UIA-EXPRESS]
The IAccessibleEx Interface. Microsoft Corporation. URL: https://msdn.microsoft.com/en-us/library/windows/desktop/dd561898%28v=vs.85%29.aspx
[WAI-ARIA-IMPLEMENTATION]
WAI-ARIA 1.0 User Agent Implementation Guide. Joseph Scheuhammer; Michael Cooper. W3C. 20 March 2014. W3C Recommendation. URL: https://www.w3.org/TR/wai-aria-implementation/
[WAI-ARIA-PRACTICES]
WAI-ARIA 1.0 Authoring Practices. Joseph Scheuhammer; Michael Cooper. W3C. 14 July 2016. W3C Working Draft. URL: https://www.w3.org/TR/wai-aria-practices/
[WCAG20]
Web Content Accessibility Guidelines (WCAG) 2.0. Ben Caldwell; Michael Cooper; Loretta Guarino Reid; Gregg Vanderheiden et al. W3C. 11 December 2008. W3C Recommendation. URL: https://www.w3.org/TR/WCAG20/
[coga-gap-analysis]
Cognitive Accessibility Roadmap and Gap Analysis. W3C. URL: https://w3c.github.io/coga/gap-analysis/