Re: comments on Making Content Usable for People with Cognitive and Learning Disabilities

Thank you!

I have opened  issue  197 <https://github.com/w3c/coga/issues/197> on
github, that should help us track how we are handling these important
points.

All the best

Lisa

On Fri, Sep 4, 2020 at 6:37 AM Clayton H Lewis <clayton.lewis@colorado.edu>
wrote:

> comments on draft of  Making Content Usable for People with Cognitive and
> Learning Disabilities
>
> from Nancy Ward, self advocate; Ben Genzel, multiple brain injury
> survivor; Clayton Lewis, Coleman Institute on Cognitive Disabilities
>
> Submitted by Clayton Lewis
>
> General comments: Nancy, who is a veteran of years of cognitive access
> discussions, and I reviewed the bulk of the document. We were both very
> impressed both by the content and the format. The use of personas, and the
> many concrete descriptions, are both excellent features. We feel the
> document is a wonderful step forward for COGA, and we congratulate those
> who have contributed to the effort. Ben, who is new to WAI and its work,
> and I reviewed the brain injury persona and associated scenarios.
>
> An issue that Nancy and I found in many sections, so will express once
> here, is the use of descriptions of capabilities, where needs are meant.
> Compare:
>
> "I need symbols to help understand essential content, such as controls and
> section headings." (from sec 3.1.3)
>
> with
>
> "I know how to use all the controls and the effects of each action." (from
> sec 3.1.2)
>
> We feel that the first example expresses the "need" much more clearly than
> the second, which actually describes not the need, but what would be true
> if the need were satisfied.
>
> We recommend an edit to put all of the needs descriptions into needs form.
>
> A general issue that Ben identifies, that may not be fully in scope for
> this document, but might be included as background, for example in one or
> more of the scenarios, is this. People with cognitive disabilities often
> struggle, with limited or no support, to acquire and configure the
> technology they need to access the Web. For these users, cognitive
> accessibility is a necessary but not sufficient condition for actual
> access. Those seeking to support people with cognitive disabilities via Web
> content, including policy makers, need to be aware of this problem.
> Similarly, many users will not be able to configure a text to speech tool.
> A site that aims to support people with cognitive disabilities could
> incorporate this facility directly.
>
> Relatedly, Ben notes that people with cognitive disabilities often need
> human assistance to negotiate problems they encounter, for example in
> navigating a large site. Gregg Vanderheiden's "rainbow" model (see e.g.
> https://trace.umd.edu/publications/modality-translation-services-on-demand)
> envisions a tiered structure of supports for users, in which the most
> difficult problems fall through to a method for requesting support from a
> human being. This is another matter that people seeking to support users
> with cognitive disabilities may want to address, when designing their
> services.
>
> Ben further suggests that site designers could consider whether they can
> detect user confusion or frustration, by analyzing user interaction
> patterns, and proactively offer assistance. For some users, recognizing
> that they need help is itself a difficult feat.
>
> Another suggestion from Ben: An "I'm lost" key could be useful. It would
> differ from a "help" key in that it would emphasize explaining where one is
> in a complex task, but explanations of controls or features.
>
> Specific comments:
>
> "breadcrumbs" meet a key need for Ben, but he doesn't know the pattern by
> that name; nor does Nancy. Include an explanation when first introduced,
> and refer to the explanation in other places where the concept is used.
>
> Sec 3.3.2 We're not clear what "implied content" means.
>
> Sec.3.4.1 re "I want long numbers that often have spaces, like credit card
> numbers, divided into chunks. That way I find it easier to check it.": the
> hyphens that divide numbers need to be big
>
> Sec 3.5.1 Ben seconds this one. Nancy suggests replacing "easily restore
> the context" by "easily understand the context". Some of the entries here
> seem a bit repetitive, and could perhaps be consolidated.
>
> Sec. 3.6.1 The heading "Previous steps" could perhaps be replaced by
> "Remembering what was entered in previous steps can be difficult"
>
> Sec 3.6.2 replace "I need the login process that does not " by "I need a
> login process that does not "
>
> Sec 3.6.3 replace "voiceXML menu" by just "voice menu". Many readers won't
> know what voiceXML is.
> replace "I want it to be simple, to go back every time I make a mistake"
> by "I want it to be simple to go back when I make a mistake"
> the item "I want the best practices for usability to be followed." seems
> out of place, as a rather abstract statement among more concrete or
> specific ones
>
> sec 3.7.2 replace "I need "easy to use" gestures on a touch screen that do
> not confuse me (or the possibility of alternative access)." by "I need
> "easy to use" gestures on a touch screen that do not confuse me (or the
> possibility of alternative access)."
> replace "personalize using my own" by "personalize the page using my own
> symbols"
> replace "For example, I find graphs much easier to understand than the
> same information in an article or academic paper" by "For example, I find
> graphs much easier to understand than the same information presented in
> text in an article or academic paper"
> replace "I need text to speech support, with synchronized highlighting, so
> I can follow as I go" by "I need a tool that can read text to me aloud,
> with synchronized highlighting, so I can follow as I go"
>
> add "I need to be able to make my reminders loud."
>
> Sec 3.7.3 is a little thin. Some of the content from 6.10.6 could be used
> to flesh it out.
>
> sec 3.7.5 suggest replacing "Explanations for unusual controls in a form I
> find easy to use (such as a video or text)." by "I need an interface that
> doesn't require me to use unusual controls that need explanations for me to
> use them."
>
> Sec 3.8.1 replace "I need to be able to express my ideas without so many
> words" by "I need to be able to express my ideas without typing so many
> words"
>
> Sec 3.8.2 Section should say that pages shouldn't do anything to block
> extensions and addons.
> replace "I need my add-ons, API's and extensions to work " by "I need my
> add-ons and extensions to work " (many readers/users don't know what an API
> is) Explaining what an "extension" would be good.
>
> Sec 4.2.2.2 In "Use common visual hierarchy, design elements, affordances,
> and patterns that are familiar to most users." the concepts of visual
> hierarchy and affordances need explanations for some readers. Perhaps:
> "Visual hierarchy" means dividing material into groups, in such a way that
> it is easy to see which material belongs to each group, and "affordance"
> means the way the appearance of something like a button suggests what
> action you can perform on it.
>
> Sec 4.2.2.4 replace "Uses common design patterns" by Use common design
> patterns"
> explain ARIA
>
> Query: is "A platform specific user interface design" appropriate for the
> Web? Anyway, some readers will not know what "platform specific" means.
>
> Sec 4.2.2.5 replace "When deciding pages" by "When designing pages"
>
> Sec 4.2.3: this material seems to already have been covered in the
> sections above
>
> Sec 4.2.3.6 replace "When all links on a page have keyboard focus the
> focus indicator looks the same." by "The keyboard focus indicator for links
> should look the same for all links."
>
> Sec 4.2.4.4 replace "(example: hidden behind accordions or a previous
> page)." by (example: information about previous steps is on previous pages,
> or has to be revealed by using a control) {some readers do not know what
> "accordion" means in this context.)
>
> Sec 4.2.5.2 seems to repeat earlier material, but does make some new
> points. Would consolidation be possible?
>
> "Making all the borders of controls clear other than textual links;" is
> confusing. How about "Making the borders of controls clear (though
> links in text don't need borders if identified properly.)"
>
> Sec 4.2.5.3 the definition "Controls are parts of web pages that do
> something, e.g. a link, button, checkbox." is good, but should be given
> earlier in the text.
>
> some material in this section seems redundant with earlier material
>
> Sec 4.2.6.2 Nancy seconds these recommendations!
>
> Sec 4.2.6.3 We're not sure what is meant by "Controls that affect only one
> section of a page is confusing." Perhaps "If a control on a page operates
> only on part of the page, it can be hard to tell what it will affect and
> what it will not. Clear borders, and grouping of things on the page, can
> help indicate what control will operate on what."
>
> 4.2.6.4 replace "Pages with scroll bars close together that impact
> different content areas." by "Pages with scroll bars close together that
> impact different content areas can be confusing. Use grouping, spacing, and
> borders, to show what controls what."
>
> Sec 4.2.7.5 replace "Provide symbols besides key texts, headings, media
> sections, contact us and help" by "Provide symbols next to key texts,
> headings, media sections, "contact us" buttons, and help buttons."
>
> Sec 6.1.4 replace "daughters bank" by "daughter's bank"
>
> Sec 6.3.3 what is an ejournal? Perhaps restate the example so as not to
> require this term?
>
>
> Sec 6.3.4 replace "emails and newsletter " by "emails and newsletters "
> replace " to try and scan read and skip through" by "to try and scan and
> skip through"
>
> Sec 6.8.1 replace "Maria Scenario 1: Finding Key Information on Dynamic
> Websites" by "6.8.1 Maria Scenario 1: Finding Key Information on Websites
> where Information Appears and Disappears", and replace "a lot of dynamic
> elements" by just " a lot of elements". (many readers don't know what
> "dynamic" means.)
>
> Sec 6.8.2 simplify "inhibits her brain from producing the cells necessary
> to form new memories" to "inhibits her brain from forming new memories"
>
> Sec 6.10 Ben appreciates this section, and feels it does a pretty good job
> of describing some of the challenges of brain injury survivors. There is a
> matter that is alluded to in Sec 6.10.5 that Ben suggests adding to the top
> level description, after "larger places, documents and websites.": "Tom
> often feels that his reserve of mental energy is small, and easily used up,
> so that after dealing with one problem he may feel unable to tackle
> another."
>
> The problem of getting lost in a complex site, mentioned in the top level
> description, rings true for Ben. He generalizes this to include keeping
> track of what one is doing in complex tasks. A scenario focussed on this
> problem specifically would be helpful, bringing out how important it is for
> Tom to have the steps of tasks clearly presented, and a mechanism like
> breadcrumbs that helps Tom keep track of where he is in a task with
> multiple steps.
>
> Because of the problem of limited reserves, mentioned earlier, Ben also
> emphasizes the importance of keeping tasks as simple as possible. "It can't
> ever be too simple," he says.
>
> Sec 6.10.2 Ben suggests that word completion or prediction should be
> mentioned as a helpful feature here.
>
> Sec 6.10.3 Ben says that being able to easily shift to a larger font can
> help when text is hard to understand. That is, trying to read smaller type
> takes up mental energy that isn't available for trying to understand what
> is being said.
>
>
>
>
>
> Clayton Lewis
> Professor of Computer Science
> Co-Director for Technology, Coleman Institute for Cognitive Disabilities
> University of Colorado
> http://www.cs.colorado.edu/~clayton
>
>
>
>
>
>
>