Standardized APIs

[lseeman]

Standardized APIs

Standardized APIs: Support known standardized API's for tools that help the user understand and use the content.

Exceptions:

• When there is a security or safety requirement, these API's may be disabled for the relevant field
• If it breaks the main function of the site, such as evaluation and testing applications

Suggestion for Priority Level A

Related Glossary additions or changes

Standardized API's

identified in the native platform's documentation or in a WCAG technique

What Principle and Guideline the SC falls within.

Principle 3, Guideline 3.3

Description

The intent of this Success Criterion is to support compatibility with assistive technology and standardized personalization. The definition of standardized API's are identified in the native platform's documentation or in a WCAG technique. This is important as the success criterion is not open ended.

People with cognitive disabilities are often using add-ons as assistive technology. It is essential that add-ons and similar tools work. Otherwise, we need to make the author support all the functions of the add-ons in use as assistive technology.

This includes:

• Support of standards for the Internet of Things that allow for simplified and personalized interfaces such as the ISO/IEC 24752 “Universal Remote Console Framework” standard
• Standardized techniques to support interoperable symbol sets that are used when available.
• Allow reading of the long form of acronyms
• Support for text-to-speech with synchronized highlighting of the phrase being read
• Content simplification
• Creating mind maps out of the heading structure
• Support for retaining content that has already been entered
• Password management
• Spell checking

Benefits

People with ADHD, Alzheimer's disease and other forms of dementia, traumatic brain injury, or weak executive function can experience memory impairments impacting their ability to remember details such as:

• The Internet of Things (IoT) interface
• Their user name and password
• What an acronym stands for
• A phone number
• The meaning of uncommon words

Poor working memory (i.e. difficulty holding on to several pieces of information at the same time) may also be experienced by people with these types of disabilities.

Providing access to simplified content and certain types of content (e.g. the long form of acronyms) helps, and in some cases is necessary, to allow people with cognitive disabilities an opportunity to comprehend the content.

Supporting password management tools enables people with memory-related disabilities to successfully login and avoid being locked out of secure sites.

Storing non-sensitive, user-provided information offers the means for completing a task in manageable pieces rather than all at once. This is especially helpful for people with ADHD as well as other cognitive disabilities, who may become distracted and logged out, or fatigued while filling out a form.

Suggesting common information, like a person's phone number or address when encountering form fields requesting this type of information, helps all people, especially those with cognitive disabilities, avoid making mistakes. It also eliminates the need for accurately recalling this information from memory or having to copy and paste it, which is a task that can prevent successful interaction with a form.

When people with literacy impairments or autism are unable to understand, or when they become overwhelmed by textual content, support for interoperable symbol sets can provide a way for the content to be comprehended.

The Internet of Things (IoT)

Individuals with lower literacy may have different reading patterns than high-literacy readers when it comes to understanding displays for “smart objects.” While high-literacy readers scan text, low-literacy users may read the text “word-for-word.” This can create a narrow field of view which may cause them to miss objects and information not directly in the flow of text that they are reading. For example, low-literacy users might miss information that is essential for successfully completing an interaction with wifi for remote monitoring.

Too many options may add to the complexity of interacting with IoT devices. Additional options should be easy to ignore and not require a lot of reading to understand that they are additional, as well as how to skip them.

Sometimes IoT interfaces may confuse the user, such as a default "reading" on a meter being set to “2” and not “1.” The user would then need to reset it to “1.”

It is important in any proposed solution to make operational tasks, such as interacting with the IoT, as transparent as possible so that users can focus their attention on the functional aspects, such as relating to content. The following solutions support general usability of the IoT for everyone, in addition to assisting those with cognitive disabilities.

The task force discussed this paper on 0/03/2015 and felt that the following changes should be made to the content below:

1. We want interfaces either to support adaptability, be compatible with supportive API's, or provide an alternative, simplified control. We cannot expect only standard controls to be used.
2. A lot of this will be covered by the API's such as URC http://www.openurc.org/
3. We need to review that the API's provide the support we need, such as less features.
4. We need to ensure web interfaces have the needed semantics, such as via ARIA. See personalization semantics

 

Related Resources (optional)

Resources are for information purposes only, no endorsement implied.

• Gap analysis
• User needs Table
• Background research document
• Semantics for adaptive interfaces
• COGA Techniques

Issue Papers

• Personalization and Preferences
• Web of Things

See also:

1. The Internet of Things Paper Prepared for the First Berlin Symposium on Internet and Society, October 25-27, 2011
2. blog: accessibility requirements in the internet-of-things
3. simplyaccessible.co things
4. accessibility in the internet-of-things from psfk.com

Testability

1. Look at the applicable standards identified in the native platform's documentation or in a WCAG technique
2. Confirm that the page conforms to the standard
3. Confirm that none of the failure techniques apply

Techniques

For HTML: Using HTML tags appropriately and using WAI-ARIA roles appropriately (Note: for HTML we will not be asking for full conformance, just correct use of element names and aria roles)

For native content: Using the native platform's documentation for help support and design patterns

For Internet of Things: Using “Universal Remote Console Framework” standard for IoT (Internet of Things) devices (need to confirm that this gives the support we need)

For AAC content: Using concept codes on augmentative and alternative communication (AAC)

Failures

• disabling the items in the right click menu-bar
• disabling spell-check

working groups notes (optional)

[lseeman]

Alternative wording: is this clearer?

Do not interfere with the user agents and support a standardized API or vocabulary that enable accessibility support unless there is a security or safety requirement or it breaks the main function of the site, such as evaluation and testing applications or no known vocabulary exists for this content type.

Note the glossary definition of :
Standardized API's
identified in the native platform's documentation or in a WCAG technique and has a conformance test harness

Content type
Domain of the content such as Internet Of Things (Iot) , web content, web applications social media

Sufficient techniques for normal HTML page is using HTML element names properly
Sufficient techniques for normal web applications page is using ARIA
Sufficient techniques for IOT is using the ETSI standard or URC

This is testable - did you use a vocabulary that conforms

[lseeman]

I am wondering if we can merge the first set of use cases with #71

the second set of use cases could be handled as techniques for 1.3.1 and 4.2.1 . @mapluke do you think we could do the etsi as roles for 4.2.1. we should also ask gotfried about URC
---...------
if that does not cover it..
Maybe we need a double AA version of 1.3.1 such as
1.3.4 Info and Relationships (enhanced): Information, structure, context and relationships conveyed through presentation can be programmatically determined

note we add the word context and remove the word available though text