See also: IRC log
<trackbot> Date: 11 November 2013
<MarkS> http://www.w3.org/WAI/PF/meetings/tp2013
<MichaelC> meeting: PF FtF Day 1
<cyns> can someone put in a link to the work statement?
<Ryladog> The work statement is at http://www.w3.org/WAI/PF/cognitive
<MichaelC> no, it´s at http://www.w3.org/WAI/PF/cognitive-a11y-tf/work-statement
<cyns> scribe nick cyns
<MichaelC> scribe: cyns
scope: we have a work statement
<LisaSeeman> http://www.w3.org/WAI/PF/cognitive-a11y-tf/work-statement#!
LS: our initial mandate is about analysis, roadmap.
... we are able to make some techniques.
... roadmap may recommend guidelines, or it may recommend updates to other people's guidelines
... What's new abou tthis task force is that its focus is on cognitive. About how ot make people with all differen cognitive disabilities have a good experience and have websites accessible to them.
... it's a broad field, there are many different cognitive disabilieits with different solutiosn
... the way WCAG and other guidelines are written may be part of hte gap anlysis. Many congiitve guidelines in wcag are advisory. There may be ways to structure advisory guidleiens differently so that people can tell which are more improtant
... we also want to look at the future of what could be. We need to dream big about what could be and come up with big ideas.
... want to hear what people are bringign to the group.
... also want to scope out what our first deliverable will look like, the gap analysis
<AWK_> Zakim AWK_ is AWK
LS: first topic, MC with tool overviews
<MichaelC> Cognitive A11Y TF home page
<MichaelC> mailing list: public-cognitive-a11y-tf@w3.org
<MichaelC> Mailing list archives
<MichaelC> Wiki
<MichaelC> Tracker
<MichaelC> WBS
<LisaSeeman> https://docs.google.com/a/deque.com/document/d/1_OrQ5owq6357pY99_ze-fyAVm9xO7kBRhw6keiHjzt4/edit#
<LisaSeeman> will move it to wiki asap
LS: start by making a table of contents for gap analysis
... 3 sections. section 1 is intro. section 2 is background research. seciton 3 is gap analysis, section 4 is suggestions for roadmap.
... roadmap is our next deliverable. This doc will let us put in lots of ideas about what should be in the roadmap. brainstorming, not necessarily concensus in this doc. real roadmap will be more conclusions.
... Seciton 1, Scope, how this doc will be used, assumptions. assumptions about where we are limiting ourselves and not limiting ourselves. we want as few limits as possible to come up with ideas, we don't have to worry about people turning it into law
... assumptions might include that people are not going to turn this doc into legislation
... section 2 is background research. this is the meat of hte doc. review of wcag, other w3c standards like voiceml , multi-modal interaction, where usecases are being handled in existing specs. how well is it doing the job that it's meant to be doing, etc.
CS: non-standards?
LS: added level 2 items: products and technologies, and pure research on cognition
CS: learning disabilities?
LS: cognitive includes LD, aging as well as more severe issues
... adopton of items relevent to current standards, becuase many are currently advisory in WCAG
... some of them may have a higher impact than others
... so that people who want to be fully accessible know what needs to be done
CS: we should also look at some WCAG things that were not testable 5-8 years ago when WCAG was written, and see if technology has advanced since then so that they are now testable
<shadi> s/curetnnly/currently
CS: another thing to look at is whether there are new techniques based on new technologies
... there is so much more technology now around heruristic technology than there was 5-8 years ago
JW: developing profiles that allow users to define their needs and preferences, that allows providing users interface modifications only for users who need them.
... that allows you to use some techniques that are good for some groups and problematic for others
LS: project fluid is a learning platform that allows content to be phased in and phased out based on prferences
JW: IMS standards
<AWK_> IMS Standards: http://www.imsglobal.org/specifications.html
CS: a lot of the research we are looking for may be in the education field rather than cognitive science
<AWK_> Fluid: http://wiki.fluidproject.org/display/fluid/Fluid+Project+Wiki
<scribe> ACTION: LisaSeeman to add link to FLUID project to minutes [recorded in http://www.w3.org/2013/11/11-pf-minutes#action01]
<trackbot> Error finding 'LisaSeeman'. You can review and register nicknames at <https://www.w3.org/WAI/PF/Group/track/users>.
<shadi> http://www.w3.org/WAI/rdsymposia
<shadi> http://www.w3.org/WAI/older-users/developing
<shadi> http://www.w3.org/WAI/intro/people-use-web/diversity#cognitive
shadi: this could be a starting point for use cases
... might be good to look at use cases
firs
CS; we need to define what we mean by use cases. do we also want to define user scenrios, personnas, blah blah blah
LS: Heidi, do you have research ideas you'd like to share? for example, research on how people with Downs Syndrome use computers
HF: research on users age 15-30 with Downs Syndrome.
<AWK_> s/Fluid: http://wiki.fluidproject.org/display/fluid/Fluid+Project+Wiki/Fluid: http://wiki.fluidproject.org/display/fluid/Fluid+Project+Wiki (not sure if this is the right project)
HF: 4x4x4 structure vs. 16x16 structure
... also studied how people with Downs Syndrome use search engines online. they like to use search, but it takes longer, and they have a hard time identifying the right link when there are 200 on a page
... pages arranged in a 2 level structure with 16 links on the first page. in the other version there are 4 links on the home page, and then another page with 4 links, before getting to the content.
... 3 level design worked better than a 2 level design. we thought before that a shallower structure worked better for people with cognitve disabilities.
LS: people with downs syndrome, not all cognitive disabilieis
CS: for example, it might not be better for people with ADD
HF: not published yet.
... I have related work on accessing the internet using touch devices. Would touch devices be better for people with Downs Syndrome.
... they had problems with touch keyboards, scrolling, difference between display on larger and smaller device
... that study is published and will send a copy
... major challenge is the diversity of cognitive disabilities. for example, there is a huge difference between people with downs syndrome and autism
LS: there are some techniques around adaptive technology
... one of the nice things about w3c is that semantic markup allows user agent to control user experience based on what it knows about the user and the content
<MichaelC> ACTION: Lisa to add link to FLUID project to minutes [recorded in http://www.w3.org/2013/11/11-pf-minutes#action02]
<trackbot> Created ACTION-1304 - Add link to fluid project to minutes [on Lisa Seeman - due 2013-11-18].
LS: for exmaple, the shallow content vs. deep content could be based on what the user needs, in the same way that you have a mobile experience and a laptop experience.
<MarkS> scribe: MarkS
CM: Executive Function: How we think about how to get from point a to point be, to complete a task. RE: find specific information on the web...
... how do I complete that. completing a search.
... is there a way we can help people understand these steps
LS: so this is a topic we should look into and apply to cognitive accessibility
... I think this fits nicely in our TOC, under Pure research
CM: in website testing, to make sure a website is usable, common to ask people to complete a certain task. We should be asking how that affects someone with a cognitive disability.
CS: Reading is important to pure research.
... dyslexia, disgraphia
LS: Cognition in general belongs there
CM: also people with temporary conditions that are affected by high cognitive load.
LS: perhaps this is a new section of TOC
... business dynamics, new business
CS: as we make UIs more friendly for everyone, I wonder if they are becoming less interesting to those who have a long history with computers, who maybe like the command line
LS: we need Business Cases as a topic
CS: and Social aspect of it as well.
... like those on autism spectrum that don't want it to be thought of as a disability
LS: we design for the 80%
... legislation bases guidelines. we have to be careful that things we write don't get turned into legislation that affect services and funding
... when we get to roadmap, we need technology as risks
CS: the case for metadata and markup clues
<richardschwerdtfeger> I'm baaackk
CS: pictographic registers at fast food restaurants
... helps employees who may not be literate
... language learners
LS: cross cultural learners
DD: Language disorders, under pure research.
... aphasia
... stroke can result in a number of disorders
... the research is on language, the use cases are dyslexia, aphasia, etc
CS: I think stroke/brain injury goes under Pure research
... education theory, special ed, whole language theory vs phonics, etc.
DD: parallel to exec function, short term memory. working memory.
CS: ADD, Autism
LS: how about a list of different functionings
... cross-overs
... different types of memory and cognition. I think they have been mapped out under research
CS: potential work item, taking research categories of different cognitive impairments and creating personae out of them
... who is the user we really want to do a good job for.
DD: lets say there are X number of people with age related cognitive issues
CS: or kids
LS: I think about prioritizing by severity
CS: from a business perspective, you want to target the biggest group.
LS: we're going to have to define some priorities.
... you might have a less marketable group that has a bigger impact, lower quality of life.
... if we pick hugely diverse cases and design with that in mind. we may find that we can also cover those who fall in-between.
DD: can we do something about prioritizing? priorities on one access severity on the other.
CS: people who are gifted but on autism spectrum
AWK: should consider feasibility on that graph as well
CS: there are things that are simple that have a high impact as well...
AWK: when I start to think about product development, these are the things we can do, there are things we already have, there can be a opportunities to add features to widely used products that help corner cases.
... under suggestions for products, a layer that has to happen at some point, clearly defined use cases, mock-ups developers glaze over, but if you demonstrate to them the issue it can easier for others to understand the benefit
LS: we will never have a final version of this document because there will always be more research
<AWK> s/Fluid: http://wiki.fluidproject.org/display/fluid/Fluid+Project+Wiki/Fluid: http://wiki.fluidproject.org/display/fluid/Fluid+Project+Wiki (not sure if this is the right project)/
LS: TOC -> What we need to do.
CS: this really lends itself to a modularized approach.
DD: you can break out the research as a document as well. a horizontal approach.
CS: one of the good things about modularization is that you can stabilize work on something and move on to a different topic.
LS: need to be very careful with URI's and make sure they are persistent.
... for referencing
... we also have to be mindful of scheduling, to actually produce something by a deadline.
CS: a lot of these can be thought of as techniques.
LS: need to think about who we have and what we need. identify holes in the TF
CS: we don't have anyone with experience in educational theory
CM: there are classifications in the DSM we can build off of. Turn into personas/user stories
LS: we can start off with existing personas, define use cases/scenarios etc. then move on from the existing research.
CS: one of the nice things about tag systems is the ability to create alternative UIs
LS: we want to be as inclusive in this TF without limiting our work.
CS: lots of people working in Software Dev that are not Neuro-typcial
LS: Summary:
... this work is ongoing
... never have a gap analysis of all the latest research
... modularized approach to this. some sections are stable, some are evolving
CS: what I assume we are going to produce is a Note and a bunch of techniques.
JB: the expected deliverable would be a WG Note. Series of working drafts that will evolve to a Note. must be clear what this is on track to be. would confuse people to lead people to think these are guidelines
... my understanding is that part of what you are going to do is to figure out what your deliverables will be.
... if the majority of the work came out as WCAG techniques, it could be integrated with existing structure, which would make it easier for people to find and use.
<richardschwerdtfeger> wcag techniques don't cover this
MC: when we talk about WCAG 2.0 techniques now, they need to map to SC. A different output is gap analysis that identifies missing SC.
LS: summary (cont'd)
... making a draft table of gap analysis (1st deliverable)
... two important points, we want to have on the TF, people with different cognitive disabilities, but not limit what we want to achieve
... the other is we realize that the gap analysis will never be finished. never have complete analysis of something that will always be changing.
... stable vs modularized documents.
JB: curious about business case and dynamics section. do you feel a need to justify a need for guidance? should we have joint discussion with EOWG? The general WAI materials are sufficiently clear.... or something like that.
... we don't want to have a discoverability issue.
CS: RE: Modularization, if you pick a kind of cognitive disability that we have expertise in, do the gap analysis, existing research, WCAG, business tie-ins, then use that as "brain-juice" for techniques.
RS: what are we going to wCAG right away with this?
ach richardschwerdtfeger
scribe: i think we are putting the cart before the horse here.
LS: what we are talking about now is a TOC for the gap analysis, which is before the roadmap
... recommendations can include additional EWOG documents, etc.
... the gap analysis is a place where we are not limiting people. not a standards document at all.
<janina_> Lunch Alert -- We need to close this portion soon to stay on schedule
<richardschwerdtfeger> rich: yes collect info
JB: in no way is this group constrained to adding to WCAG techniques. but I would expect that some of the work of this group would end up as WCAG techniques.
... if we were to look at cognitive a11y TF work as an opportunity to just focus on expertise in the group, we would be missing out. We need to bring expertise in that we are missing (based on gap analysis)
JS: need to stay on schedule because we will be meeting with IndieUI again at 1:30.
there is a kickoff event at 3:00 that judy would like us to participate in.
CM: a question about what our product should be. IS there any precedent for WG around certain disabilities?
JB: what we did was caucuses, in the early days of WAI for rapid input into SMIL
... we had no one from deaf organizations, so I convened a caucus of reps from those communities. we did similar things around media requirements, but not WG
... which would not be very productive. what we need is a TF of multiple WG, like we have here.
LS: Lunchtime. we can convene at 1:30 50 minutes from now.
<Ryladog_> slow down your speech James please
<scribe> scribe: MarkS
LS: defining personas, use cases, user stories (these will be stable documents)
... Personas should include description, their challenges, how they would use the web, how content can be optimized, existing research and guidelines.
... if someone is doing the module on dyslexia, you want to reference particular guidelines.
... each user group will have a module that contains this templates information
... Persona is general, brief. Scenario is detailed
... we're looking at gap analysis document, section 2. Research section, external to standards.
... a document that defines the terms and overview of the process
... the bulk of work will be defining user group research modules
... much more detail of information common to the user group
... description, cognitive function, challenges, user stories, how they use the web,
... characteristics, extent to which needs are currently met, potentials, possibilities, references
CS: re: current needs that are being met. Where does assistive technology fit into that.
... read, write gold. maybe some of that stuff would be useful in web content.
LS: we have the user group material, but hey we have the technology review module
... can be referenced
CS: maybe we want to talk about the technologies in the context of the specific user group
LS: In the user group module, we want to reference the technologies module and how they may use it differently than another that uses the same tech
<katherinemancuso> ((Mark: who is CS? I'm not sure of the names of all the people in the physical room. Thanks!))
CS: lots of examples of mainstream technology that has benefit for persons with certain cognitive disabilities like syncing between epub and audible books
<katherinemancuso> Thank you!
<katherinemancuso> ((thank you, Michael & Mark!!))
LS: what about mood disorders?
[discussion]
CS: should we list various mood disorders and people can elect to take them up?
AWK: what you'll end up with is a list, some will get done if an tf member has a particular interest. others will get dropped.
CM: mood disorders don't include psychosis and some of these other things.
... PTSD would not be a mood disorder according to DSM
LS: is PTSD a cognitive disorder?
KHS: we are working off of definition from WHO
... we have to state where we are taking our definitions from
MC: is their a line between cognitive and psychiatric?
<cyns> http://en.wikipedia.org/wiki/Cognitive_disorder
<cyns> learning disability: http://en.wikipedia.org/wiki/Learning_disability
<katherinemancuso> ((jcraig - glad to hear that I'm not the only one having challenges with that - i thought it was my own auditory processing problem when actually it's a general problem other people are having.))
JS: we should have a scoping section
<cyns> learning disability: http://en.wikipedia.org/wiki/Learning_disability
MC: propose we switch to action items
... this is the current consensus of who is in the room right now. can come back to this once we get more people involved.
... focus on functional impairments, not cause
JW: approach I would consider helpful, is to find out the categories that people who do research in this field use.
... if there are conflicts and contentions in that field, we can either take sides or neutralize them