<Lisa> https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Main_Page#What_documents_do_we_have.3F
<Lisa> scribe: Jennie
+present
Lisa: starting with introductions
today.
... any preferences on length of today's meeting?
<JohnRochford> It is truly my honor to be working with all of the COGA Task Force.
<Lisa> https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Main_Page#What_documents_do_we_have.3F
Lisa: Starting with overview of
documents.
... This group prefers to use Google Docs for working
documents, and then move them over to github.
<Lisa> https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Main_Page#What_documents_do_we_have.3F
Lisa: suggest bookmarking this
document - it has the table of contents, and other important
links.
... Summarized important points from research, organized by
disabilities - in the research document.
... this is a working draft.
... Issue papers is next, and being updated.
... Issues papers - takes a topic, and looks at that more
broadly. What works for those with different types of
disabilities.
... Issue papers have not been formerly published.
... Gaps analysis: some things got added into WCAG, but not
solved as wished.
... Gaps analysis and road map is a summary, user needs, how
technology could help solve the user needs.
... in 3rd working draft. Actively working on now. It's use is
for people making standards - how could the standards solve
these problems.
... Making It Better (Layer 3): instead of relying on other
groups, doing some ourselves.
... Trying to make it a separate document. How to make content
usable for people with disabilities.
<Lisa> https://w3c.github.io/coga/content-usable/
Lisa: hopefully permanent link
coming soon.
... publishing separately hoping more will get into WCAG, and
will be useful for next generation of guidelines (Silver,
AG).
... guidelines requirement: be extremely testable. This
document postpones the testable pieces, but is more about what
you need to do.
... goal: plain language, tell people what is helpful.
... Gaps analysis audience: W3C standard makers.
... Design Guide: name chosen to distinguish it from legal
requirements.
Abij: Is topography covered?
Lisa: Absolutely. That's exactly what couldn't be done in WCAG - can't tell people in legislation which fonts to use, but we can here.
<Lisa> https://docs.google.com/document/d/1poEoQjuWdAfWM3aOGPCwJRx7EvBsAtQ_99sGyS9Jlgc/edit
Lisa: Terms for COGA
documentation document
... As you find in any of the documents terminology that is
unclear to you, add them in this document.
... Glenda has been working on the feedback for theme 9.
<Lisa> https://w3c.github.io/coga/requirements/
<Lisa> https://w3c.github.io/coga/content-usable/
Lisa: Making Content Usable - how
to do user testing
... Design Guide: themes for design requirements.
... If you can't give feedback, you don't know the person
cannot use it.
... move feedback somewhere else? Keep it in the design guide?
Or both?
... Documents are published through Github, but collaboration
on working drafts is done in Google Docs.
<Glenda> Steve, see https://w3c.github.io/coga/content-usable/#design_themes where the 8 themes are listed. We needed content for “Feedback is usable by everyone”
<Lisa> https://w3c.github.io/coga/requirements/index.html
Lisa: leave it as a theme for now, because a theme is the high level of the design guide checklist. It is not meeting design recommendations unless it is met. And for simplicity recommend only putting it in one place.
Correction - Glenda's comment is above, not Lisa.
<Glenda> Then look here….https://w3c.github.io/coga/requirements/index.html#theme8 (see how it is short). I’m writing more content for that section :)
<Lisa> https://w3c.github.io/coga/content-usable/
Lisa: Alternatives: put it as a
section in the usable document.
... could also expand on data collection.
John K: agree with keeping it in its own section. It would give it a stronger presence.
Alastair: Feedback section within the Design Themes - it seems a mix of policy and design aspects. In the make usable document we should say make sure it is easy to provide feedback, and reference parts of the design guide where relevant. Maybe separate the policy pieces. Like the usability testing pieces at the top.
Glenda: that's why I like it as a theme. It can then be talked about in detail.
Lisa: We are thinking of promoting it to a higher level.
Glenda: I wrote it for the design guide.
Abi J: What is meant by feedback? It would be useful if discussed in the language used in the accessibility requirements.
<Lisa> https://docs.google.com/document/d/1poEoQjuWdAfWM3aOGPCwJRx7EvBsAtQ_99sGyS9Jlgc/edit
Lisa: we have used this term
inconsistently, so this is why we are using this
document.
... Abi - can you go through the documents, and add unclear
terms into the terminology document?
Abi J: yes.
Lisa: Theme 9 gives some specific things that belong in the design document, but also have a subject in the usable doc at the higher level - a chapter that says "why feedback is so important." Thoughts?
Glenda: that's fine. Can we agree for now to leave it as a theme, and focus on updating it in the design guide?
<Glenda> Have you seen it fleshed out here? https://docs.google.com/document/d/1aJE2C0FzzzXgydEp0MNGSdDDvUTTsANViUVvciFK36k/edit#heading=h.jmv8dajhvvom
<alastairc> AC: For what it's worth, I'm not clear what the content for the Feedback theme will be, at first read it seems to be a function that should be achievable, but not how to achieve it. Need to read Glenda's updates, but didn't have a chance before the call
Glenda: Being a theme is critical because you need to have usability testing for this use case.
Lisa: Should we have feedback is
simple to use, and is available at different check
points?
... Break these into two parts.
Glenda: When testing feedback you can test it all at once.
Lisa 9.3.1 could be feedback is simple to use. Then separate out the other part.
Glenda: Confirmed: it is remaining a theme, and we will break it in 2.
<Lisa> https://docs.google.com/document/d/1aJE2C0FzzzXgydEp0MNGSdDDvUTTsANViUVvciFK36k/edit#
Jennie: I will check which one was assigned to me and complete it by next week.
Alastair: I would rather do the
CFC email.
... This is for the new document for Makes Usable and Design
Requirements. I will send a draft on the list.
Lisa: This CFC does not include taking what was the appendix and moving it.
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Present: stevelee kirkwood Glenda JohnRochford MichaelC Roy alastairc WARNING: Replacing previous Regrets list. (Old list: EA, and, steve) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ EA, janina_and_steve WARNING: Replacing previous Regrets list. (Old list: EA, janina_and_steve) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ EA, janina Regrets: EA janina Found Scribe: Jennie Inferring ScribeNick: Jennie WARNING: No "Topic:" lines found. WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting 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: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report 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]