Task force for inclusion of people with cognitive disabilities
Draft for brainstorming and discussion.
Version: Version 0.2 (draft)
Author: Lisa Seeman. Please contact me at lisa.seeman at Deque dot com, or
lisa.seeman at zoho dot com
What we are trying to do
We are working to make accessibility guidelines that focus on cognitive disabilities. Guidelines that allow author to make their content usable by as many people as possible. It should include people with learning disabilities, problems reading, problem solving, attention span, short term memory loss (such as mild to moderate Alzheimer’s) and language disabilities.
Gather people and organizations who have useful expertise. This includes: People with disabilities, people who make technology for people with disabilities, developers with an interest in this topic, researchers, people involved in standardization, policy makers, and anyone else who could help.
Collect as much relevant information as we can. For example: Useful technologies; useful related work and specifications, research on helping people with cognitive disabilities. We will need to collect ideas, issues and risks that we need to address and mitigate. We will also collect user scenarios such as: Early stages of Alzheimer's, students with Learning Disabilities, adults
with Learning Disabilities
We will reference all the information in one place for easy access.
The next steps will be:
Define exactly what we are going to do (the scope, use cases and requirements). For example, should we include phone menu systems? Should all our work be done in public?
Analyze the different approaches, to select the best way forward.
Start drafting...
Some context
Although current accessibility standards provide benefits to some people with cognitive disabilities, there is still work to be done so that as many people as possible are included.
The largest group of disabilities are people with cognitive disabilities and the numbers are growing. (For example. For example by 2050 it is projected there will be 115 million people with dementia worldwide.) On the other hand many systems have become more and more complex to use (such as TV interfaces, heating etc.). These effectively make people disabled even when they only experience a minor cognitive decline.
A specification for cognitive disabilities would not necessarily be a legal requirement for most content. However, many people want to increase their market or simply accommodate as many people as possible
What could a specification look like?
A specification for people with cognitive disabilities could have may different types of techniques:
Many techniques will not be difficult or an author burden, they just need to be specified.
Some techniques will not change the look of the page for “typical” users. They would instead enable adaptive interfaces or assistive technologies that help users with disabilities. In other words, the user runs an application that provides an alternative interface for them, that they find familiar and is tailored to their specific user group.
A different set of techniques could help the user find the right alternative content. For example, an author may make a simplified page as alternative content for some users. Meta data in the header would let the user’s browser default to the simplified version.
Some techniques could produce different versions of the same page based on content that changes on the user profile or choices.
Some strategies
Work with as many interested parties (stakeholders) as possible.
Working with as many interested parties as possible means that we will have the right information to do a good job. To include: Groups involved with research and helping people with cognitive disabilities, tool providers and vendors, potential web sites who have a mandate for accessibility for people with cognitive disabilities and other standards organizations.
Do not reinvent the wheel - use techniques and technologies that already work:
A lot of useful work has been done already, and we can achieve a lot by pulling together or extending existing work. For example, integrating and extending WAI-ARIA roles and INDIE UI to enable adaptable content for our use cases.
Other useful work includes work done by IMS global, Department of Education, FP7 research projects of the European commission program challenge 5 and relevant projects such as FLUID.
Test test and test.
Make sure that any deliverables work and can be used by authors, tool providers, browsers, assistive technologies and of course check that they give real benefits to end users.
For each iteration of the draft specification, test results and results feedback will be used to make the next version of the specification better. To include:
Testing with use cases
Feedback from tool providers and assistive technology
Tested against requirements such as requirements for Evolvability
End user feedback
Fig 1. Using feedback and test results
This should also help promote support and adoption of the specification.
Identify risks, strength and opportunities.
There is some resistance to increasing inclusion for people with cognitive disabilities. However there are also opportunities and a growing awareness of the need for this work. We need to be aware of the risks as well as the opportunities so that we have a higher chance for success.
For example, we may also build a business case document to promote adoption of our work. There is a strong business case to support inclusion of these important groups. The global population is aging and the numbers of people living with dementia worldwide is expected to double every 20 years. Both business and governments are realizing that people with mild and moderate levels of dementia need to stay as active as possible and participate in society for as long as possible. On the other hand even a minor cognitive decline can make a lot of content too complex to use.
From a purely financial perspective, according to Georgia State University's Center for Mature Consumer Studies, today's mature market already controls 75 percent of America's wealth and 70 percent of its disposable income. Clearly, this expanding and under serviced demographic is an important group/ market for many web sites.
Another factor is the rise of The Internet of Things (IoT), where everyday physical objects will be connected to the Internet and will be able to identify themselves to other devices. Knowing how to make the control of these devices understandable is an essential part of enabling the aging population to maintain their independence, stay in the work force for longer and stay safe.
Make it extendable - know what you do not know.
One of the challenges of our topic is the huge range of different disabilities and types of limitations. It is very unlikely that we will address all the possible scenarios in the near future. Therefor it is important that we allow for adding techniques and user requirements as they are discovered. Related strategies may also include:
Focus on adaptability: We are unlikely to address all the profiles and user scenarios. However, some techniques give information about the content that makes content adaptable to different scenarios. Then assistive technologies can continuously create interfaces for different profiles and new user scenarios without requiring new content or new guidelines. With adaptive content, the author can accommodate many more users with very different needs with less effort. (See explanation and example in Appendix 1.) Note that we should also allow techniques that do not support adaptation.
Make it evolvable , so that techniques and guidelines can continue to develop as new user criteria are discovered. See Appendix 2 for discussion and example.
Help the author and tool providers.
Our work will only be useful if it is used. Supporting authors and any other stakeholders will make it actually worth doing. This may include:
Create informal authoring guidelines that are easier to use then a specification.
Checkpoints with testable statements and criteria that are compatible with WCAG 2.0 (when possible).
Information on who it helps with references
Non-normative explanation of why it helps
Create general guidelines
Appendix 1. Adaptable interfaces
To enable adaptive interfaces we would create semantics that the author adds to the page and that the user agent uses to create an alternative interfaces. The adaptive interfaces like an assistive technology and provides a familiar GUI tailored to the users cognitive strengths. As this interface is designed for the user/user group, all features are familiar and the same buttons and metaphor will be used across all conforment applications.
Fig 1. Screen shot for a complex interface
Fig 3. At the user end a toolbar could sit on top of the complex interface enabling the most important features (for users with mild cognitive decline).
Note that using adaptive interfaces enables many other adaptive interface used by different user groups , that sit on exactly the same content. For example, a different adaptive interface could provide symbols for people with extreme language disabilities or aphasia. However someone with dementia may find buttons with clear text simpler, as they will not be able to learn the new symbols. With adaptive content, the author can accommodate many more users with very different needs.
At the user end, or as a SAS or cloud applications, alternative instructions can also be made available, that are both familiar and understandable by the different user groups user.
Some advantages:
Easier for the author - they do not design for different disabilities, just add extra attributes in the markup
The look of the content has not been changed to enable accessibility for people with cognitive disabilities It looks the same and we have one page for everyone.
The usability of the tool bar is tested by AT providers who understand the user group much better then the content author
The same content could be used (via different adaptive interfaces) by many more types of users, such as people with extreme language disabilities, who can function much better using symbols. These are groups that the author could not be expected to design for. However the same semantics that enable a simple text interface would also enable a symbolic interface.
It would cross barriers of languages and cultures, as the same semantics could be used for user interfaces in different languages or with different cultural references - increasing the business case for the use of this technology.
The specification would include:
Needed additional semantics of what things are and state values (roles and states for common controls such as open, close, save, scroll higher lower, ID information, security information etc) to be harmonized with existing standards.
Semantics related to audience (such as importance of features or sections of content)
Information to enable binding of different controls to AT with user focused interfaces
Supportive information such as additional labels or instructions for uncommon controls and function, or for additional labels and instructions for different user groups
Supportive ontology for meta-meta data about information , so that criteria such as instructions are tagged to map to appropriate audience (such as reading level of instructions, assumptions, metaphors used) The intent is that different user groups can be defined at later stages and by independent organizations, and new alternative adaptive interfaces created for preexisting content.
Defined steps, and instructions repository, (using ontology above)
All ontologies should be based on abstract categories, extendable, flexible and inferable, so that new criteria can be added, at any stage, as more is learned about cognition and barriers to comprehension for different persona.
Worked example
Without adaption semantics, techniques to help people with early stage dementia may include:
Each action / selection/ decision is defined as a step and has instructions or is a standard well defined step (such as click next)
Restrict the number of visible features to a maximum of five for early stage dementia and two for moderate dementia.
Clear step by step instructions are made available for each feature/action/selection/decision.
Use metaphors that the user is likely to be familiar with for over five years.
Provide (EARL?) statement of who can use this content.
These techniques would be tagged as helpful for the following cognitive use cases:
Impaired short term memory
Low general IQ
(Note we may create these tags based on cognitive function rather then disabilities to enable flexibility (as cognitive disabilities come with huge variations and are often reclassified). These tags can be mapped to known disabilities.)
With adaption semantics, we provided semantics to enable adaptive interfaces for these user groups.
The author now only needs to:
Tag 3 features as most important and an additional 2 feature as important. .
Provide information to allow binding of events between the adaptive interface and the standard interface for important features.
Tag important features with common roles (such as open, next etc.). This will be mapped to standards instructions at the user end. The author will not need to provide instruction for common features.
Note that The same content could be used (via different adaptive interfaces) by may more types of users, such as people with extreme language disabilities, who function much better with symbols rather than words.
Appendix 2: Making abstract guidelines.
There may be value in making the specifications abstract and ontology based. This may enable adaptive interfaces, evolvibility and actually make the specification itself evolvable.
One way would be to make abstract case and allow real user profile to fill in the specifics. This may work if we identify what determines both perceived and real issues of complexity that effect barriers to entry in communication, transfer of concepts and usability for any given user persona or group. These relationships could be generalized to apply to any object and any user. You could think of these relationships as a formula where the variables can be filled in so that they refer to real technologies and users.
For example, an important factor is the extent that a user understands any metaphors used by the technology.
A piece of content may be explaining a concept. To aid user understanding it uses the analogy or form of an avatar game as a metaphor. The intent is that the user will find it easier to understand the concepts when paralleled to an avatar game. However, if the user is not familiar with this type of game, then the content has become much more complex because of the metaphor. Hence the familiarity of the user with the metaphor is a key issue for usability. On the other hand what metaphors the audience is familiar with, and what metaphors are used in an objects are real and usable characteristic that can be applied. Another metaphor example could be the interface, for example, making web links look like a dial or a button.
These issues could be directly compatible to creating guidelines, that apply the abstract to create practical instruction for a given user group. So for example, if instructed to include users in the aging community with significant short term memory decline over the last 5 years- the applied guideline could be: Avoid metaphors and interfaces analogies that were not common 5 years ago.
Protocols such as The Resource Description Framework (RDF) with open source inference en&gins may help this be practical.
