Copyright © 2017 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
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.
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.
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).
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:
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.
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.
This section is non-normative.
While some terms are defined in place, the following definitions are used throughout this document.
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].
Hardware and/or software that:
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:
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.
A set of instance objects that share similar characteristics.
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.
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.
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.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.
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.
Any software that retrieves, renders and facilitates end user interaction with Web content. This definition may differ from that used in other documents.
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).
Semantic properties have the characteristics described in the following sections.
Value type of the semantic property. The value may be one of the following types:
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.
Is this section needed for this spec?
Semantic properties are categorized as follows:
coga-simplificationcoga-destination attribute provides the context of a link. It should be used on a link element or element with role="link".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-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.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)
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:
Typically 3 links or buttons would be considered "simplest"
coga-simplification="high". This setting should be used on:
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) 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.
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| Used in Roles: | All elements of the base markup |
| Value: | token |
| Value | Description |
|---|---|
| medium (default) | |
| high | |
| low | |
| simplest |
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:
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| 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.
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| 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"
coga-field can also give the context for text elements.
coga-field values on text are:
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| Used in Roles: | All elements of the base markup |
| Value: | string |
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.
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| Used in Roles: | All elements of the base markup |
| Value: | URI |
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>
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/>
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| Used in Roles: | All elements of the base markup |
| Value: | URI |
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:
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>
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| Used in Roles: | All elements of the base markup |
| Value: | string |
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.
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| Used in Roles: | All elements of the base markup |
| Value: | string |
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.
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| 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.
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| Used in Roles: | All elements of the base markup |
| Value: | string |
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.
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| 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.
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| 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">
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| Used in Roles: | All elements of the base markup |
| Value: | token |
| Value | Description |
|---|---|
| automated | |
| dictionary | |
| faqs | |
| glossary | |
| helpform | |
| humanhelp | |
| morehelp | |
| simplified | |
| thesaurus | |
| tooltips | |
| topicsearch |
The following may not be necessary
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.
This data model may be too complex, so this property could undergo substantial changes.
Supported values:
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>
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| Used in Roles: | All elements of the base markup |
| Value: | token list |
| 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.
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| Used in Roles: | All elements of the base markup |
| Value: | string |
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.
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| 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.
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| 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.
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| 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.
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| 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.
Need a better token for "not done", or is that value actually needed given the presence of prending and current?
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.
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| Used in Roles: | All elements of the base markup |
| Value: | token |
| 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 | @@ |
<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>
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>
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>
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| Used in Roles: | All elements of the base markup |
| Value: | token |
| 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>
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| 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>
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| 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>
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| Used in Roles: | All elements of the base markup |
| Value: | string |
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.
| Characteristic | Value |
|---|---|
| Related Concepts: | SVG [SVG2] and DOM [DOM4] active |
| Used in Roles: | All elements of the base markup |
| Value: | token list |
| Value | Description |
|---|---|
| ad | |
| animations | |
| auto-changing | |
| auto-starting | |
| chat | |
| message | |
| moving | |
| offer | |
| overlay | |
| popup | |
| third-party |
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:
This section is not yet developed. A draft of user settings is available separately.
This section is non-normative.
The following people contributed to the development of this document.
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.