w3c / coga Goto Github PK

I haven’t finished reading the whole document yet but I wanted to leave a comment than it’s really flipping good. It’s clear and it’s a great resources I am already sharing with teams around the BBC.

Thanks for all the effort and energy to get it this far :)

Comment from UMD to "Avoid busy patterns because they are visually confusing" and "“brain blindness”: where the person has capable vision but the brain  is no longer able to process or find the right match for what they’re seeing. Contrast is very important because of changes in vision as a result  of certain dementias. Color orientation is not always reliable for people with dementia  because they may associate colors differently or not understand what the color is meant to represent"

While these are addressed by low vision and in WCAG there are unique cognitive aspects to this area and we should review to ensure we've covered those.

Should Persona be plural in the headings?
Fix parallel structure in the lists in 5.2, 5.4.1, and 5.5

• The document is very big as it is and the appendicies add extra bulk
• Appendix C is probably more than an appendix and would be better as a separate document

This new issue opened as Lisa thought in #133 the WAI website cognitive landing page could be reviewed by the TF,

Note: this page is a WAI staff page that the COGA TF have a particuar interest in.

Important: Please change some persona names so diverse ethnicities are included.

Minor: Mixed up the order of female and male a bit more.

minor copy edit suggestion:

The Objectives and Patterns presented here provide Supplemental Guidance beyond the requirements of WCAG. Following the guidance in this document is not required for conformance to WCAG. However, following this guidance will improve the accessibility for people with cognitive and learning disabilities.

to

The Objectives and Patterns in this document provide supplemental guidance beyond the current requirements of WCAG. Following this guidance is not required for conformance to WCAG. However, following this guidance will improve accessibility for people with cognitive and learning disabilities.

Throughout the document there are a number of tables (e.g., in section 2 Cognitive Function Table and Tags) and the tables have no formatting at all. This makes it very hard to read, especially if the table is long and / or wide.

Please add some styling to the tables so there are at least borders. If possible, style it such that the table heading remains on the screen as a reader scrolls through the table so the column meanings remain obvious.

The document uses a few terms which come across as judgmental. I'd consider rephrasing to talk about impairment or a relevant measurable metric.

For example:

3.2.2. use of the term "weak"
"memory impairment, weak executive function and/or weak language processing skills"
would be better phrased as: "memory, executive function and/or language processing impairments"

4.7.5.3. use of term "strong"
"Without strong reasoning skills the user is likely to select the wrong menu option."

6.3.5 use of "bad"
"Anna has bad eye hand coordination"

3.4.2 use of "give up:
"As a user who often makes mistakes or touches the wrong thing, I want to be able to undo what I just did quickly and easily so that I can manage to use applications and not give up."

"Give up" might be a sensitive phrase for some people. It's often used in a negative way to imply someone is lazy or not trying hard enough. In this scenario the user has been excluded or has become fatigued. Perhaps "so that I can manage to use applications before I become fatigued"

In the guide "Making Content Usable for People with Cognitive and Learning Disabilities", you mention several times "easy to read" but you do not define it and you do not explain how to make it.
We would like to suggest you:

• Add it to the glossary
• An ISO standard about easy to read is going to be created. We encourage you to link it.

Thank you for your work.

Are we updating the main primary w3/coga OR are we forking the repository, making our updates, then issuing pull request? Also if I fork the repository will it keep in sync automatically or is there a refresh option in this tool?

Travis CI sent a message this week alerting of a bug in the way they used to encrypt environment variables. Owners of this repo should have received it.

Depending on the way encryption was done in this repo using the Travis CLI, those values might have leaked.

This is a reminder for maintainers of this repository to make sure they discard old values, and re-encrypt new ones with the latest version of travis, now that the bug has been fixed.

Please close this issue if action has already been taken. Feel free to ping me or sysreq if you need help.

1. Consider changing "Making websites and applications that are friendly for people with cognitive impairments affects every part of design and development." to "Making websites and applications that are usable for people with cognitive impairments affects every part of design and development." Also discuss "to" vs "for". (NOTE: This is also in the Design Guide Introduction)

2. Consider whether "Often the issues that affect people with cognitive and learning disabilities include design, context, structure, language, usability, and other factors that are difficult to include in general guidelines." should be presented in list form.

3. Consider removing the bold from: Some design patterns create barriers for people with disabilities. The patterns presented in this document have been designed to avoid such barriers for people with cognitive and learning disabilities. While this guidance may improve usability for all, these patterns are essential for some people with cognitive and learning impairments to be able to use content independently. (NOTE: This is also in the Design Guide Introduction)

4. Consider changing "The Objectives and Patterns build on the:" to "The Objectives and Patterns build on prior work" or "The Objective and Patterns build on prior research by the COGA Task Force."

5. Consider switching the paragraph "Some design patterns create..." with "The objectives and patterns..."

Location: https://rawgit.com/w3c/coga/master/techniques/index.html#limit-the-number-of-features-and-choices-on-the-same-screen.x

This section demonstrates the use of an aria property, aria-importance.

This property does not exist in WAI-ARIA 1.0 nor does it exist in any draft I can find in 1.1. Furthermore, no results are found in a Google search: https://www.google.com/search?q=site%3Aw3.org+aria-importance

• If this property is simply some sort of "made up" example, it should be removed. Even though this techniques document is in Draft status, it is still discoverable to laypersons who don't know any better.
• If this property is in some sort of "proposed" status, please provide a link to the proposal and/ or a note regarding its status.

Thank you.

Suggestion from UMD review:

Relatedly, spatial representations can be very important for technology use. For example, we have spoken to people that use spatial representations on their desktops as a sort of filing system.

Action: Explore this further.

Not sure on this one, it might be a Jamie thing. I had to read carefully to work out if maths was short for "mathematical" the concept, to "math" the action.

Consider whether to use Do/Don't instead of Use/Avoid. If changed, go through examples and change to active tense (Use…) to fit with the revised Do and Don’t. If not changed, review for language consistency.

Source: Recommendation from the AG working group review.

There is a broken reference link https://docs.api.ai/docs/reminders-and-notifications in section https://www.w3.org/TR/coga-usable/#more-details-35, it looks like the website moved their documents to other place, we could fix that in next updating working drat.

Please add a glossary to clarify terms that may be ambiguous or cause confusion across cultures.

From @AreaOfAKite on July 1, 2018 19:24

URL:
https://www.w3.org/TR/coga-gap-analysis/#introduction

Section:
Introduction

Issue:
Bullet #6 is duplicated content from bullet #5
"Attitudes and misinformation can also ..."

Copied from original issue: w3c/wai-news#4

Item 41 just shows up as raw HTML.

Migrated from personalization semantics issue 20 filed by @plehegar

In 2.3.2.2 Solutions for security and privacy, keygen is listed as a solution.

However, the latest version of HTML indicates:
[[
keygen has been removed
]]
http://www.w3.org/TR/html52/changes.html#changes-fpwd

I went to make change and wasn't sure without looking whether to start in gh-pages or master. If the process is light, you could just add a blurb in the README.

The section "3.5 Table 5: Simple and clear interface" mentions coga-destination="home" for new semantics. I wonder wether it would be better to use rel="home" instead. It has been proposed quite a while ago and is probably already in use (I do not have any data on that though).

coga/gap-analysis/index.html

Attitudes and misinformation can also become a barrier to inclusion for people with cognitive disabilities. For example, developers that may feel people with cognitive disabilities are not in their “target audience” and so have no interest in their inclusion. Also, studies of usability often over-sample college students. Thus the results work less well for groups who are not well represented among sub-groups of college students (such the aging population).

https://www.w3.org/TR/coga-usable/

Thank you all for your work on this topic! I'm looking forward to reading through more in depth.

I'm concerned about how white and Eurocentric the personas seem to be. Does that also reflect the research that these guidelines are based on? If so, there should be a disclaimer for clarification. That just stood out to me as odd, especially within international guidelines.

Emailed comment from UMD.

Sensitivity to loud and complex environments (overloaded by over stimulus) often with heightened sensitivity to sound

Avoid busy patterns because they are visually confusing

These are partially included in 3.6.2 Limit Interruptions but could be clearer. Explore 3.6 Help Users to Maintain Focus and integrate them as appropriate

I have reviewed the document here: https://www.w3.org/TR/coga-usable/ and noticed the document makes use of person first language (with autism, has autism) when referred to autistic people.

Much like with the Blind and Deaf community, there is a well established norm of using identity first language (autistic) when referring to autistic people.

Sources:

NHS: https://www.england.nhs.uk/learning-disabilities/about/get-involved/involving-people/making-information-and-the-words-we-use-accessible/
NAS: https://www.autism.org.uk/get-involved/media-centre/how-to-talk.aspx
Research: https://www.autism.org.uk/describingautism,
Advocacy groups:

• ASAN (US) https://autisticadvocacy.org/about-asan/identity-first-language/
• AAA(Austrialia) https://www.autismawareness.com.au/resources-01/making-sense-of-language/

Agreed upon language for wide review: The Objectives and Patterns presented here provide Supplemental Guidance beyond the current requirements of WCAG. They address accessibility barriers that could not be included in the normative WCAG 2.x specification and may not otherwise be addressed.

There needs to be further discussion with all parties about the bold content. Other suggestions include:

• that were not be included in the current normative WCAG 2.x
• that are not currently included in the normative WCAG 2.x

No longer needed as we removed Appendix C from content usable, which was the only reference to it. Is also out of date

Also review tests.html

Hi,

Many links are pointing to local file per example: in coga/techniques/index.html
in chapter 1.1 summary there is the list Main techniques include.

With link pointing to
file:///C:/Users/lseeman/Documents/GitHub/coga/techniques/index.html#provide-a-clear-structure"

https://www.w3.org/TR/coga-usable/#summary

1. @michael-n-cooper provided some css to improve the look of the lists. See below
2. The last item "Test with real users" actually applies to all the objectives and is not really one itself. It is allso a general a11y principle. Thus, I suggest it is moved out of the list. It can be made a stand alone paragraph at the end if it is felt to add somehting important that is coga specific.
3. We should be consistent with the list of Objectives as they are used throughout the document and provide a usefull high level list of topics to keep in mind for Cognitive Accessibility. In the summary "Objective 3: Use Clear and Understandable Content" has been split into two: "Help users understand with clear text and images" and "Provide support for different ways to understand content". I suggest they are remerged in the Summary or else if the distinction is concidered usefull the are separated in the rest of thee document (I do think there is some merit in that)

Suggested CSS

#summary li img {
   float: left;
   margin: 0 0.3em 0.5em -4em;
}
#summary ol {
   margin-left: 2em;
}
#summary ol > li {
   margin-bottom: 1em;
   list-style-type: none;
} 

The persona/index.html page contains links to www.aegis-project.eu which no longer appears to be responding to http/https

Example of these broken links
http://www.aegis-project.eu/images/docs/Personas/NiteshHQacc.pdf
http://www.aegis-project.eu/images/docs/Personas/PeterHQacc.pdf
http://www.aegis-project.eu/images/docs/Personas/martaHQacc.pdf
http://www.aegis-project.eu/images/docs/Personas/carlosHQacc.pdf

These links were added in
fe3db59b
and in turn come from the document
https://docs.google.com/document/d/18bjXRKSW7hT8PQyS2TCzPyo90i55pJamIGSdTrYdBIQ/

The third and fourth items are effectively the same

A.4.8 Pattern: Keep text succinct
Use short blocks of text:

Keep paragraphs short. Have only one topic in each paragraph.
Use short sentences. Have only one point per sentence.
Use bulleted or numbered lists.
Use bullets or numbered lists.

For example, in the main document where it has:

The Objectives and Patterns presented here provide Supplemental Guidance beyond the current requirements of WCAG. They address accessibility barriers that could not be included in the normative WCAG 2.x specification and may not otherwise be addressed.

I think it should include the wording agreed upon for the abstract -- with some further simplification of language:

The Objectives and Patterns in this document provide supplemental guidance beyond the current requirements of WCAG. Following this guidance is not required for conformance to WCAG. This guidance addresses accessibility barriers that could not be included in WCAG 2. Following this guidance will improve the accessibility for people with cognitive and learning disabilities.

Hello,

I am curious if this section should be more broad (or expanded upon) to include STEAM (science, technology, engineering, art, math). I notice great difficulty (similar - but different - to issues outlined in the 2.3.4 Math section) for individuals with cognitive and learning needs in these additional areas. Science (and the many subsets of this general field) are incredibly important to make accessible (whether in diagrams, materials, websites, language, etc.). Also, Art - this area is not frequently touched upon, but what are the best ways to make graphically complex images and such understandable to individuals with cognitive and learning needs?

Thank you!
Kelsey

https://github.com/w3c/coga/blob/master/user-research/add.html#L2

I'm pretty sure 'Description' should be 'ADHD' or similar.

https://github.com/w3c/coga/blob/master/techniques/index.html#L126-L136

These are all local file URLs and broken in the document linked from the wiki home page

https://www.w3.org/WAI/cognitive/

ASAP as we've been pointing people there

There are too many old branches making it hard to find the ones we want in the GitHub UI

Consider adding a Tag if we need to keep them.

README.md

https://w3c.github.io/coga/templates

Gives 404

The title and main header of the Techniques document has the word 'the' repeated twice in a row:

"Techniques for the The Cognitive and Learning Disabilities Accessibility Task Force (COGA)".

I believe that one of the two 'the' should be deleted.

https://w3c.github.io/coga/techniques/

At the top of the Techniques document, there is a link that reads "Latest published version". That link is broken (404 error).

https://w3c.github.io/coga/techniques/

Section A.2.1 is titled 'User Testing' - in keeping with common practice it would be preferable to call it 'Usability Testing' as we are testing the usability of something, not testing the users :) If accepted, there are other places that use the term 'user testing' - they should probably all become 'usability testing'

This is a test issue for exploring projects

Issue

The Venn Diagram appearing at the end of §2.2 Background about People with Learning and Cognitive Disabilities and the Web seems problematic.

Opinion & Interpretation

At their cores, accessibility is the absence of barriers, and usability is the quality of use. If it is not accessible first, it cannot be used, and therefore the quality cannot be measured. So accessibility should be a much larger circle and encompass usability.

Also, the diagram is interpreted by the relative scale of each area. So, the fact that the overlapping area of usable & accessible is so small, perpetuates the myth that only a small number of things can achieve both.

Suggestion

The text content of this section sufficiently describes the background. So the diagram could be removed with no impact on the content.

Add pattern to make it clear what is a close button and what is a cancel, and what happends when you click them... See https://lists.w3.org/Archives/Public/public-cognitive-a11y-tf/2019Sep/0003.html

from Ajit (from Google) on AAC: I took a little more time to look through the guidelines in this document. 

There were two best practices that I've had personal experience with during my AAC career, which I couldn't find references to in the document. Perhaps worth looking into (or feel free to point me to where they are in the doc). 

1. Object permanence. We frequently found that scrolling to find objects is challenging cognitively. This is true not just in the AAC use case but also for MCI. When we were doing research for Action Blocks, for example, we found some older adults putting all of their apps in folders on one page of the home screen - even if that makes the icons really small - because they didn't find paging through different screens cognitively easy enough.

2. Motor automaticity. This is a major theme in the AAC community, since a high level of cognitive burden due to the AAC app UI can interfere with the user's linguistic processes. There's a theme of keeping the same item on different screens always in a consistent physical location, so that the user can rely on muscle memory to activate and trigger them. I've found that this consistency greatly increases the learnability of user interfaces, particularly on touch surfaces.

Consider reworking the headings in Summary and reordering them Clear structure, clear design, clear content

Source: Suggestion from editorial review.