Brent: Let's get started, thanks to everyone for your work and completing the survey. We got good info...

W3C WGs, EOWG in 2016

Brent: I got involved in EOWG after a couple of years at Pearson, joined without much idea of what was expected. Started in listening mode and paticipated as I could. As I was here longer, the Chairs invited me into more of the project work.
... as I moved into more responsibility, I began to learn more about the charters and how the WAI groups really work. it was different from my original perspective. My suspicion was that many of the new folks in EO shared my misconception.
... one thing that is important to know is that we have recently been fortunate enough to have staff editors assigned to develop the resources. I had thought that Shawn ran the meetings, Sharron kept notes and track of logistics and participation. I saw work being done by staff and assumed my job was to review staff-developed work - to review and give my opinions, let staff continue to create and edit the work.
... as co-Chair I have learned that the actual way the WGs work in general is that particpants themselves develop the resources. While EO has had staff resource for the past few years, in 2016 we would like to see participants resume their previous roles as creators of resources, becoming editors too. That will allow us to increase group productivity wihtout putting the full burden of work on the small staff.
... despite the varied skills of participants we need to be sure that our skills are put to work by contributing some direct editing.
... An example is what James is doing now in taking up the unfinished issues from the first set of tips that were released. Since Kevin's time is now dedicated to "Planning..." we have asked James to take up the open issues from the first set of Tips, address them and bring them to the group for review and approval.
... I have explained the role to James and he has stepped in. In order to fully implement his edits, we need to fill in the middle piece, so that James can take the work to the point of having alternate versions in repositories that can be reveiwed by EOWG. We will provide that training in January and will strongly encourage EO participants to resume that role.

Sharron: Yes, this was the way the group worked for the first several years I participated. It has been a luxury to have W3C staff and I believe it is important for others to step up and for all of us to be more active in our contributions.

Shawn: This is the operational model that all of the W3C groups have. Being a primary editor of a resource is one aspect. But another aspect is to think about the level of contribution. Rather than simply saying "I have an issue with this..." the idea is to be sure that when you have an objection you offer quite precise suggestions or even a new draft of sections that you want changed.
... so the stages of review of: Stage 1, we have a fairly complete draft. This first draft is submitted for EO to look at Big Picture questions, is everything covered, is it the right tone and approach, etc. Stage 2 is thorough review where you polish, use your fine tooth comb, and make very clear comments and suggestions.

Stage 3 is the public review and final EOWG review. Stage 4 will be final approval to publish. At that point we do not expect to have major issues to address.

Brent: We understand that people are in various places technically in relation to GitHub and so will use it differently. Any questions?

David: I like this...you have a greater sense of ownership and you can put the pieces together in a positive way.

Brent: Success depends on a great sense of safety and trust in one another. As you polish and complete a draft, we must understand that we will still have the review process. It is important if you take the editor role that you understand that you will have review and there will be different perspectives. So with that level of trust, we can dive in and work and accept constructive criticisms and suggestions for improvement. Thanks, David

Howard: One issue I have is that I don't seem to be able to edit in GitHub. Would appreciate some support.

Brent: We will provide more training and help to solve any OS bugs.

<shawn> GitHub training resources: https://www.w3.org/WAI/EO/wiki/Main_Page#GitHub

<yatil> --> http://w3c.github.io/wai-gh-training-2015-06-29/ Github training

<yatil> --> https://w3c.github.io/ More about W3C on Github

Shawn: I would encourage everyone to not let the technology slow you down. If you can't get GitHub to work for you, submit comments in email and the survey

Howard: It is so much more efficient in GitHub but I hear what you are saying.

Susan: I need training on IRC I think :) This is a general comment, going in I expected more hands-on work so I would like more training on what we are doing, how the review process works. I like this direction a lot. I have a programming background so am OK with GitHub.

George: This was a great explanation and with this level of collaborative resource. I am OK with doing any of the work you spoke about (except minuting - scared of that!)

Shawn: Also we have a mailing list for editor's, it is publicly archived with a samll subscription list, it is good to cc wai-eo-editors@w3.org. That way you have a document thread of what we are working on. So please keep in mind that you can use that list and do not have to have everyone in EO copied but just the small group working on it.

Brent: We also need to re-join. Member participants and Invited Experts all need to complete a process to continue for the new year.

<shawn> rejoin form: http://www.w3.org/2004/01/pp-impl/35532/join

Shawn: Everyone needs to do that within the next couple of weeks.
... do read through the links, you are asked to affirm several things and agree to the participation expectations and requirements.

QuickRef

<yatil> https://www.w3.org/2002/09/wbs/35532/EOWG14Dec2015/results

Eric: Survey results responded to the 8 issues that I had put on the table. There was mostly agreement to my proposed resolutions, only a few comments.
... Kevin noted that we should have Techniques in mind as we filtered and tagged. Sharron, AnnaBelle, and James are working on mapping those so we expect some changes there in any case. I have marked all of the issues a completed which means we are at the end of the large queue.
... we got through the public review, have two items that will be in the survey next time and that's all for a while from this side.

Brent: Thank you Eric, any comments or questions?

Sharron: Wondering how to move on with the work AB, James and I are doing?

Eric: Will show you the process, more offline.

Planning and Managing Web Accessibility

Kevin: Thanks for your comments and review of that...I have responded to GtHUb comments and still have one more to address from the survey.
... now to introduce implement and sustain sections. These are first stage drafts, welcome all comments, thoughts on general content and approach.

Shadi: Just to make sure Kevin that my understanding is that this is the first draft. We are looking for overall input on tone and approach, order of information, is it too repetitive, especially with the Sustain section. For now the editorial detail - fine editing - not ready for that. Looking for high level review. Is everything here that needs to be here? is there too much repetition? Is the order, approach, tone right for this resource. Is that right, Kevin?

Kevin: Yes but so not mind grammar corrections at any time.

Shawn: Go ahead and share re-wording ideas if they occur to you?

<Brent> +1

<Howard> makes sense to me

<George> +1

<Susan> +q

Sharron: To summarize - we are looking at the big picture but while doing that, if you see obvious editorial changes - like tersification - go ahead and do it.

Getting Started Tips

<kevin> Comment on suggested change

Kevin: This issue is realated to public comment on the Tip on alternative text. The rewrite caused a new set of objections, we rewrote again and it showed a high level of acceptance but one suggestion with a strong objection leading to a rather significant change to the Tip:
... Eric's concern is that this is now a bit too big and not specific enough to let people know what action they need to take to meet it. In that way it is like other Tips where you need to read more to get detail.
... next suggestion was to work with other team members to come up with the visual elements that will be within the design. Those were the issues and wanted to open for discussion.

Eric: I found very specific accessibility terms that would be hard to understand if you were in fact new to the field. Putting more detail in the Tip made that clearer for me. I do feel it would be better as two tips but I feel better now that we have that detail in the rewritten tip.

<shawn> proposal in context: http://w3c.github.io/wai-quick-start/designing.html#include-image-and-media-alternatives-in-your-design

Kevin: wanted to open this up to comment...
... with the change to the direction of the tip, there was a question of what example would illustrate the idea most effectively. Put a very rough example. The title of the Tip remains the recently changed title. Pulled some of the detail in a previous sentence, not a bullet list. And pointed to collaboration with other team roles.
... this is all meant to put some pointers and hints to features that the designer would be well to consider in the design process. Reminders that these things are important. If it was to become two tips, one would downplay the collaboration and go back to an emphasis on alternative text.

<Susan> thanks kevin. very helpful

David: If we are presenting all of these at once, it could be confusing, people who are new really need to have these things unpacked to understand what feature designers are providing for which disability group.

Shawn: It is important to remember that this is just about helping designers understand that they need to link to these features or provide for them in design, *not* that they need to provide those things.

David: The features however are not isolated sufficiently.

Howard: The rewrite is clear to me. But I do worry along with David that this is a lot to parse and the designer is going to wonder where do I link, where do I get the material to link to?

<shawn> This page is just about designing. current wording says "Work with content authors and developers to provide alternatives for non-text content."

Howard: Eric's suggestion to create a separate tip for captions is where I am leaning.

Sharron: The tension here is between the intention to provide a high-level tip, versus too much background and justification. need enough to lead them to further investigation but want what *is* there to be quite clear.

Shawn: So if we split it, it would be four tips, quite repetitive. Exactly the same tip four times.

Kevin: Is that a bad thing?

Shawn: Remember that this tip is about the design aspects of providing alternatives to non-text content.

David: Then maybe it should say "ensure that you design accomodates non-text content" Your design schema must allow for these things.

<Susan> +q

Shawn: Someone's version had the word "accomodate" but I wondered if it had negative connotations of providing disability accomodation? I would be happy to be overruled.

Susan: I understand better that this is directed to designers and I think what is there is appropriate in that context. Would point them to some basics, essentials to help them understand.

Shawn: Look at this in context of the entire resource.

<Susan> thanks

Shadi: Coming back to earlier point, I have mild concerns about the word "provide" because people will think they need to create the text alternatives rather than make allowances for them in the design.

<shawn> idea for first sentence: Ensure that your design includes alternatives....

<yatil> [Make sure that your user interface can include links or buttons too...]

<Susan> +1 inclusion vs accomodation

David: I understand why accomodate is the wrong word, so to convey the idea that the design schema must plan for the inclusion of these ...

<shawn> or more directly worded: Ensure that your design includes alternatives....

<shadi> [[maybe "allow for"]]

Brent: If we made the changes as suggested, will you be OK?

David: Yes, I think the two tip solution works but can see if the wording is fine tuned, it could work as one...maybe two illustrations.

<shawn> to long, but this dea: Ensure that your design includes user access to alternatives....

<shadi> +1 to simple word change to help clarify

<shawn> OR *anyone* suggest wording ideas! :-)

<shawn> -1 for a second example

<shawn> +1 to simple word change to help clarify

Brent: I propose that Kevin takes the comments into consdieration and work on the example. Take a quick shot at looking at a new version.

Kevin: I think I can put something together for the test but a more involved example will not be feasible before the break.

Shawn: I do not think we want to add another example, we worked hard to keep examples to a minimum.

Brent: We want to show one example that addresses the items mentioned in the text above.
... is everyone OK with that proposal?

<shawn> anyone add your wording ideas to https://github.com/w3c/wai-quick-start/issues/297 !

David: I am OK with that...I would comment about the example, the nature of it even if there is only one. Am I correct that this is a complex example and that there are simpler examples where something like a simple image is seen within context of an entire page.

<shadi> +1 to david

David: we could then point to several examples within the context of an entire page design. Just a thought, more than one example that shows several aspects but within context of an entire page.

Brent: Yes, Kevin can consdier that.

Shadi: Yes David's example is resonating with me, not sure about the whole page but maybe the media player is not the right example.

Brent: Hard to know when the example is not quite done. In summary, Kevin will draft new text and we will add a question to the survey on that and the type of example that would work best.

David: We might also use examples where non-machine text needs alternatives.

Brent: We want everyone to be encouraged to actively suggest alternatives.

WCAG-EM Report Tool

Brent: Questions were to add fields for recommendations on usability, remediation, or other items not realted to WCAG. A question about ARIA references. Those were agreed to be postponed for future versions.
... the other question about the accessiiblity statement
... Good question, but this is an example of a place where if that is suggested, then we need to have a specific suggestion, a place to put it, and how it would be in context.
... we are seeking clarification about what it would be and where it would go.

<kevin> scribe: kevin

<inserted> scribe: shawn

Sharron: not a good idea. could spend time polishing it. not sure if people thought about it when they filled out the survey?

<James> +1

<Brent> +1

+1 not needed

<shadi> +1

scribe: think it's a distraction. strongly opposed.

<yatil> +1 - convinced

<George> +1 convinced as well

<Sharron> Scribe: Kevin

shawn: Maybe we should ask the people in the survey who said 'yes' if they have changed their minds

<davidberman> +1 supporting Sharron's comment

Susan: I said 'yes', although I am not familiar with the background. What made me say yes is that this is something that people need to do on their own sites. I felt that it was important that we do so as well.

Brent: From the comments in IRC it looks like most are supporting dropping this. Is there anyone that feels strongly that it should still be included?

<Susan> I don't strongly feel about including it at this point

davidberman: I completely supported what Sharron said. When we tested the tool we wanted to know that the tool was accessible, but we also needed to know that the output was accessible.
... This was the case for both.
... It could have one clarifying sentence that clarifies that this is the case.
... Could we consider one sentence that could highlight this rather than having a full statement?

Brent: If you want to suggest a sentence, that would be welcome
... If you strongly feel that something should be in there, then please create something so that we can all comment on this.

shawn: At this point, everyone on the call now thinks that we should not provide a statement.

Brent: davidberman, if you are fine agreeing with what the group has said then that is fine. If you still feel that something is needed then please do write something up for consideration.

<shawn> David: OK with it not being in this release

davidberman: Thanks, I will create something for the group to consider for inclusion now or later.

<shawn> +1

<George> +1

<shawn> +1 to resolution

RESOLUTION: No accessibility statement will be included in version 1.1 update. If davidberman feels strongly that one needs to be added, he will provide an edit for consideration in a future version.

Report Tool - Name

Brent: Just wanted to have a bit of a discussion regarding the name of the tool following the survey question

-> https://www.w3.org/2002/09/wbs/35532/EOWG14Dec2015/results#xq8 Report Tool survey results

Brent: Survey results were pretty even across the board. So we wanted to continue the discussion a bit more today.
... Some key points, using WCAG-EM was often not understood or confusing by users
... Secondly, current name creates an expectation of automated checking. We need to avoid words that include such connotations.

<Zakim> shawn, you wanted to provide more background on WCAG-EM in name

Brent: Want to review the names in the survey and see if we can work down to a final name or a few names to consider.

shawn: Some background on WCAG-EM; this tool very specifically follows WCAG-EM. As such, it is not a general application suitable for any process. Users need to understand WCAG-EM.

<shadi> +1

shawn: We made sure that within the content this would made clear and deliberately included WCAG-EM in the title to reinforce this.

<davidberman> +1

Brent: To clarify on users who didn't know what WCAG-EM was, when I first encountered this the 'EM' wasn't clear and it wasn't obvious to me how to find out more about 'EM'. Once I was pointed to the information in the directions, it made perfect sense to me.

shawn: Perhaps we need to make this clearer, but need to keep WCAG-EM in the name. We also need to bear in mind that the tool has been out for a while now and people are using it. In this case we may not want to change the name significantlyas this would throw current users.
...

<shawn> current name:

<shawn> WCAG-EM Report Tool

<shawn> Website Accessibility Evaluation Report Generator

shawn: Also, a lightblub moment I had was to consider calling this an 'app' or 'application'

Brent: Does anyone else have thoughts or ideas?

<shawn> ftr, I support a minor name change

davidberman: I like the idea of calling it an 'application' rather than 'app', which suggests mobile. Given that it is already out, I am 50/50 now on keeping the same name to avoid confusing existing users.

<shawn> e.g., a minor tweak:

<shawn> WCAG-EM Report Application

<shawn> Website Accessibility Evaluation Report Generator

<shawn> +1 to change the one word "tool"

shadi: Agree that 'app' has connotations. I think that WCAG-EM could be used in the subtitle. Although it was there for a reason to link to a particular specification using the same terminology. It seems that the problem is related to the word 'Tool'.

<Brent> +1 to change the one word Tool

shadi: Perhaps we can consider changing this to something like 'builder' to reduce the change, and avoid the existing problems.

<shadi> "builder", "maker", "generator", "application"

Brent: Ok, so what ideas are there to use instead of 'tool'?

<Susan> +1 generator if it must be changed

shawn: I like 'builder', although that conflicts with the subheading, although that could be tweaked

<shawn> WCAG-EM Report Builder

<shawn> For the Website Accessibility Evaluation Methodology (EM)

yatil: When I look at the survey results, it is pretty even but the top pick is the existing title which suggests we don't have a huge problem. If we have a subtitle this might mean that we don't need to rename.
... It may be that the survey results suggest this isn't such a big thing.

<George> +1 as is but with Sub-Title

<shawn> [ I think the issue of people thinking it's an automatic tool *is* a big issue that we need to address ]

yatil: As the tool is already out and in use with a specialised community it might be that this is an ok name.

Brent: I wonder how many people actually had an issue with the existing name?

James: I put the current name as a 1 in the current survey. I think current users is a good point, but if we have a goal to have more people it might be that a name change would help to engage with them. Just want to make sure that the resource is findable and understandable to new users.

shadi: Totally agree James. Minor point though for clarity, this is not a WCAG report 'thing' but a website evaluation methodology. I think that is an important distinction.

<shadi> [[does not explain evaluation of WCAG requirements]]

shawn: To answer your person Brent, one highly involved and experienced individual has suggested that this was an automated tool. I have also seen this assumption when giving presentations.
... I think we could make a minor change to improve this with out too much problem.

Brent: I would suggest that we pull together a survey question to explore options for alternatives to the word 'Tool'. We should also provide an opportunity for people to provide a rationale for any major change that people might still feel is required.

<George> +1

Brent: Everyone ok with that?

<Susan> yep

<davidberman> +1

Brent: If there are no other comments, I am going to wrap up now.

Next meeting

Brent: Next meeting will be January 8th 2016. We will aim to have a survey out today or on Monday.
... We will also produce attendance and face-to-face surveys for 2016. I know some people are waiting for budget to respond about face-to-face meetings, but it would be good to be able to make a decision on this.
... Thanks everyone, have a restful and peaceful holiday.