Accessibility Education and Outreach Working Group (EOWG) Teleconference

26 Jun 2020


dboudreau, Sharron, shawn, Daniel, Vicki, Helen, Laura, Kevin, Mark, Jenn, Hidde, Bill, Shadi, Brent, Estella, KrisAnne
Andrew, Sylvie, Jenn, Greta
Sharron, Vicki


<Sharron> Scribe: Sharron

ARRM progress/status

Brent: The team has processed feedback from GitHub and recent presentations. There are several open issues for discussion today. Denis will walk us through.

<brent> ARRM Project Page: https://www.w3.org/WAI/EO/wiki/ARRM_Project_-_Accessibility_Roles_and_Responsibilities_Mapping

Denis: Wanted to begin with thanks for all the input. It has been months and there was a lot of feedback. We reviewed and processed all of the comments. Since the May presentation at AccessU have reviewed comments again with a new perspective and to make the changes indicated by the feedback and comments.
... as well we have a new TF member and that has helped with the understanding of new perspectives. With the charter being renewed, we want to have a shared vision for moving it to the next level.

<dboudreau> https://github.com/w3c/wai-roles-responsibilities/issues

Shawn: Who is here today who has not yet seen or been involved in this document?

Denis: Helen, Kevin, have contributed. Daniel may be a bit new to it. Are you suggesting I need to do an overview?

Shawn: I wanted to check but it seems good, thanks Denis

Denis: Compiled all comments and feedback as GitHub issues.We tagged all the people who made the comments but I may not have done that right. If you have not gotten a comment response, let me know. We processed and closed 42 issues. If you are curious, you can review on the GitHub Repo. The one that remain opne are ones we need discussion for.

<brent> ARRM issue #37: https://github.com/w3c/wai-roles-responsibilities/issues/37

Denis: Let's start with issues around voice and tone. There are three of them. Overarching idea was that the tone is too familiar and not as "authoritative" as WAI resources generally are. That was deliberate, we wanted a sense of familiarity, peer discussion rather than feeling that it is an authority dictating to them.
... those comments were from Sharron and others. Jennifer and Sean rewrote a lot of feedback from chairs and staff. So there is a new version for your review. #43 was also to make the document shorter, more concise.
... we tried to make it shorter but still have a difference about the tone.

<shawn> Sharron: Didn't mean strong sense of authority. Approach is good. Informal is better. My feeling it went too far.

<shawn> ... Can become distracting. Also, my biggest push was for making it more concise, shorter. Knowing people hate to read.

Denis: We are so close to the document, if you can help with making it shorter, we welcome that.

<Zakim> shawn, you wanted to say EOWG recent approach

<Vicki_> I'd be glad to help Sharron take a shot at shortening it.

Shawn: Some of the things that we did especially with the redesign, we have shifted tone. For example the Busienss Case. EO is very open to that. Since the redesign, we have made a big push toward tersification. When we did the usability testing, we found that there was a strong preference for short text. In some cases however, like the user story narratives, their tolerance for more information

was high. Maybe take a look at what people really need to know in order to summarize.

scribe: People can have a short summary for those who just want to jump in and go with more narrative for those who need it.

<hdv> ATAG Report Tool: https://atag-report-tool.hdv.now.sh/

scribe: encourage yu to look at the ART for how short the intro text is with expand options for more info.

Denis: Yes, expand/collapse is a an option we are considering.

Vicki: I can take an edit pass as well.

Daniel: I did not read this in depth but when I took a pass for the survey, it was the use of subordinate phrses and things that made it hard for me to read. I don't think the stye or tone is an issue at all. But the complex sentences are difficult, plain language, especially for non-native speakers like me.

Denis: happy for you to point those out. Anything that does not work from an internationalization standpoint, we definetely want to know about it.
... the goal is not to walk you through each issue that was found but more of a higher level review. The 10 issues that remain open - some are a couple of years old. Questions about the intro we are not addressing since this is an internal page only. We do need to update it, but we think we will put it to bed for this charter and create a new version for the next charter.

<dboudreau> https://www.w3.org/WAI/EO/wiki/ARRM_Project_-_Accessibility_Roles_and_Responsibilities_Mapping

<brent> me/ to Shawn, was that your queue question?

Denis: There is a need to revisit the goals and make sure they are aligned. We acknowledged the coments but did not afddress them since they are internal.

<brent> New version of Introduction page: https://www.w3.org/WAI/EO/wiki/ARRM_framework_introduction

Denis: There is a new version of the intro and we could use an edit pass.
... next were issues of reordering items in the decision tree. https://github.com/w3c/wai-roles-responsibilities/issues/47

<brent> Decision Tree page: https://www.w3.org/WAI/EO/wiki/Role-Based_Decision_Tree

Denis: Kris Anne brought up the way that it was made before that UX and visual design were separatd and should be closer together. We agreed but wanted to move it further down in the consdieraton list.
... a lot of this feedback came from Kevin with a rating of low, medium, high. Made it very easy to address and we appreciated that.
... we came to understand that there was a discomfort with business, project maangement were conflated. We wanted to separate business strategy from analysis and managment roles. We have tried to separate analysis from implementation and management. As well to separate QA from development. Tried to be clearer about specific roles and make a catch all for those in procurement, etc.
... so these are longer pages but may be able to avoid "wall of text" with accordians. The page is really just informational to help people work through the decision tree. People often have trouble finding their role in the big picture. So we try to help with very specific defintiitons that fit into the bigger picture.

<shawn> [ Shawn wonders if that part is clear in the Introduction? ]

Denis: meant to help people whose actual title may be different than in the decision tree.
... Kevin also said that the primary role status was separate from the decision tree and we ended up combining them. The feedback has helped us simplify. There is information about front-end developers that we think needs to be said and may need it own page. Wanted to address that consdieration.
... by default, people seem to expect most responsibilities fall into development but we found that nearly 70% of issues we find during assessments come in the design phase.

Bill: The reason for this section is the recurring characteristic that expects the developer to have responsibility for nearly everything. We realized that even though most things go through the developer in one way or another, they often are not decision makers but are impleenting based on design decisions.
... developers were assigned ownership often incorrectly and this document tries to address that.

Denis: The tagging was not done correctly so you may not have gotten these messages on how these were addressed. To let you know now, we paid special attention to "ED-High"

<dboudreau> https://github.com/w3c/wai-roles-responsibilities/issues/47

Denis: We thought we may have a different definition of "primary ownership" In our mind it is not related to product ownership but the responsibility for that aspect of project development. As well there may be a disconnect about functional and nonfunctional requirements.
... in our mind it is more about who is accountable in seeing that the accessibility standard is met. Matrix - accountable, contributing, or informed.
... We tried to be more granular than the product owner with the accessibility features to allocate them into task responsibilities. Wnated to bring this up in case people who are contributing concepts is on the same page about what we mean by ownership.
... we feel that we have reached another layer of maturity and are ready to understand the next step. Should we tersify and then do another review?
... or shall we review now? I have an ongoing discussion with Helen as well about how agile development works within this framework and we have asked her for input.

Helen: Description of the roles is more of how they work within a waterfall process. I can do an example of waterfall vs agile with QA that can illuminate the differences.

Denis: Do you think it will be a discussion of process or roles?

Helen: Probably some of both.

<Helen> +1 to wait until after the updates are done before the next review as work is ongoing

Denis: We can work offline. We did not feel we were emphasizing waterfall so much as linear in describing roles we welcome input on that.

<Jennifer> I too have to drop off at 9:30am EST. But thank you Denis for walking through this and to everyone for their comments ongoing feedback.

Denis: would ask people to look at the GitHub issues, add to them if they spark thoughts. Want to close the issues and complete the resource version within this charter. Then make the next version plan for the next charter period.

Brent: Continue to work through the issues to resolution with whoever submitted. Can aslo ask for review if issues are not specifc.
... may not need to revise the requirements for the new charter period.

Denis: Great, thanks. Stephane and Lewis were contributing through the years and have had to drop. Want to acknowledge their contributions.

Shawn: Will do that in the acknowledgements page (can set it up now)

Sharron: Thanks, great to see the progress.

<shawn> +1 that most will use the default, and only some will build their own

Denis: Creating role based documents and encourage those of you who have those roles to help with that. We have built this in our cocoon and welcome the challenge from people who do these roles and have another perspective.


Shawn: Thanks all of you who got to the review but a couple of active participants were not able to get to the survey due to the short turn around. Wanted to be sure we had your approval.

Kevin: I can just register here that I am happy to publish.

Shawn: OK we wil get that in the survey.

Brent: Big announcement on Monday, celebration is required, thank you Hidde and Shadi for this really good work.

Shawn: And the Charter was approved and announced, it's done!

Brent: With the new charter, our name is officially the Accessibility Education and Outreach WG.

WCAG EM Report Tool

Brent: Shadi will talk to us about the updates coming for that.

<brent> WCAG EM Report Tool: https://www.w3.org/WAI/eval/report-tool/#!/

Shadi: Happy to see the success of the ART and looking at WCAG-EM report tool, we have this tool, originally made by Wilco. We have funding for developers to update it. Of the 72 issues, we have prioritized.

<brent> List of open issues showing prioritization: https://github.com/w3c/wcag-em-report-tool/issues

Shadi: P1 are those do not change any features bur update the code base. Looking for conssitant user experinces. Mostly bugs under the hood. "face-lifting" toward the WAI site design.
... P2 are enhancements that do not really change the current tool. Adding a button or filed but not changing the essential functions.
... P3 are items and requests that add features (eg: a template chooser or creator, etc.)
... those of you who have added feature requests can review to see where your comments have landed. Or if you have not, this is a chance to add to the issues. We will be working through the list.

<brent> Just for information. Number of each type of issue... Priority 1 = 32 issues, Priority 2 = 14 issues, Priority 3 = 25 issues

Shadi: may be work for this week to review but open the floor for comment.

Sharron: How much is the tool used?

<shawn> [ Shawn notes that we have lots of good data on the WAI site overall, since the redesign. ]

<shawn> s/[ Shawn notes that we have lots of good data on the WAI site overall, since the redesign. ] / /

Shadi: We know that it is quite widely used by governments and government agencies. Companies have reported and taken the source code to make internal versions.

<eoncins> Agree with Shadi that in Europe is more a legal issue rather than being smart :)

Shadi: European Directive requires monitoring and reporting and this has prompted higher use in the EU perhaps.
... one of the issues is that the US focuses on VPATs,guidance from the EC actually references the WCAG-EM Report Tool directly.

<Zakim> brent, you wanted to say about priority

Brent: Appreciate the prioritization process, think it is a great idea. I might suggest that if there are any P2 or P3 issues that would have a big impact or that are widely requested that may be pushed higher because they are highly requested?

Shadi: We were cautious not to go too far down rabbit holes that take a lot of time and resources. We have chosen instead to start with the easy issues, those that can be most efficiiantly addressed.
... finally it is up to the group. Any other overall questions about the work, the plan, your role?
... Some P1s are stylistic, will look at the first 3 of them.
... this was a comment from several years ago, the title is clunky. One was can we rename it? Envious of the ART and trying to think if there is still a need to consdier the title.

<Zakim> hdv, you wanted to ask about name change

<brent> WCAG is already an acronym. It's like wrapping an acronym inside an acronym.

<shadi> WeRT

Hidde: I like the compliment between ATAG Report Tool and WCAG Report Tool.

Helen: Since Web Content is removed from the title in the future, like the work of Silver, is that an issue.

Shadi: Is there a high enough discomfort with the title to work on a change?

Helen: Seems more likely to stick with it based on Hidde's comment?

Brent: Maybe just drop the EM?
... I usually don't say ART, I use ATAG Report Tool when I speak about it. I would also say out loud the WCAG Report Tool

<Zakim> shawn, you wanted to say *if* we were to rename that tool, we should this, too. :-/ and to say acronym is not the issue I think

Shawn: I have found that too, we really do not need the acronym. The issue was Report Tool vs Report Generator.

<shadi> https://www.w3.org/WAI/planning/statements/generator/

Shadi: We had issue with the word tool because it makes people think it may do the testing and reporting automatically.
... we did use Generator with the Accessibility Statement Generator Tool.

<Daniel> +1 to Kevin, he's just said what I was going to say

<eoncins> Also agree that "tool" is more user-friendly than "generator". "Generator" is very technological driven.

Kevin: The idea of simplicity is important. Tool is such a much easier word for the long term. The explanation of what it does is quickly made and we have a good short word for the long term.

<Vicki_> +1 to Kevin. Plus, it has been around for some time now. I would say leave it.

Sharron: +1 to stick with tool

<Zakim> shawn, you wanted to say that we propose to leave it, and close this issue

<Helen> +1 to keeping the tool

Shadi: OK, any objection or strong feeling to rename?

<Vicki_> Ship has sailed.

<Laura> +1 to leaving it as report tool

<eoncins> +1 to keep tool

<kevin> +1

Sharron: +1

<shawn> +1 to keep "tool"

<Vicki_> +1

<Mark> +1

<Daniel> +1 to tool

Shadi: Next issue may be moot since it is coming into WAI look and feel, does anyone have other thoughts about a logo or icon for this tool?

<brent> Agree, nothing needed if moving into WAI site branding wrapper.

<shawn> +1 to nothing needed now

<kevin> +1 to nothing needed now

<Vicki_> +1 to nothing needed

Sharron: +1 nothing needed

<Laura> +1 to not needed

<Helen> +1 to nothing needed

Shadi: Up next is the question of the WCAG-EM does actually apply to mobile. It uses the word screens and has other guidance on how to apply the EM to the mobile context.

<brent> Allow substitution for phrases "website" and "web pages" #348: https://github.com/w3c/wcag-em-report-tool/issues/348

Shadi: The idea was to take that into the Report Tool. I am not at this time aware of the tool being used in a mobile context so it may convelute the interface to solve a problem that does not exist. Thoughts?

Helen: I have not used the tool but I do use WCAG for mobile apps and sites. Until there are specifically guideliens for mobile, it seems it should be part of it.

Shadi: Maybe take a look at the tool by Tuesday and see if it would fit the use you are imagining.
... I will give you a small assignment, look at the spec, browse through the tool and let me know if it would work in the context of your work with mobile.

Brent: Jan and I were trying to use the tool when evaluating a one page web app. Same URL for each step of the app. So you are putting the same url and instead used a short descriptor. In that way, it did not lend itself to our purpose with the same ease of use as a page designated web site.

<Vicki_> ok

<shawn> scribe: Vicki

<scribe> scribe: Vicki

<Vicki_> Estella: Should be included from a European perspective, also important to include mobile apps

<Vicki_> Brent: I think this should be used to mobile apps, everything. I'm trying to say that it is difficult to use in that respect, if you change the words.

<Vicki_> Hidde: It is not a big issue to replace the word with something else.

<Vicki_> Shadi: I think we need to look at it more closely

<Vicki_> Kevin: The biggest challenge is how do we describe the terms

<Vicki_> Daniel: +1 to mobile, we can use other terms

<Vicki_> Shadi: Looks to me that there is quite some interest in this functionality. The team will look forward into this. Any input, thoughts will be helpful. If it gets too complicated, we might downgrade to Priority 2. We'll bring this back to EO. The renaming is moot.

<Vicki_> Shadi: Do drop any further input, ideas in github

<Vicki_> Shawn: Work for this week. Subscribe to the ?? (some odd mails come in), ATAG Report tool, WCAG-EM prioritization

<Vicki_> bye

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/06/26 14:31:56 $

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/ownershi/ownership/
Succeeded: s/defintin/definition/
Succeeded: s/fro review/for review/
Succeeded: s/acknowledgements page on publication./acknowledgements page (can set it up now)/
Succeeded: s/deault/default/
Succeeded: s/mush/much/
FAILED: s/[ Shawn notes that we have lots of good data on the WAI site overall, since the redesign. ] / /
Succeeded: s/Accessibility Statement Generator/Accessibility Statement Generator Tool/
Succeeded: s/nothign/nothing/
Present: dboudreau Sharron shawn Daniel Vicki Helen Laura Kevin Mark Jenn Hidde Bill Shadi Brent Estella KrisAnne
Regrets: Andrew Sylvie Jenn Greta
Found Scribe: Sharron
Inferring ScribeNick: Sharron
Found Scribe: Vicki
Found Scribe: Vicki
Scribes: Sharron, Vicki
Found Date: 26 Jun 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]