W3C

- DRAFT -

Accessibility Education and Outreach Working Group (EOWG) Teleconference

21 Aug 2020

Attendees

Present
Brent, Mark, Daniel, Shawn, Howard, Laura, Vicki, Kevin, Sharron, KrisAnne
Regrets
Estella, @@
Chair
Brent
Scribe
Sharron

Contents


<shawn> presnet+ Vicki

COGA - Making Content Usable

Brent: Vicki has started to go through results of the survey. We'll talk about common themes and get a document to provide recommendations. Will provide feedback in a narrative document (unless COGA strongly prefers GitHUb)

Sharron: Clarity about our goals

Brent: As you know, survey data often conflicts. One of the goals will be to resolve those conflicts sso we have one coherant set of recommendations.
... not to give them 15 different opinions but a unified voice from EO

Purpose of document

Brent: Several people asked what is the purpose, who is the audience, etc. We have asked them for a requirements document so that we can understand that. It is a foundational question that will impact all the other topics. For now, we can ask ourselves what we assume it is and how the doc sould be used.
... Vicki brought these questions. So first of all, does our group feel the purpose is clear?

Kevin: They have a purpose statement but not sure that they actually keep to that point of giving advice to content creators and devleopers. So while they state a purpose, they don't necessarily focus on that purpose.

Vicki: I agree, there is so very long, one gets lost in it. There are sections on the WAI site that some parts could be moved. But to fulfill a specifc task in a reasonable time would be very difficult in this document due to length and complexity.

<shawn> [ Shawn clarifies that there are several things in WCAG that address cognitive and learning disabilities. Just that there some things that do not fit in WCAG. ]

Laura: When I first reviewed it, I was very impressed. It is long but there is great information and it' great to have in one place. I am a team lead and it has something for all the people on my team. There is info here for all roles and I appreciate that there is information for all of them. It does not feel strong enough to have a high level document with pointers elsewhere. I like that there

is so much in one place.

Laura: I would like to get feedback from the team, especially the design and UX team. So much falls onto the develpers and this addresses the need to distribute.

<krisannekinney> agree with that Laura!

Laura: in my career, cognitive issues have been overlooked. They compete with other disabilities especially screen readers and so having this strengthens the understandng that accessibility is braod.
... I know it is long and I am open to structural changes.

Kevin: Tht is one of the biggest challenges. Many people could benefit from parts of this but very few people - maybe no one - needs all of it. It needs to be re-organized, there is a bit of work to do to meet the goal of helping people make content more usable.

<shawn> Sharron: A little ironic that it's overwhelming. Agree that people will struggle with finding the infmation that is relevant to their work.

Kevin: if this document is truly for people who make web content, why are those roles not called out more directly. There seems to be little that directly talks to the different disciplins.

<shawn> +1 to Vicki that there is so much information even in one section, that it's hard to find the info on what to do about it.

Vicki: Need to suggest that they include pointers specific to the different roles. Even in trying to find the solutions to the problems that are posed is difficult. Sectons for different roles wouold be useful and important to provide.

Howard: If there was a separate document similar to the Easy Checks, something that did high level overview. Also it needs examples rather than just explanatory text.

<shawn> [ example of examples https://www.w3.org/WAI/tips/designing/#dont-use-color-alone-to-convey-information]

KrisAnne: Agree that cognitive issues are often overlooked, there is actually resistance to recongnizing for example the cognitive decline of aging. I too am overwhelmed by it but I love all of it. There is so much useful information that is not commonly called out.
... As I read the user stories, I think of the students that I taught in the past and how useful these approaches would have been to me. I feel it has to be structually changed, it is overwhleming as is, but it is comprehensive and all teh info is so useful.
... I think it is actually about making content more usable for everyone. I have shared it widely at work, with the whole UX team. I am OK with breaking it up but don't want to lose any of this related information. I was sad the info was in appedices.
... the issues of older users is in the last appendix and seems more important than that, I think about my mom,intelligent and active but often lost on web sites.

Sharron: Intereseted in the reactions from the people you passed it to.

Laura: I am on a team for a governemtn agency. Our team is understaffed and tends to only do what we absolutely must. I am juggling 5 projects and seem always to be asking for help. I do this because I care about it but not sure if others on my team will care, especially if it is presented as best practice rather than requirements.

Brent: In talking to collgues at Pearson, they said yes it is long but please do not break it into separate pieces that we have to go find. Great to have in one place.
... I am thinking about at least a document with side navigation.
... is that something we could recommend, or is this outside our scope?
... and the section at the bottom was the Appendix A section that is well structured, easy to consume, and it was suggested that it could be more prominent.
... something must guide people to the sections relative to thier role to make it truly usable.

<Zakim> shawn, you wanted to ask about awareness and this document and "shove in the faces" and to note e-mail and to say How people with disabilities use the web videos

Shawn: Got an email saying I can't find anything on the WAI site, language is not simple, navigation is not clear. So while I whole heartedly agree that we need to make people more aware of cognitive issues and embrace them, I am concerned that this document will almost certainly turn people away. Maybe we can think of outreach and what else we can do.
... Yes, there is discussion already about making the design guide more prominent. I think it may be published as TR and we will then have another version later.
... TR is technical report

Brent: If we recommend to put into a structure that can provide side nav for, etc
... can we do that?

Shawn: Yes

<Vicki> +1 shawn about simplifying content

KrisAnne: It is interesting that we talk about simplying content for cognitive issues with a massively complex document. It is wonderful content that needs to be presented in a more usable format to understand and utilize it.
... and it is good for everyone and for documents of all kinds
... but I do not want to lose any of this great information.
... it is a great way to help people understand the experinces of people with cognitive issues.

Laura: Is it that we are too far down the road for them to re-organziae this document and find a structure that is specific to roles?

<shawn> Sharron: get everyone to be excited about this document. provide ideas on how to restructure it so everyone loves it

Shawn: We need to clearly communicate how we think the information can be restructured so that it is clear, so that people really use it and appreciate the depth of informaiton here.

<krisannekinney> +1 to kevin

Kevin: I don't think it should be a TR document at all. There is superb information and I love that it has been doen. The people who need this will not find and use it here. It needs to be a suite of docs like How People with Disabilities Use the Web. As a TR document it will be buried.

<Vicki> +1 to Kevin

<brent> +1 to Kevin

Kevin: This is brilliant body of work but there remains much to be done.It is wonderful content that is struggling to break free.

KrisAnne: I agree it will die a terrible death if it is remains in this format.

Kevin: TR is for technical information but this is more of an educational document.

Vicki: Valuable information here is buried and I agree that the Appendix A really has to be moved further up in the document, it is so vlauable. This is so good, and we all agree that this will help people understand cognitive issues. But the next step - how to use it - is much less clear.

Mark: I know from the interactions I have with my team trying to get them to pay attention to accessibility. Imagining handing this to people are my team, I know they would smile, eyes glaze over and they would pass. The sheer size of it.

<Zakim> shawn, you wanted to ask everyone to skim https://www.w3.org/WAI/people-use-web/abilities-barriers/#cognitive

<Vicki> +100 to Shawn's link. This is so clear.

Shawn: Can everyone skim this section, remind ourselves that it is there. An intro with an expand/collapse with details.My own opinion is that it explains issues more clearly than this document. The challenge is getting people here to read it.

<shawn> Sharron: ... organize it like @@ Hope they hear the deep and @@ appreciation. Just want to make it usable

Brent: What I envision then is a part of the WAI site with it's own side nav etc.

Sharron: Like Kevin's comment coparing it to the suite of docs in How People with Disabilities Use the Web

<shawn> Sharron: have in format that when we push people to it, the don't get yucky TR, they get something that's helpful and thopurhghful and helps people find the info that they need

<shawn> [ shawn points KrisAnne and others to https://www.w3.org/WAI/older-users/]

<Zakim> shawn, you wanted to ask what stay together

Kevin: Another similar resource is Older Users, so making the information available within a coherant structure rather than a long unweildy TR document would be most useful to meeting their goals and helping the community understand and act.

Shawn: A question I have is if we re-structure, what stays together and what would be segmented. Steve lee has worked on putting this (at least the design guide section) in the WAI website. So what's in the left nav?

Kevin: The design patterns are vital imo. The personas are important to making it understandable. The user needs are good as well but the rest is more general, educational not as actionable.

Daniel: If we go that route of asking for a specific subsection in the WAI website would we open ourselves to asking for sections for specific disabilities? I think much of this can be put into existing sections like How People with Disabilities use the Web, Business case, etc Can extend the sections that exisit with this info.

Brent: I heard both Laura and KrisAnne and my Pearson collgues strongly say they wanted it all to stay together.

Laura: I think last week when we talked through this, we agreed that it is valuable to have a link to one document that covers all the things your team needs to know. I do however see that it could be restructured to be easier to find specific info relevant to your role.

<Vicki> +1 to splitting the document up into usable portions within sub-sections on WAI web site

Laura: we also spoke about incorporating into existing resources and just providing a link. So linking to for example the business case would be fine as long as these points are maintained within the exisiting doc. We must be willing to change those existing resoruces as well.

<Zakim> shawn, you wanted to EO updating

<dmontalvo> +1 to communicating openness

Shawn: I strongly strongly support that we EO are open and eager to update our resources. We are on the record of asking them to help us update and use some of the videos for those issues. Very open to incorporating as we did with Older users.

<dmontalvo> s/+1 to communicating openness //

<dmontalvo> +1 to Shawn's comment above

Laura: When I look at HPWDUTW and consider creating a similar section for cognitive, I considr as well the Older users section. If we make that recommendation, we will have a lot of work to restructure these two sections as well. Or rethink them in any case. May need to think bigger.

User Stories and personas

Brent: They are separate and Kevin spoke a bit about that - did you have further comment about how they might be used?
... Laura and KrisAnne when you shared the document, what were the sections that really stood out and that you pointed people to?

Laura: The design patterns user stories and Appendix A since it gave people clear ways to link them together and quickly understand the issues

KrisAnne: I sent the UX folks straight to the design guide and the researchers I sent to the persona. But I also feel that the user stories could easily come into play.
... especially for the QA and testers. They are all related and not sure they can effectively be separated. Wonder how they decided on this structure?

Brent: Yes I was confused initially about the difference between use cases and user stories and some seemed like it culd be combined.

KrisAnne: Yes I think it could and sometimes it disturbs the flow of the narrative.

Vicki: For the user stories, that set of information has links to the personas. I also want to open the discussion about the usability testing since it may not be appropriate to inlcude in the document at all.

<Zakim> shawn, you wanted to share link finally and to say very rough concept draft

Shawn: The background on that is that there are existing resources on usability testing and when those were developed, it was detwermined that it was out of scope for us to cover all aspects of usability studies. We focused only on the need to include PWD and high level guidance.

<Zakim> kevin, you wanted to comment on usability testing

Kevin: There is so much detail, disclosures. ethics, and all the complex issues. The best decision is to give high level guidance and pointers. The risks are too high that we would encourage people to do things in the wrong way - we need to steer clear of it.

Brent: What is different about the uability testing section here? Seems like it is the 5.5 sections where they suggest questions.

Shawn: I could see leaving that section since it is tied to the objectve so that part is OK (not sure it is all that useful however)

Brent: Maybe do that for each one - provide guiding questions for all the objectives. I agree with kevin there is already some of that same content in the WAI site in a bit lighter fashion.

Shawn: Does anyone disagree with those points on the usability section?

Brent: Usability is always the part of testing that gets overlooked or left out. Seeing it here, is another reminder that you must include that to ensure you meet the goals. if you remove it, you don't have that reminder.

<Zakim> shawn, you wanted to say here is a *rough* concept draft - https://w3c.github.io/wai-coga/coga-draft/guide/design-notes and to say still mention usability testing and link to

Shawn: Perfectly fine to mention user testing "it's imprtoant and here are links" But there is difference between mentioning and giving what seem like detailed guidance but is actually incomplete and could lead to sub-optilaml outcomes.
... Here is Steve Lee's first pass at a section to go on the WAI site
... interesting it does have the user stories

Brent: Why was this abandoned?

Shawn: It is not abandoned. Some in the COGA TF who really like it and think it is easy to use. Others think the TR has more credibility.

Kevin: I like the way this is being restructured, as an early draft looks good. Some of it may be unecessary, but this is moving toward being a useful resource. Focuses a bit heavily on the objectives rather than the tasks related to each role.
... seems more useful but needs to be more effectively chunked.

<Vicki> +1 to Kevin, key words from Kevin: it is a usable and useful resource. Good job (Steve ?)

<Zakim> shawn, you wanted to say filters like quickref

Shawn: Thinking about getting people right to what they need, like filters.

Kevin: The credibility arguement seems a sideline. What matters is if people findit, understand it, use it. Make sure that it is easy to change habits.

Brent: Thanks everyone for these great comments, we have gotten through everything bulleted. Any other big picture comments? Vicki do you have any questions for us?

Vicki: If there are any other thoughts about this, please be sure I get them soon. I heard one arguement to keep in one long doc and sharpen up the findability. The other is to chunk up and present in a more segmented format.

Shawn: When you see what Steve lee is working on, KrisAnne and laura, does that seem to meet your wish for "all in one?"

KrisAnne: Yes

Shawn: So are we leaning toward a different presentation format?

Kevin: Yes if I am a team leader, I want to be able to provide specific guidance by role. How to change the presentaion to facilate that?

Laura: Don't want to duplicate the content

Work for this Week

<shawn> video survey extended to Monday. (no more extentions planned)

<shawn> please spend at least a little time, even if can't do all

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/08/21 14:30:50 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision of Date 
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/Contnet/Content/
Succeeded: s/workid/worked/
FAILED: s/+1 to communicating openness //
Succeeded: s/consdier/consider/
Succeeded: s/togehter and uickly/together and quickly/
Succeeded: s/pattersm/patterns/
Succeeded: s/task realted/tasks related/
Present: Brent Mark Daniel Shawn Howard Laura Vicki Kevin Sharron KrisAnne
Regrets: Estella @@
No ScribeNick specified.  Guessing ScribeNick: Sharron
Inferring Scribes: Sharron
Found Date: 21 Aug 2020
People with action items: 

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]