Introductions

All: quick round of intros - name, location, role in job, time with EO.

Ra11y Matrix requirements

<shawn> Accessibility Roles & Responsbilities Project Plan - https://www.w3.org/WAI/EO/wiki/RA11y_Matrix#Project_Plan

Brent: The survey results have been processed. The team will bring any issues that need further resolution to the group today. They have reviewed submitted comments.

Denis: The matrix is about defining roles in projects and aligning them to the accessibility responsibilities associated with those roles. We want to make accessibility relevant to and easier to implement for all the stakeholders.
... In the past when I have done trainings, I found that people whose roles were not involved would feel their time was wasted in trainings that did not mean anything in their role. So this project came from understanding that people want to be able to focus primarily on the accessibility aspects that are relevant to their actual job responsibilities.
... When Bill and Sean and I - who have been working on this idea and building a matrix - decided to bring it back into EO we needed a project plan and that is what we will look at today. We have a three year timeframe within the EO charter. Will start with a pilot of the UX Designer role and, as we work through it, develop a template for other roles.
... We have looked at submitted comments, worked through the ones that are editor's discretion, and there remain three things that we felt we need more input on.
... One of the process things we are modeling here is that small groups can do a lot but that there are some things that need full group consideration. We have three of those issues to discuss today.
... As far as I am concerned, everything is open to discussion. But here are the three things we would like to discuss today.

Brent: And once you have enough information to set a direction, you can move on.

Denis: OK the first issue is the use of the term matrix. She does not understand why we would use the term.

<Brent> Why Matrix? Issue # 10: https://github.com/w3c/wai-roles-responsbilities/issues/10

Denis: We are not married to the term "Matrix" but we chose it because it comes from looking at different aspects that while they are presented as tables have relationships with each other. The relationships give you insight into a process and make a more dynamic event. A matrix (and I am old enough to like the feel from the movie) helps change an approach and that is what we are seeking. I see it as almost like a transformational moment as you work though these inter-related aspects and signify how it will impact others and how they will be empowered to do their job. If there is another term that represents that more effectively I am open.
...We considered framework (trouble with translation and overused) blueprint (too prescriptive, weare not building a roadmap). But happy to consider what options might be as strong and compelling. We see this as more than a table.
... anyone else really opposed to the term matrix?

Brent: Initially I was leaning toward Shawn's question, but I have been convinced by your rationale and no longer have a problem with that.

Shawn: I appreciate your explanation too and can accept matrix. Still not sure I am comfortable with Ra11y.

<Brent> "RRM" Roles and Responsibilities Matrix

<shawn> ARRM - Accessibility Roles and Responsibilities

<shawn> +1 for ARM Accessibility Roles Matrix

<Norah> Role Mapping

Denis: Yes I understand and may share your hesitation to that. The simple fact that there is a pun there does not make it a good one. We had that discussion and would rather not spend too much time revisiting.

<rjolly> +1 to not spending too much time on this.

<shawn> +1 for mapping

<Norah> +1

<shawn> ARM - Accessibility Role Mapping

<Vicki> +1 shawn

Eric: In general keeping that as a working title is OK and once we know more about what the deliverable looks like, we can take another look.

Shawn: I know working on titles can be annoying for some but this is a big awesome project and we do not want something that causes discomfort to get too ingrained.

<yatil> ARRMM - Accessibility Roles and Responsibility Mapping Matrix ;)

Shawn: Norah came up with Accessibility Role Mapping, and + from Vicki

Denis: What we have now is just a code name for the project and I am happy to explore the others, interesting.

<Norah> Role is important piece to include - Role Matrix seems good too

Brent: To Eric's point, once the deliverables begin to take shape, we may have a clearer opportunity for renaming.

Denis: OK can circle back and thanks for the ideas.

<j-pulido> WARM is a great acronym, I think

<shawn> +1 for WARM - Web Accessibility Role Mapping

Shawn: Mapping seems active and aligns well with the decsion tree.

<Norah> mapping includes room for overlaps

Denis: Another issue is the fact that there is a document developed at the Silver TF. They have developed a roles document of another sort. It gives perspective about how various roles are impacted. The list they have for job stories is like 31 roles. We have far fewer but are meaning to define within the product development life cycle where will people have an active role. Their list is broader

<Brent> Silver roles - Issue #9:https://github.com/w3c/wai-roles-responsbilities/issues/9

Denis:...but the roles are less clearly defined. We find different relevant issues for consideration based on the roles we have defined. Ideally we could try to align more closely but we think the job stories goal is to give a wholistic description of how accessiiblity impacts various roles and ours is more to define the responsibilties within those roles and make specific assignments. It may be interested to create relationships between them but the focus seems slightly different.

Shawn: Need to change "opposed" and communicate with the Silver TF and make sure we are in sync. Don't want to be in conflict. OK if there is not a one-to-one match but want to stay aware of each others work.

Denis: Perhaps we can look into all the different roles they have defined and see which are part of the project development life cycle and create sub groups.

Bill: I did not see anything in the document that actually defined the roles they use. There is for example only one designer role whereas our approach critically distinguishes different kinds of designers within roles.

Denis: We could use those stories in our examples, illustrating how the impact is realized. Good idea to work in a collaborative way which requires communication.

Brent: Have discussed the concept with AG that there is excitement about this project and working collaboratively on how the roles are defined and developed.

Denis: Finally we have a question about defining the decision tree. The example you gave Shawn of the alt text tree is a good one but this one is more about process. How do you approch accessibility decisions based on your role as X.
... we made it broad on purpose so it can help people make decisions about where different responsibilties are assigned. Part of what we are doing is developing a bit of an instruction manual and understand that the roles we define may not 100% fit every job and may need to be re-assigned and want to give them a rubric that will help make those assignments.

<Brent> Deliverables descriptions - Issue #5: https://github.com/w3c/wai-roles-responsbilities/issues/5

Bill: Yes, everyone's organization works differently. Various parts of a process may be uniquely formed. We cannot provide a checklist that fits everyone's interactions internally or through a vendor but maybe we can create a way to assign ownership within their existing processes and customize it to their own needs.

Shawn: I get that different orgs do things differently but still I do not see the tree.

Bill: An error may show up but the cause may be code or design or QA and as a novice how do I know where to assign the need to fix? We have business owners who do not assign anyone other than developers for repair and it is not always appropriate. Need a way to route a problem to the actual place it can be fixed. We have not completed this experiment yes ourselves.

Shawn: But you cannot make a decsion tree for every possible point ot error, can you?

Bill: Here is a case where you have a tree that helps you decide where the responsibility can be assigned. Helps you understand is this code, interaction, presentation, content. We have not worked it through completely. When I go through the excercise of assigning responsibility I have an deep understanding of the requirments and where it fits in a process. But how does someone with less experience do that?

Norah: Listening to the description, maybe rather than a tree this is where the matrix idea is realized that helps illustrate the flow of decision making.

Shawn: Do you have a specific example? I see only one question - who is responsible, so where is the tree?

<Norah> maybe more of a map than tree?

<shawn> +1 to norah "more of a map than tree"

<shawn> decision mapping

<Norah> map and workflow - process diagram

Denis: There may be issues where there is more than one role that has responsibilty. Think of alt text and all the roles that are involved in coding, design, and content - different roles have some responsibility.Something to reflect the interdependence.
... think about the table we made several years ago on WAI-Engage. The idea of a decision tree that shows how different people are involved to do things well and how those perspectives relate and makes it happen at the end.
... a consideration is how does something like alt text affect the work of all the various roles that feel impact.

<Norah> process map

Denis: we want to make it almost an infographic that makes it clearly mapped out in front of you.

Norah: It sounds more like a process diagram or process map that shows a workflow rather than a tree that brings you to a stop.

Denis: Could be.

Bill: (Shares screen to show how the descisions lead to a sequence of assignments) And this is how we worked oursleves as we determined which SCs belonged with each role.

Sharron:If the idea of a tree resonates with Denis and the team, I am happy to give them the opportunity to explore and flesh that idea out. Can always change later if it is not working.

Brent: Any other thoughts?

<Norah> seems very helpful!

Denis: Our next step will be to amend the requirements doc. Not sure about how much more work to put into this before actually doing the work.

Brent: Almost there, work to assure that people's comments were addressed and then get going on the work. Anything else?
... good discussion, thank you for the time.

WCAG2.1 Understanding

<Norah> https://www.w3.org/WAI/EO/wiki/Understanding_docs

Brent: Norah has agreed to lead the review and revision of the 17 newly published Understanding docs. We are invited and encouraged by AG to do serious revision. Norah has a small team she is leading and will take us through the process she has in mind.

Norah: Thank you Brent. Sharron made a wiki page that our small editorial group will use to organize our approach to revise the published docs for clarity, brevity, and understanding. The process will be to look at the one we have prioritized on Friday. We will comment on GitHub for one week. My role will then be compile those by Wednesday.
... For the first week we can focus on just one document and try it out to see if we can add more than one each week. I think we may just go in the order here on the wiki unless there is another suggestion for priority.
... Hoping that is clear, any questions?

Norah: Participants signed up so far are Sylvie, Denis, Robert, Chris, Nic, Brent, Vicki, and Lewis. I wondered if there is a prioritized list or should we just work through them in order?

Shawn: There are no requests that I know of from AG to re-prioritize.

<shawn> https://www.w3.org/TR/2016/NOTE-UNDERSTANDING-WCAG20-20161007/understanding-techniques.html

<shawn> "Important Information about Techniques" e.g,. https://www.w3.org/TR/WCAG-TECHS/G1.html

<Norah> https://www.w3.org/WAI/WCAG21/Understanding/

Denis: Be sure that we point people to " Please note that the contents of this document are informative (they provide guidance), and not normative (they do not set requirements for conforming to WCAG 2.1)...."

Norah: I am not 100% clear yet where these pieces reside and will work on being sure I know how to do that.

Shawn: Make clear that while it needs AG approval, and we should coordinate with AG chairs. It does not need EO approval.

Brent: We can offer EO approval but really are relying on the small group to finalize the revisions.

Norah: Will Shadi serve as liaison?

Shawn: No
... better to have the direct connection to the AGWG chairs

Sharron: I can work that coordination

Shawn: Also, we want to cooordinate things like days of week to work with AG review and approval cycle.

Brent: Any other comments to Norah?

Wrap-up

Brent: Not sure we have any questons for a weekly survey, any other topics to bring?
... if you want to support the Understanding docs, we can really use your help and the expectation will be high.
... TPAC registration is open. If anyone is planning to go, please let us know. Small group is forming

Feedback on revised website and EOWG resources

Sharron:Wanted to share that recent references to a select few EOWG Resources at a conference earlier this week earned me a drink at the bar later. An attendee was grateful to learn about them and said my 10 minutes sharing them was worth the whole time of the panel discussion.

<shawn> From public comments: Did that website get a recent upgrade??? I'm finding more resources there than I ever noticed before! Very helpful and user friendly!!

<yatil> \o/

<Vicki> Yay!

Brent: Thanks all for sharing and for your contributions. Have a good weekend.