W3C

- DRAFT -

Cognitive and Learning Disabilities Accessibility Task Force Teleconference

25 Jan 2021

Attendees

Present
Shawn(for_part), Rachael, bruce_bailey, LisaSeemanKest, Jonny_James, JakeAbma, Judy, mbgower, kirkwood, AbiJ
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Abi, AbiJ

Contents


<Rachael> Meeting: Content Usable Wording Meeting

<Rachael> We will be working off of: https://docs.google.com/document/d/1cEaoEV_IFWi7WIc9WsAmXfEnhABt4jnvv6C2V5n_9kI/edit?ts=600ddf77#

<Rachael> scribe: Abi

<Rachael> scribe: AbiJ

<Rachael> https://docs.google.com/document/d/1cEaoEV_IFWi7WIc9WsAmXfEnhABt4jnvv6C2V5n_9kI/edit?ts=600ddf77#

Framing language

Rachael: Provides background. In Autumn, we reached agreement to publish first version but to have a follow up meeting on these issues

<Rachael> https://docs.google.com/document/d/1cEaoEV_IFWi7WIc9WsAmXfEnhABt4jnvv6C2V5n_9kI/edit?ts=600ddf77#

Rachael: see document for topics we will be discussing

<Rachael> 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 increase accessibility for people with cognitive and learning disabilities.

Rachael: will be discussing framing language

<Rachael> The Objectives and Patterns presented here give supplemental guidance beyond the requirements of WCAG. They address accessibility barriers that could not be included in the normative WCAG specification and may not otherwise be addressed.

Rachael: have pasted current abstract and introduction

<Rachael> barriers that could not be included in the normative WCAG specification

<Rachael> that were not be included in the current normative WCAG 2.x

Rachael: focussing on comment about barriers ... as pasted

<Rachael> that are not currently included in the normative WCAG 2.x

<LisaSeemanKest> +1 to current lang

Rachael: are we happy with proposed language? Or prefer proposed alternatives

<Zakim> MichaelC, you wanted to favor first bullet

Judy: is there a link to the referenced version for WCAG?

<LisaSeemanKest> we can just add that as a to do

<shawn> [ Shawn not strong opinion -- except edit needed I think - "be" -- " that were not be included in the current normative WCAG" -> " that were not included in the current normative WCAG"]

<LisaSeemanKest> +1

<Rachael> They address accessibility barriers that were not be included in the current normative WCAG 2.x and may not otherwise be addressed.

Lisa: we have an action to add links to documentation so can include a link to the appropriate standard

<Rachael> They address accessibility barriers that were not included in the current normative WCAG 2.x and may not otherwise be addressed.

Rachael: poll on the proposed language as pasted

<LisaSeemanKest> +1

<Rachael> straw poll: "They address accessibility barriers that were not included in the current normative WCAG 2.x and may not otherwise be addressed." with a link to WCAG 2.x

<MichaelC> +1

+1

<Rachael> +1

<Jonny_James> +1

<JakeAbma> +1

<mbgower> +1

<alastairc> +1

<shawn> +0 totally fine with it and won't vote

<MichaelC> Suggest this link: https://www.w3.org/TR/WCAG2/

<MichaelC> which will update as versions are updated

<Rachael> Judy: +1

Rachael: additional point in abstract language

<Rachael> Current language: Following the guidance in this document is not required for conformance to WCAG.

<Rachael> Suggested language: Following this guidance...

<Judy> [JB was a +1 on the question asked above when I'd dropped offline]

<shawn> +1

<bruce_bailey> +1

<LisaSeemanKest> +1

<alastairc> That's fine for me, better than "the"

Mike: concerns about readability

<Rachael> Following this guidance is not required for conformance to WCAG.

<LisaSeemanKest> the guidance

<Judy> +1 ok with the "following the guidance"

Rachael: clarified that this document will also be removed

<shawn> +1 in general for abstract to be shorter as appropriate

<LisaSeemanKest> +1 to as is

<JakeAbma> +1 to MC

<Rachael> stawpoll on language:

<Rachael> Abstract: The Objectives and Patterns presented here provide supplemental guidance beyond the requirements of WCAG. Following this guidance is not required for conformance to WCAG. However, following this guidance will increase accessibility for people with cognitive and learning disabilities.

<alastairc> I think they both make sense in context, so don't have a problem.

<Rachael> Introduction: The Objectives and Patterns presented here give supplemental guidance beyond the requirements of WCAG. They address accessibility barriers that were not included in the current normative WCAG 2.x and may not otherwise be addressed.

Mike: main concern is that all concepts covered in the introduction and abstract
... are included in the document

Shawn: is the point about this guidance is not required for conformance included in the introduction?

Rachael: it is included in the how to use the document section

mbgower: the abstract included the statement about conformation so I would except that there would be a section in the document that expands on this

<Zakim> shawn, you wanted to say abstract says "Following this guidance is not required for conformance to WCAG." wording introduction is not nearly as clear. I think it needs to be as

LisaSeemanKest: we have so many request to not add additional content. These sentences were added at the request to clarify the relationship of this document to WCAG. Adding more content could be a distraction

shawn: All content in the abstract should be in the document. Maybe we need to repeat the sentence from the abstract in the introduction

alistairc: this sentence is more of a usability point of view to make it clear to readers that are different.

<shawn> +1 to adding that sentence in the introduction

<mbgower> I can live with it as it is. Lisa gave reasons for the current state of the doc.

Rachael: I am hearing that we should add the sentence on conformance explicitly in the introduction

+1

<JakeAbma> +1

<Rachael> strawpoll: Add "Following this guidance is not required for conformance to WCAG." to introduction

<bruce_bailey> +1

<mbgower> yep

<LisaSeemanKest> +1 happy iether way

<Jonny_James> +1

mbgower: can live with adding it

<Judy> +1 lean towards adding it as it's essential info

RESOLUTION: add Following this guidance to the introduction and revised wording discussed here.

Friendly vs Usable

<Rachael> Making websites and applications that are friendly for people with cognitive impairments affects every part of design and development.

<Rachael> Making websites and applications friendly for people with cognitive impairments affects every part of design and development.”

Rachael: friendly and usable are used throughout the document

<Rachael> acl AbiJ ;

Lisa: raised concerns about passive and past tense

<shawn> AbiJ: friendly and usable not direct correlation between those terms. Usable more quantative.

<shawn> ... vote for usable over friendly. wider context. more easily measurable.

<shawn> ... "friendly" seems not for me

<Judy> [JB thinks that "usable by" conveys more seriousness than "friendly to"]

<Zakim> shawn, you wanted to slightly prefer "usable by" or "usable to". don't object to other options. and +1 to active voice!

<alastairc> +1 for "usable for", by/to didn't sound right in the sentence overall

MichaelC: if we are using friendly then we should make sure that we are linking this to usable.
... e.g. friendly should be defined in the introduction or glossary

<mbgower> yep

<Rachael> Strawpoll: "Making websites and applications usable by people with cognitive impairments affects every part of design and development." Change friendly to usable everywhere in the document and change to active voice.

<Jonny_James> +1

<bruce_bailey> +1

<LisaSeemanKest> +1

<Judy> +1

Rachael: suggesting usable "by"

+1

<shawn> +1 to "...usable by people with cognitive..."

RESOLUTION: "Making websites and applications usable by people with cognitive impairments affects every part of design and development." Change friendly to usable everywhere in the document and change to active voice.

Sentence vs. List Structure

<Rachael> Some accessibility features will help people with cognitive impairments. 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.

Rachael: pasted in sentence from the introduction which includes a list of one word things
... question is should this be presented as a list

<LisaSeemanKest> I prefer the list

<alastairc> Would have thought should be list, but defer to plain language folks

<shawn> AbiJ: pref list for readability

<Rachael> strawpoll: Make it a list format

<LisaSeemanKest> +1

<alastairc> +1

<bruce_bailey> +1

<mbgower> +1

+1

<Judy> 0

<Rachael> +1

<Jonny_James> +1

<shawn> 0 (I'm not aware enough of the context) totally fine with list

RESOLUTION: Make it a list.

mbgower: I recall there was clear guidance from COGA that we should use bullet point lists but should acknowledge that too many lists can reduce readability

Shawn: lists bring more emphasis to the items and sometimes you don't want it to have that much emphasis

<LisaSeemanKest> +1 to bold

Framing language

Rachael: essential is bolded in both the introduction and the design guide
... read from the introduction where bold is use

Judy: if I was looking the document for the first time have "essential" bolded in numerous places is confusing when we have a statement in the introduction that this is not required for compliance.

Lisa: I can live with removing bold but would prefer to keep it as it is underlines the difference between improving usability for everyone but some of these patterns are essential for people with cognitive disabilities

<shawn> AbiJ: while understand... support not bolding here. sicnce the document uses bolding for concepts.

<Rachael> strawpoll: remove bold on the word essential

<alastairc> 0

<LisaSeemanKest> -1 but can live with it!

<Rachael> 0

<mbgower> 0

<Judy> +1

<shawn> 0 (fine with it)

<bruce_bailey> +1 to unbold

<Jonny_James> 0

RESOLUTION: Unbold the word essential

Friendly vs Usable

“The Objectives and Patterns build on the..”

<Rachael> The Objectives and Patterns build on the:

<Rachael> alternative 1: The Objectives and Patterns build on prior work:

Rachael: we agreed to discuss 2 alternatives

<Rachael> alternative 2: The Objective and Patterns build on prior research by the COGA Task Force:

Rachael: alternatives are followed by the links to the research and prior work

<Rachael> strawpoll: Leave current language

<LisaSeemanKest> +1

+1

<shawn> 0

<kirkwood> +1

<alastairc> 0 no passionate opinion, happy either way

<Rachael> 0

<Jonny_James> +1

<Judy> 0

RESOLUTION: leave current language

“Some design patterns create barriers for people with disabilities”

<Rachael> Some design patterns create barriers for people with disabilities

Rachael: statement in the introduction

<Rachael> suggested change: The objectives and patterns create barriers for people with disabilities

<shawn> -1

<mbgower> -1 (missing something?)

<LisaSeemanKest> keep oringinal

<Rachael> document: http://raw.githack.com/w3c/coga/part1-from-googledoc/content-usable/index.html#introduction_for_usable

Rachael: initial concerns about the phrasing. Are there any concerns about the current phrasing?

<Rachael> full paragraph for perspective: 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.

<Zakim> shawn, you wanted to say "designs"

<Rachael> suggested revision from Mbgower: Some current design patterns create barriers for people with disabilities.

Shawn: you can use alternative words to design patterns

<Rachael> shawn: Some current design create barriers for people with disabilities.

<alastairc> "Some designs create barriers for people with disabilities."

<LisaSeemanKest> some designs create

<shawn> +1 to "Some designs create barriers for people with disabilities."

<shawn> AbiJ: About "current", that puts a time aspect, and maybe not as good for those reading document later.

mbgower: design patterns are a subset of designs, so designers don't always use patterns

<Rachael> strawpoll: Some designs create barriers for people with disabilities.

<mbgower> "Some common design...

<shawn> +1

<alastairc> "Some designs create" or "Some common design patterns create", either are good.

+1

<bruce_bailey> +1

<LisaSeemanKest> +1 Some designs create

<Jonny_James> +1

<kirkwood> +! to common

<shawn> -1 to "patterns"

<Rachael> strawpoll: Some common design patterns create barriers for people with disabilities.

<shawn> 0 to common

Judy: it would be useful to differentiate from patterns in the document but base it in website design

Shawn: I am confused about why we have to use patterns. But I can live with it

<mbgower> 'Some common designs create...'

<Rachael> strawpoll: Some common designs create barriers for people with disabilities.

<mbgower> +1

<LisaSeemanKest> +1

+1

<kirkwood> +1

<Judy> 0

<bruce_bailey> +1

<alastairc> 0

<shawn> +0.75 (not sure "common" is needed)

RESOLUTION: Some common designs create barriers for people with disabilities.

<Jonny_James> 0

Friendly vs Usable

judy's point

<Rachael> Traditionally, accessibility focused on making the interface usable for people with sensory and physical impairments (vision, hearing and/or mobility).

Judy: frist sentence of 2nd paragraph in the introduction could be ambiguous that could reduce the impact of cognitive disability supprot

<Rachael> proposed text: Traditionally, accessibility focused more on making the interface usable for people with sensory and physical impairments (vision, hearing and/or mobility).

Judy: the word "focus" can be ambiguious as some see it as working as explicitly excluding cognitive disability support which is not correct
... proposing "focused more" to ensure that the sentence clearly represent the historical context

<Zakim> shawn, you wanted to ask purpose of sentence and to say parctitioners...

Shawn: i strongly agree with Judy. It would be good to understand what the sentence is trying to convey

Lisa: this is to help clarify why this guidance is supplemental to WCAG and why it wasn't fully addressed in these guidelines
... this sentence is needed to explain why this document is being published.

<Zakim> Judy, you wanted to say that not everyone thinks why wasn't it; some people are focused on "and how should I regard this new info going forward"?

<LisaSeemanKest> i can live with Judys suggestion

Rachael: can we take this offline and address by email

<Zakim> shawn, you wanted to say important that some went in, though not fully addressed and to say not lasck of focus -- just the other parameters

<LisaSeemanKest> sounds great

Judy: I think it will be difficult to address the past but would like to work on a sentence that is more forward focussed

Shawn: I agree that we can tweak this to get the message across in a positive way

<kirkwood> I would be interested in the language discussion.

RESOLUTION: Judy, Rachael, LIsa, John, and Shawn to rework the paragraph to be more forward facing.

Summary of Action Items

Summary of Resolutions

  1. add Following this guidance to the introduction and revised wording discussed here.
  2. "Making websites and applications usable by people with cognitive impairments affects every part of design and development." Change friendly to usable everywhere in the document and change to active voice.
  3. Make it a list.
  4. Unbold the word essential
  5. leave current language
  6. Some common designs create barriers for people with disabilities.
  7. Judy, Rachael, LIsa, John, and Shawn to rework the paragraph to be more forward facing.
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.200 (CVS log)
$Date: 2021/01/25 18:25:30 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision VERSION of 2020-12-31
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/so sometimes it can have a detrimental impact/and sometimes you don't want it to have that much emphasis/
Default Present: Shawn(for_part), Rachael, bruce_bailey, LisaSeemanKest, Jonny_James, JakeAbma, Judy, mbgower, kirkwood, AbiJ
Present: Shawn(for_part), Rachael, bruce_bailey, LisaSeemanKest, Jonny_James, JakeAbma, Judy, mbgower, kirkwood, AbiJ
Found Scribe: Abi
Found Scribe: AbiJ
Inferring ScribeNick: AbiJ
Scribes: Abi, AbiJ

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]