Roles and responsibility Matrix

Shawn: Exciting news that the first deliverable is ready. Take it away Bill.

Bill: Our first document, the Role Definition is ready for group review. We needed a set of statements to define roles and their various relationships in the product development life cycle. We were pointed to the AG roles of the Silver TF and found that those have a bit of a different purpose and focus than what we need. Theirs was more work stories rather than tasj-related roles. Looking at our purpose, we have a slightly different angle to be sure that our assignment of responsibilities will make sense and that our analysis fits the definition.
...we need this role definition because, while titles and work assignment names may differ, and people may wear various hats in different compnaies and circumstances, there are specific roles across projects that tend to be common. We have tried to use those kind of role definitions to focus how the way those roles may approach accessibility.

Shawn: So you are defining the roles according to how they may use WCAG?

Bill: When it comes to accessibility, parts of it are owned by differnt stakeholders in various roles. Based on that, we try to point them to relevant standards to support their decision making during the development cycle.

Shawn: So everyone understands that the point is to map specific SC to various roles in the life cycle development?

Bill: Yes that is the point.

Shawn: We are expecting that people will use this to assign responsibility?

Bill: We are not trying to replace anything about roles that other groups are using. We just wanted to define what we need for our analysis.

Shadi: This definition seems like it will be useful for many of the existing resources, such as the Planning and Managing guide. Any thought of using personas?

<Norah> +1 useful resource

Bill: Considered it, but am more interested in making the foundational definition at this time. And unlike the AG document with so much more details and filling them out, this is more basic.

Shawn: Is there a reason, Shadi, you suggest personas?

Shadi: I was only thinking out loud.

Bill: For example in the AG list, they have only titles, having personas may inform the definition, but we felt that we really needed to clearly define the way people work, the actual tasks that they do.

Shadi: Only that many groups are trying to use personas and my thought was that these definitions could enhance and add depth to the persona description.

Shawn: For what we are doing now in this phase, we do not need personas but it may be useful to consider it going forward.

EricV: I really like this document. I recently asked more than 60 people at a conference what their job titles were and only two job titles were the same. They name things so differently. I really like how this defines by what people actually do - what their job tasks are. In some cases people perform 5 different roles.

Shawn: Are you willing to go through and add any job titles that may have been overlooked? Under the typical job titles if you see something that is left out, we do not have a broad country representation yet.

EricV: Yes, I can look.

Bill: That would be very helpful - thank you. You may know of job titles that we have never heard.

Shawn: Roy, could you help from the Chinese perspective?

Roy: Yes, I will look and see if there is something to add from the Chinese perspective.

Shawn: Thank you, we are looking at the draft for the first time and we are hoping to get some feedback in the next week.
... the message will go to the EO list when it is ready for review. Let's get some broad perspective review. That will be great to have.
... any other questions about this?

EricE: We plan to publish this eventually?

Shawn: Yes. It will be a public document - mostly a background document.

Bill: There may be dozens of names for people with those tasks, so it is a matter of having the role defined by job duties. And yes, it will be published but not primary.

Shawn: People can look for the announcement and put in survey or begin to look at any time.

Understanding docs review

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

Norah: We have established a framework for review of the new Understanding documents, set up the first docs for review and heard from a few of the participants. There is not much activity at this time and I would like to encourage a higher level of participation. Could we put a question in the weekly survey?

Norah: I posted a comment and have begun my own review, I will be on vacation next week. I think a weekly survey would help.

Sharron: Yes we can do that. And Lewis, as a newbie, do you feel like you're gotten clear expectation and know how to participate?

Lewis: Not really. Know what to review, but not how to give feedback.

Sharron: Let's do some orientation off line

Norah: I am hoping that we can send a link to the resource as well. There is a link in the wiki to post comments on the corresponding GitHub. So the links are there so that as people have time, they move ahead and enter comments.
... the survey will help us focus on one or two at a time. Once we have comments coming in, the second part will be to compile them into one recommendation from EO.

Shawn: Suggest to bullet out what to review and where to put your comments along with several other comments I sent to Norah. Also may want to add dates.
... let people know what the deadline expectation is. So people can work ahead but know what the current pace is.
... any other questions? Even if you did not commit to working on this in the small group, everyone is welcome and it is open to all to participate.
... any other questions?

Accessibility Statements

<shawn> Background/Requirements: Accessibility Statements Requirements

<shawn> https://www.w3.org/WAI/EO/wiki/Accessibility_Statements_Requirements

<yatil> [ would like to help but no time :-/ ]

Shadi: We talked about this a few weeks ago.

<shawn> Rough Concept Draft: Accessibility Statement Guide and Generator https://w3c.github.io/wai-statements/planning/statements/

Shadi: Objective is to provide guidance for product owners to create statements about the accessibility of their web site or application.
... looking to build a tool to help them build such a statement. Not an automated process but a way to help you include critical parts of an effective statement.

<shawn> "rough concept draft"! from https://www.w3.org/WAI/EO/wiki/EOWG_Participation_Info#Review_Stages_and_Levels

<shawn> "Rough concept draft (or rough wireframe for tool) Review for overall content and general design. Do not bother with word-smithing or copy-editing or design nit-picks."

Shadi: EricV has been doing most of the work We have a very early rough concept draft. We are not looking for input on wording but are still looking at the conceptual level.
... ended the last discussion with a request for a rough draft to look at how we may organize the resource. You may have ideas or resources that you use that are similar.
... seems we are looking at four kinds of info: One is basic instruction/scope.
... second is functionality to support creation of your own statement.
... third piece of content type is best practice recommendation (eg "don't use WCAG jargon") Overall guidance for enhancement.
... Forth piece of content are living examples of actual accessibility statements.
... these are the four types of content. For now they are in one page, giving a feel for the organizational structure. Eric E put some detail about how it might work (not yet functional)
... looking at how we might combine these areas of content in a way that may give support to people trying to present an accessibility statement.

EricV: It may look great when it is short but as it develops it may look so extensive that people will be intimidated and likely to not even begin. The expand/collapse elements are meant to address that. Eric E proposed that there could be a two column version as people make choices, more content may be added.
... the idea was to collapse everything and as you clicked the info button, more function reveals itself. Is this the way to go forward?

Shadi: Since both EricV and I are so immersed, is there anything we have left out?

Shawn: The links were posted so we hope all are prepared, but are there questions before discussion begins?

Nic: I really don't have a lot of feedback but want to say this approach is brilliant.

<yatil> 1 to say really useful!

<shadi> https://www.w3.org/WAI/eval/report-tool/

Shadi: Can I ask about the idea previously expressed in comparison to the WGAG-EM Report Tool and how it is divided into a multi-step process. For this we do not perhaps need such an elaborate process but if you look, there are steps provided and you can make your way through that.
... this is something much more geared to the assumption that people know what they want to do.

<shadi> https://www.w3.org/WAI/teach-advocate/contact-inaccessible-websites/

Shadi: and there is another resource, the "Contacting Organizations about Inaccessible Websites" Has a short list of the steps that are to be considered and you can scroll down for elaboration. Beyond that are the examples.

<shadi> https://www.w3.org/WAI/planning/org-policies/

Shadi: another example of previous work is the development of policy.Includes several elements that should be included and gives backround, guidance, examples, links to fully developed policy.
... you may also have ideas from outside WAI that can informa the process

Shawn: One thing that struck me when you look at the report tool is the model that here is where you put info and you can get more information through this link. As people use this tool, they will not need to look for the detailed info. In the case of the statement, they are not likely to use it repeatedly.
... if that is the case, you may want to consider giving the background info by default rather than having to ask for it.

Shadi: Good point. The info in an eval report should be objective. In an acessibility statement, it is less straightforward. There may be legal or management considerations that have to be considered

Shawn: High level, organizational comments. Do we want one page, sequential pages, feel free to brainstorm...

Lewis: The intro is really really long. Seems intimidating.

Shadi: Picking up on the idea that if forget the intro for now and scroll down, does the content help make it less intimidating?

Lewis: I think the page content list may not be needed.

Shawn: Another point is that a simple, minimal accessibility statement is really short. But if you look at the offered list, there are a dozen or so options. If people land here do they even know what an Accessibility Statement is. What if the minimal example is in the intro.

<yatil> [ I think the default accessibility statement could be the example. Then you could click edit to fill in your own details. ]

Shawn: can show people that it need not be big and scary
... I totally see where Lewis comes from. I do think the TOC makes it possible to jump to specific sections but do see the overwhelmingness.

EricE: I want to put something here, a suggestion for a two-column layout with check boxes that allows customization. Another idea is to by default have the minimal example with option to add more as needed.

Shadi: I understood that while you are follwing the info in the main column, the associated column builds the statement from checkboxes.

Shawn: So the statement would be in left hand column and the form in the right hand?

<Norah> additional information in the summary would be helpful. ex. A web accessibility policy can be a short simple statement or a comprehensive policy. Find examples of both approaches on this page.

EricV: As you choose an option in the left hand, it adds in the right hand.

Shawn: One idea is to allow people to choose whether they are just reading (no forms would be offered) or generating (which would then include the forms)
... I like the column idea, actually I like both.

<shadi> https://www.w3.org/WAI/tutorials/menus/styling/

Shawn: people could just read at the information gathering stage and avoid the distraction and clutter of the forms until they are needed.

Shadi: Look at the link to the tutorials and when you scroll there is a live example.

Norah: I like it all on one page. Summry could be more developed, now seems only a restatement of the title
... could add info that tells people that a statement may be simple or more complex and prepare people for what they will find. Better expectation of what they can find and do here.

Shadi: That puts it more in the area of the "Contacting..." doc.A short "here is waht you need to do" statement to not be daunting.

Shawn: When you looked at the different ways we have approached, I did like the template example. Similar to what EricE said. Having a minimal example may fill that role.
... in Developing Policies at the bottom, in Contacting we have a template email. Some people may not have the patience for the individual forms and would prefer a template to expand on.
... so the tool may be a template statement or that might be an alternative to the form.

Shadi: So you can click on the template to get more info about what goes in different places?

Shawn: I would want to see the whole thing. The twelve aspects to be considered can be daunting as Lewis said.

Shawn: before we look again, it would be good to have an example minimal statement.

Shadi: We would probably need to have one that says a few exceptions and that could make it problematic.
... may require more than one statement.
... Any further thoughts? Useful discussion today, thanks all.

EricV: I agree that making a minimal statement is an interesting idea but there is consdierable variation among compnies, countries, legal environments. We may need to make minimal statements to be autoselected based on your specifics. Brainstorming.

Shadi: Things like who to contact with problems, how to provide feedback, all those things should be in the minimal statemnt. Can't think of EU requirements that are beyond what would be in minimal statement.

EricV: OPtions for branding and allowing people to add other personal options.

<Nicolas> Eric E asks if Shadi could paste the link to the current EU draft in IRC, so he can uninitiated like him can compare

Shadi: OK giving the group one more chance to weigh in. Was there a final decision about format? One page, early on example or minimal template, and a few other ideas about how to organize following content.

Shawn: There is flexibility about the summary, you suggested instruction on what to do -OR- a sample statement.

Shadi: Maybe they can also be combined in three or four high level headings.
... the key parts with the individual elements within it.

Shawn: And the TOC has the capacity to group items.

Shadi: Thanks for your input, we will take another iteration.

Shawn: Do you feel like we should put this on the survey this week?

Shadi: No I think we need another iteration.
... please do keep the resource on your mind and let us know if another, interesting approach occurs to you.

Wrap-Up

Shawn: By 18 July we plan to have a draft of the Accessibility Statement for full review. Add time to your calendar for that review.
... Understanding Docs info will be posted to work for this week.

Sharron: and there will be a survey for the Roles work and a few other questions.

Shawn: Be sure to update availability, at this time we plan to meet on the 5th but let us know vacation plans, etc.
... thanks all, have a good weekend.