COGA FtF Day 1 -- 28 Jan 2019

introductions

<LisaSeemanKestenbaum> https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Main_Page#What_documents_do_we_have.3F

<stevelee> Introductions

<stevelee> Also present Neil Milliken Jamie Knight, Ollie

<stevelee> Prof Leslie Carr of Uni of Southampton and W3C network of offices popped in to say hello

<LisaSeemanKestenbaum> https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Main_Page#What_documents_do_we_have.3F

<stevelee> LSK - recap off the state of our documents

<stevelee> 1) User Research - https://w3c.github.io/coga/user-research/

<stevelee> 2) Issues Papers (Research) - https://w3c.github.io/coga/issue-papers/

<stevelee> 3) Gap Analysis (aimed at spec writers) - https://w3c.github.io/coga/gap-analysis/

<stevelee> 4) Content Usable (Whole story for devs) - https://w3c.github.io/coga/content-usable/

<stevelee> 5) Design Guide (best practice and techniques - wider than WCAG SCs) - https://w3c.github.io/coga/design/

<stevelee> Lion - "a sentence should describe one concept well and one concept badly"

<stevelee> JK I didn;t get policy section in Contents Usable - who for> Why?

<stevelee> LSK - not written yet - for people who are creating policies, eg for companies or government

<stevelee> LSK - they won't read Design Guide - need more of an overview

<stevelee> JK - so high level for people who do not create websites

<LisaSeemanKestenbaum> ac j

<Zakim> janina, you wanted to suggest this still needs to point to the best possible User Needs doc

<stevelee> Outcome focused regulation for finacial markets might be a useful technique

<stevelee> LSK - some key terms to keep in mind

<stevelee> 1) Standard - eg WCAG. W3C process MUST be followed

<stevelee> 2) Note - Published but process is not globally defined

<stevelee> MC usually not something that requires testability

<stevelee> MC notes could be republished with same version number (but COGA doesn't have to do that)

<stevelee> LSK we have some flexibility with notes

<stevelee> 3) web pages - usually no guarentee of a process

<stevelee> MC That's up to us (and WAI site is tightly controlled)

<stevelee> MS there will be 2 way interactions - with COGA and Editor/EO reviewing each others work

<LisaSeemanKestenbaum> if anyone wants webex let us know!!

<inserted> scribe: stevelee

https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Main_Page#What_documents_do_we_have.3F

:LS we could potential double up - eg design guide is a Note but with interactive Web 'facade'

JK: Are standards and guidelines the same? eg WCAG

MK: W3C are a standards organisation and creates standards like WCGA, But WCAG is a standard that guides developers so is called a Guideline

<LisaSeemanKestenbaum> https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/PlanningPage

LSK: we mist feel in these 2 days to be open to changing formats and content
... Gap Analysis is focus of current work - needs work

EA: "Terms" or "Glossary"? Both are used which is confusing

LSK: on agenda later

LS for GA on extra adding "popups" for terms

MC: probably depends on format - could be done in web but almost certainly not as TR note.

LS Some GA changes are "wish list"

LSK also working on moving Design Guide (DG) items to our template for next publication

https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/PlanningPage#Timelines

LSK: summary of timeslines

MC: we should be prioratising based on how it help COGA obsjectives

JS: Video and Audio are great examples of how a11y required more than just captions so published the requirements which then informed the updated normative items in WCAG
... so GAP Analysis is critical - must have cast iron use case

MC: WCAG use to discuss so we should pick items that GA suggess are high priority

AJ: There is a ballance between need and what is achievable

MC: for more success in WCAG SC we need better GA plus need to join in the process more
... aiming to be in WCAG/Silver has weight so DG not seen as a replacement for WCAG

LS: TF devalued WCAG and decided to concentrate on DG

MC: as a TG of the WG we should be working towards WCAG/Silver
... TFs need to do the work so deliver more than just Use Cases to WCAG
... WCAG Chairs are collecting data and want to ensure wide representation including COGA - so far just data gathering and not selecting

LSK: we though secondary item WCGA SCs, WAI Website, silver

JK GA should be a prority

JS: And also next version and eventual notes

JK - content quality in design guide is important - so cna be linked by high profile articles like Smashing Mag

SK: design guide is important

MC - WCAG is supported by law and policy - COGA would probably me more like a guide

Jennie: we need the SCs for legal enforcement

LS: worries that has experienced it's such a fight to get SC applied consistently on same site

JD Minnesota say NOTE would not be successful as it's hard to get SCs followed - DG required someone to sue

SCs are part of state legislation

JS WCAG guide produced as q?

LS Usable, design & Gap analysis are current priorites as per wiki planning page

we can change that over these days

<Zakim> MichaelC, you wanted to say frustration with process not reason to engage with process and to say different people have different roles, could have focus from different place on SC

MC if the WCAG SC process is not working we should not drop out

the coga resources are better now

W3C will not put on a note that it's legal enforcable

<LisaSeemanKestenbaum> https://docs.google.com/document/d/18TJ8JAC0u0Fa64MnONOA2Cs8MBTcJQxfnFDqK6KVxD0/edit#

<Jennie> scribe: Jennie

Tasks were added to the document, so that as tasks get thought about, they can be added to the list, and assigned at a later time.

Item added: Find subgroup who can work on/with WCAG, chairing older and newbees (Rachael)

<LisaSeemanKestenbaum> https://docs.google.com/document/d/1poEoQjuWdAfWM3aOGPCwJRx7EvBsAtQ_99sGyS9Jlgc/edit

Terms document: name changed to glossary by consensus of group

Lisa: 2 problems to be solved:
... 1 - different meanings used by different people
... 2 - sometimes need a quick and easy definition
... goal - consistency in COGA documents, and make links to the glossary from terms people may not know
... e.g. working memory - aka short term memory
... 2 tasks. 1: collect these terms. As you find them, please add them! (Hint: Steve)
... 2: draft a definition. It is ok if you add a term, but do not draft a definition.

EA: are there rules for standardizing the glossary?

Michael: not much in rules for glossaries, but follow best practices.
... there may be some documentation, but not sure that we need to follow this unless we are submitting things for WCAG
... suggest not following the WCAG process for this

EA: can we have a link?

Michael: I will try to find one. But, I'm not suggesting following W3C practice.

Abi: We are not just looking for a glossary of terms? Different diagnoses and labels that are used in different countries, but we need to include the impact of how this impacts a person with a cognitive disability

Michael: we may want a glossary term with a precise, short definition. But then, we can link to more information.
... could it be a section in a document called "important concepts."

<Zakim> MichaelC, you wanted to suggest picking a ¨canonical term¨ and for alternative terms, put them in the glossary with a definition of ¨see <canonical term>¨

EA: concern - this requires a lot of jumping

Michael: if we could do this with tooling, would this work?

Lisa: pick one term e.g. Learning disability, then either have the other terms used referenced by a slash, or also known as...

Michael: if this was done I would want it linked by other words

Abi: the problem is learning disabilities means different things in different places

Lisa: this is why we have used the term "cognitive disabilities"

Janina: is there a place in a major COGA document that says this?

Discussion about the language continued

Michael: table of terms and jurisdictions, and then decide how to present them?

Abi: propose categorizing using functional difficulties, and then list disability names that may be used by the various people coming to the documents

Lisa: propose: term, other terms people may use, brief/understandable definition, then a link to go to more detail

Michael: it is possible and recommended to have this type of information included in documents we publish

Lisa: can the glossary be evolveable?

Jamie: Autism Spectrum Condition is the way a lot of groups are moving
... the WHO has accepted this.
... there is a final step - the translation piece may still bump this out.

John Rochford: person first language is important in the United States

Discussion about specific groups of individuals with disabilities and their preferences for being identified as having a disability/terminology

<Zakim> MichaelC, you wanted to say evolvability of glossary depends on what doc it´s published in and to say we should consider tooling to address some of the challenges with glossary

Michael: some tooling can help with this. This can help tie some of these things together. Let's think about what we want, and then I, Steve, Roy can work on the behind the scenes part.

Lisa: collect terms at the top.
... we need an introduction discussing that different locations, changing terms, people do not all have the same background. Explain the term coga :)

Jamie: could we add the things it connects to - e.g. other terms (map dementia into memory)

Group discussed starting with functional issues, and then listing the terms.

John Rochford: effort by AT&T and another company that produced a manual. If you only had 10 minutes to read about accessibility, here's some information. And similar for those with an hour, and longer time periods.

Jamie: we have a lot of this at the BBC. We call them Accessibility Actions. We have videos for this as well. E.g. how to eat an elephant in 3 bites - shows some basic accessibility principles in a short easy to understand way.

Lisa: do we want to have a conversation about other things we should be doing?
... if something needs to have more time dedicated to a topic we discuss, then let's schedule more time for that conversation.

Next item: Gap's Analysis

<LisaSeemanKestenbaum> topic gap analisis

gap analisis

<LisaSeemanKestenbaum> https://raw.githack.com/w3c/coga/lisa-working-on-janinas-resucture/gap-analysis/index.html#table-1-authentication-and-safety

<LisaSeemanKestenbaum> See https://raw.githack.com/w3c/coga/making-the-tables-smaller/gap-analysis/index.html#topic-1-authentication-and-safety

Lisa: Topic 1: some of the changes - took out the issue papers, and moved this to Appendix B
... in authentication I added more about the user - the difference for those with a cognitive impairment that shows that it is a barrier.
... I put that the design guide covers more. I also took out of the table "operating systems
... instead of one table, it is now several smaller tables.
... are we happy with this restructuring?
... we also have to identify that we got all the gaps.

Jamie: who is the intended audience of this document?

Lisa: People like WCAG, or the personalization working group, or the security working group.

Janina: I think this needs to be use cases and road map. I think it is a terrific improvement. If we can restructure the 61 screens down to 13. I think we are still missing, need to make the case better who needs the information and what is the barrier.
... e.g. for authentication the "safety" - articulate why it is worse for those with cognitive disabilities. For example, just the issue of safety could be interpreted to apply to everyone.
... authentication, tell why last pass and other password options - be specific of why these are not enough.

Reviewed 3.1 Topic 1: Authentication and Safety as a group

Janina: this improvement is definitely better!

Lisa: once we get this section write, we can copy this process to the other sections.

Janina: we need to talk about what is being done around the world - do the solutions available meet the needs or not?

Jamie: do we need to cover the problem, the solutions?

Janina: probably by way of listing out what are the requirements to meet the need.

Group reviewed further the user stories and the techniques table.

Janina: it sounds like it is heading in the right direction.

Michael and Janina to review 3.1 tonight. And then come back with feedback tomorrow.

Group reviewed the user stories.

Jamie shared an example: when I have to take a number off of one device to add into another device, when one presentation has a space, and the other doesn't use the space, it always takes me a few tries to remember that this is the case.

Lisa: having Janina and Michael look at section 3.1 as a prototype, and will discuss what they find tomorrow.

Janina: we also need to fix the language.

John Rochford: this is what I said I would help Steve with, once we are at that stage.

Lisa: does the design guide address all the user stories? We need to check our work.
... we may be able to delete the historical information? If it is in the design guide, this may be possible.

Jamie: what is the difference between a solution and a technique?

Lisa: that kind of technique is normally an authoring technique.
... solutions might be an approach.
... should we take out the user needs table, and just have a link to the Design Guide

Glenda: for those of us working on writing pieces of this - it is nice to dig back into the history, but it is probably confusing to people just trying to learn it.

Lisa: let's move the techniques tables to an appendix, the solutions into a design guide.

EA: how about links to the design guide included in the document.

Lisa: yes

Glenda: for those beginning into the topic can start with the design guide, but if ready for more they have an option to drill down.

Jamie: at the BBC we have a process where we observe barriers, ensure we have captured all the gaps, then develop the techniques. This is included in the BBC mobile accessibility guide.

Abi: is there any link to show where there may be existing success criteria that partially reference them already?
... e.g. partially address by x, y, z

Glenda: I had done something similar to this in the past - I will find this.

<LisaSeemanKestenbaum> https://docs.google.com/document/d/18TJ8JAC0u0Fa64MnONOA2Cs8MBTcJQxfnFDqK6KVxD0/edit#

Lisa: we want to remove the authoring techniques table - adding these into the tasks.
... added into tasks: check user needs are met in the design guide and what is missing
... added into tasks: do we have all the use cases?
... both in the design guide, and adding our new knowledge.

Glenda: I have a suggestion: the Design Guide - a minimum viable product. I know we won't have covered everything because we will miss things. Rather than expanding to what we have missing, just work on what we already have, and state that there are other things still missing.

Lisa: agreed. Partially met by WCAG (editors note to add)

Glenda: I think this will help create engagement.

Jamie: would a document outline be helpful with everything we can think of. We indicate what we are working on; and indicate "contributions welcome" - is this allowed?

Lisa: check which user needs we have addressed in the design guide, and then add what is not being worked on - "contributions welcome"
... techniques moved to the appendix, adding an editor's note about items partially met by WCAG, design guide, check user needs are met in the design guide and what is missing, Janina and Michael and Alister to review section 3.1, and do we have all use cases

Janina: we want to connect people to the issues, by having some key user cases that trigger thoughts in people like - I know someone that has that challenge.

Steve's WAI Pages

Steve: rationale: WAI has a nice resource introducing people to accessibility, so having some of the COGA information here would be good. We want the COGA stuff in a primary location.
... this is a mock up.
... it must fit in with the WAI website design. It is responsive.
... we have not decided where all these pages will live, and some may be moved to other parts of the site.
... COGA Resource Plan: a bit of information about the stakeholders, editorial process, detailed design guide, etc.
... some of the information on the page currently is to help this group understand what could go on this page.
... I worked with Eric on this.

John Rochford: it is looking great Steve!

Steve reviewed the pages for the group.

Jamie: I have information I can give you, that may be useful.

Steve: that would be great.

Steve continued reviewing the pages.

Jamie: some of the videos we are making include one about cognitive disabilities, and could be linked up.

Steve continued reviewing the pages.

Group discussed the 2 column layout in the design requirements section.

Lisa: the easy reading summary could go here.

Jamie: for the design guide, we would need one place to commit to a change and have it go to both places.

Abi: I would say web page. You want something succinct you can go to.

Steve: Lisa felt that a document would be more formal.

Neil: I like the webpage, because one of the problems I find keeping up with COGA is keeping up with the information in general. The issue will be maintaining two sources.
... for those that want to contribute occasionally, the website is really helpful because it is clear. The content can change, but I need to know where I am going to go - that needs to stay the same. The navigation needs to stay the same.

Lisa: For the design guide, it can be mined if it has the right tags in it - it might be being read outside of its source document. It is easier to reference a document more efficiently than the web page.
... What is Key Access Resources

Steve and Lisa discussed some of the information that is missing.

Lisa: I suggest changing some vocabulary to find resources.
... we need an easy reading summary.

Steve: most pages have a summary at the top in a box.

Jamie: if I send people to a webpage like this, it will work. If I send them to a WCAG page, it won't help them.

Neil: you want that executive summary called out at the beginning, but then have the full document/full information below.

Lisa: can the group agree that we have an easy read/bulleted summary at the top. At the bottom have a link to the policy, note, etc. This would include the design guide.

Neil: summary, then detail is what I recommend

Lisa: summary, detail, then link to the main document/note is what I propose.

Jamie: will this just repeat content?

Lisa: have the link to the note content that someone may need to refer to for legal reasons.
... per page basis.
... no objections noted.
... the group will break for lunch.

<LisaSeemanKestenbaum> topic. useble doc

<Glenda> scribe: Glenda

<LisaSeemanKestenbaum> https://docs.google.com/document/d/18TJ8JAC0u0Fa64MnONOA2Cs8MBTcJQxfnFDqK6KVxD0/edit#

<LisaSeemanKestenbaum> https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Meetings/Jan_2019#Tuesday_29_January_2019

<LisaSeemanKestenbaum> https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Main_Page#Planning

<LisaSeemanKestenbaum> https://www.w3.org/TR/coga-usable/

Lisa: This is the Design Guide - advice for how to make content usable. Should be easy to read and understand and do.
... we want all the info in the Design Themes to be in our new template.

Jamie: Can we go through this document and give feedback?

Steve: Design Themes are the organizing principals of the Design Guide.

Jamie: who is this for?

Lisa: This is for content providers. “This” = “Content Usable” published at https://www.w3.org/TR/coga-usable/#design_themes
... section 11 is for policy writers. See https://www.w3.org/TR/coga-usable/#issues_and_considerations

Abi: Can we draw a flow diagram?

<LisaSeemanKestenbaum> https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Main_Page#Planning

Gareth - is this about UX or content design? Those are two very different audiences.

Steve: Design Guide is the “how to” make content for people with cognitive learning disabilities

Lisa: Let’s focus on the Design Guide and take each of these “themes” and rewrite them in our template.

a draft is published here: https://www.w3.org/TR/coga-usable/#issues_and_considerations

And the “work in progress” is here: https://docs.google.com/document/d/1aJE2C0FzzzXgydEp0MNGSdDDvUTTsANViUVvciFK36k/edit#heading=h.jmv8dajhvvom

Abi: I was just reflecting on what Jamie said about the BBC. Barriers > Principals > Guidelines > Techniques

Lisa: We cannot use Principals and we cannot use Guidelines. We cannot use checkpoints. And we cannot use Success Criteria.

Abi: If we can’t use principals we should not use “themes”. Themes means something different to designers.
... We should replace “Themes” with “Concepts”

Lisa: Adding to the “To Do” List. We need consistent terms in the Usable Doc

Gareth - the “themes/concepts” is a mix methodologies, approaches and objectives. Suggest rewording them all to objectives.

Lisa: Let’s go to the Design Guide
... mockup where each Design “theme” is collapsable
... Look at the structure of Theme 1: Help Users

Design Patterns, or Design Methods, or Design Items

Gareth: Use words that UX language accepts.

Lisa: Consider replacing Design Item with Design Pattern

Document: Design Guide https://w3c.github.io/coga/design/

Design Theme/Objective (example) = Theme 1: Help Users https://w3c.github.io/coga/design/#theme1

H2 User Testing

H2 Example User Stories

H2 Design Patterns / (Items)

2.3.1 Pattern: Make the purpose of your page clear https://w3c.github.io/coga/design/#make-the-purpose-of-your-page-clear

2.3.1.1 How it helps

2.3.1.2 Applying this Pattern

2.3.1.3 Examples

2.3.1.4 Technical Resources and History

EA: concerned about “Look at the most common 1500 words or phrases.” on 4.2.1 Use clear words https://w3c.github.io/coga/design/#use-clear-words

Gareth: Can we have a plain language review after there is a draft?

Yes! We have Mr. Plain Language - John Rochford

<LisaSeemanKestenbaum> https://docs.google.com/document/d/1aJE2C0FzzzXgydEp0MNGSdDDvUTTsANViUVvciFK36k/edit#heading=h.dgd1m22rf

<stevelee__> What the Design Guide might look now like - https://w3c.github.io/wai-coga/coga-draft/guide

Lisa: For now, we will do 1 design guide as a big group today. And tomorrow we can break up into small groups and do one in each group.

<LisaSeemanKestenbaum> https://w3c.github.io/coga/design/#use-clear-images

https://w3c.github.io/coga/design/#use-clear-images

Working on Design Pattern

https://docs.google.com/document/d/1aJE2C0FzzzXgydEp0MNGSdDDvUTTsANViUVvciFK36k/edit#heading=h.dgd1m22rf

Working on “Use symbols that help the user” as a group

Jamie: could “clear” mean “user understandable image with a single meaning”
... At the BBC we would say how the informaiton needs to be available to different types of people.

https://www.bbc.co.uk/gel/

<stevelee__> https://github.com/w3c/wcag21/issues?utf8=%E2%9C%93&q=is%3Aissue+COGA+

Jamie: sharing BBC Mobile accessibility guidelines https://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile
... wanting to look in to a11y for VR

VR A11Y Research

1st step - build data set of research on barriers in VR

2nd step - see if current design principles encompass all observed barriers

3rd step - develop a method for creating a11y VR

participants needs summary: vision, hearing, cognitive, motor

Jamie: we built a switch controllable VR environment

Lisa: Sharing personalization semantics project - Athena

<LisaSeemanKestenbaum> https://personalization-f08cf.firebaseapp.com/ProfileEditing/ProfileEditingSimpleEdit

Lisa: sharing / demoing personalization extensions on the Athena site and others

<stevelee__> https://www.atbar.org/

<LisaSeemanKestenbaum> https://www.easyreading.eu/

<LisaSeemanKestenbaum> funded by the eu commision

<LisaSeemanKestenbaum> The project was funded by the European Union’s Horizon 2020 research and innovation programme and started in 2018.

<LisaSeemanKestenbaum> https://rawgit.com/orish88/AUI_Personalization/master/html/Athena-TestSite/Accessibility%202.0%20at%20Athena%20ICT.html4

John R - talking about the sign language added to their videos https://masscans.ehs.state.ma.us/QuizzesDemo.aspx?id=76

Jamie: BBC will have a toggle for sign language.

JohnR - request from people to be able to place the signer

Janina: Are you synchronizing the captioin and the sign language

JohnR: https://disabilityinfo.org been doing a lot of experimentation what we can do to make this site accessible for people with cognitive disabilities.
... Have video to show you how to do a search (the key action on the site)

Search for doctors and see results (note the addition of symbols)

Click on “specialties” and notice the common language words…. Heart Doctor (Cardiologist) 7

JohnR: people with some intellectual disabilities understand text better when it is bigger

<LisaSeemanKestenbaum> Also http://www.smart4md.eu/

JohnR: https://massreallives.org helps people in Mass with Intellectual Disabilites understand what programs are available to their area.

<LisaSeemanKestenbaum> Smart$MD (sponcered by the commision horizon 2020)

Abi: Bigger text - some work done by researchers in London on nav on websites (with learning disability) - comparing horizontal to vertical nav structures.

Jamie: I do the same thing (text size). When I make the text I want bigger (it pushes all the other stuff out of the way).

EA: That goes back to our proposed Success Criteria (to create white space around blocks of text)

<LisaSeemanKestenbaum> humans guide

Jamie: We have https://www.euansguide.com reminded me of what JohnR was showing

Lisa: see this project about “empowering people with mild dementia” http://www.smart4md.eu
... Agenda for tomorrow - split into groups and work on the parts of the design guide.
... Also look at the Usable doc (structure)
... Review for overlaps and redundancy
... WCAG 2.2 and Silver

<stevelee__> https://raw.githack.com/w3c/coga/making-the-tables-smaller/gap-analysis/index.html#topic-1-authentication-and-safety

Janina: why is “Authentication and Safety” one topic?

Lisa: Let’s focus on “do we like the template”? right now

COGA FtF Day 1

28 Jan 2019

Attendees

Contents

introductions

gap analisis

Steve's WAI Pages

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output