December meeting schedule

Brent: Next week the 16th will be the last meeting of the year. We have a few key things to get through so please plan to spend the time this week to review and respond to those.
... Chairs are asking that group put the extra time in the next week to get through the Inclusion doc, Tutorials, Easy Checks
... need a lot of focus on these items this week so they can be complted by Wednesday. Will lay out expectations today and make sure that it is reasonable to complete by Wednesday.

Accessibility, Usability, Inclusion

Brent: Linked from agenda, much work has been done, a few remaining issues to resolve

<Andrew> http://w3c.github.io/wai-inclusion/

Shadi: Please refresh agenda, I have added the sub-bullets for topic discussion. I have received really good comments. The major issue was the repetition. We have made changes that shift and tighten up the document, updated the wording. Thanks to everyone who commented.
... will give a chance for one more review. Chairs have suggested that this becomes the through review and the permission to publish, will talk more about that.

<Brent> Issue #10 Title

Shadi: remaining open issue is the title. subtitle was Related Aspects of a Web for All. Several noted that 'web for all' could be distracting since it is used broadly outside of accessibility. A suggestion has been - a web for everyone, referenced by TBL.
... then however, "related aspects" is necessary in order to communicate that the article is discussing how they relate to each other.

Shadi: so those three titles, the current one, and the two current candidates for replacing it.
... we need to close that thread about which of the titles to use and then put it forward for final review and permission to publish.

<shawn> +1 for current title: Accessibility, Usability, and Inclusion: Related Aspects of a Web for Everyone

<dboudreau> +1

<Howard> +1

<Brent> +1 to current

<Laura> +1

<Caleb> +1

<chris_langston> +1

<shawn> +1

<yatil> +1 - let's do this!

<Andrew> +1 - happy with longer version

<Robert> I also prefer shorter title, but this longer one is also fine, so +1

<shawn> susan from GitHub "I'm okay with "Accessibility, Usability, and Inclusion: Related Aspects of a Web for Everyone."

Sharron:I am not going to block consensus on this, but wanted to raise the question of how we continue to burden out titles with over explaination. It may not be necessary and in some cases the subtitle itself may cause confusion or make people thing it is more ponderous than in fact it actually is. Tis is fairly short, relatively concise doucment and the title may not need to do so much. The very first sentence is quite explanatory. But only minor issue with this particular title. I will not object to using the subtitle here but wish we would consider crisp short titles.

<dboudreau> +1 to what Sharron is saying :)

<shawn> susan from GitHub: "having "Related" or similar is important."

<Howard> I kind of agree with Sharron but am okay either way

<Andrew> +1 for tersification (but happy if we don't)

Brent: I think there is the question of whether it is meant to be a creative type article, different from a how-to or if it is more of a descriptive piece you may need an explanatory title.

Andrew: Shorter title is more succinct, but happy to go with the longer one if it will get the document out.

Shadi: This will not change the timeline, I think many of us can go either way. What I would like is to make a decision one way or another today.

<chris_langston> +1 shorter title, but not really strong feelings. I just think succinct is generally better.

<shawn> live with happily

Eric: The different subtitles might not have too much impact, I prefer the shorter one somewhat but we can go with the longer, more descriptive one, we can shorten it later. We can all live with the longer title, the more important thing is to get this out.

<Robert> +1 to what Eric is saying

Howard: "Related aspects" is a clunky phrase and may throw people off. I prefer a shorter title but will go with whatever people choose.
... we may be overthinking by adding the clunky phrase to the title.

<shawn> [ I think -0.5or so for shorter title from Shawn and Susan ]

<chris_langston> short

<dboudreau> short

<shawn> long

<Howard> short

<Caleb> Short

<Sharron>short

<Robert> short

<Andrew> short

<Laura> short

<shawn> [ Susan long ?]

<Brent> short

Brent: Maybe we don't need any subtitle at all? The first three words (main) title would catch my attention. I would read it no matter what the subtitle is.

Shawn: I just noticed Andrew put in GitHub an alternative

<shawn> Andrew github: if "relationship" is important, and I appreciate that it is, what about "Accessibility, Usability, and Inclusion: Related Aspects"? as a shorter title? Do we really need the "for a Web for Everyone"?

<Andrew> did we consider Accessibility, Usability, and Inclusion: Related Aspects

<shawn> +1 for including related somehow - there were other ideas in GitHub

<shawn> reminder of related ideas previously in GitHub:

<shawn> How Accessibility, Usability, and Inclusion are Related

Robert: If we take out web for all/everyone, we mentioned putting it in the body of the document somehow. Did we decide on that? maybe should consider as an option?

Shadi: And how well are these represented in the document itself is important.
... I thought there was relatively little support for that since it flattens the title and may be stale.
... what do others think?

Shawn: gets the idea across, is short, may not be very smooth

<Caleb> Accessibility, Usability, and Inclusion: Related but Different

Chris: honestly I just don't like : in the title. It feels designed by committee every time i see it. I'd rather see a direct statement that doesn't need a colon. plus i put "electric boogaloo" after the colon every time I see one and it totally kills it.

<Robert> The Interdependence of Accessibility, Usability, and Inclusion

<chris_langston> +1 Robert's reco

<shawn> +1 to the idea of Accessibility, Usability, and Inclusion: Related but Different

<yatil> Accessibility, Usability, and Inclusion are Related but Different (to have no : for chris)

<Robert> I'm not sold on having a brand new title, btw. Just responding to the "clunkiness" comment about Related Aspects

Brent:what about just "Accessibility, Usability, and Inclusion". I would read it, just to find out what the three are about.

Sharron: +1 Brent!

<chris_langston> +1 brent's idea

Chris: subtitles are for sequels and middle management memos that everyone ignores

<Caleb> +1 Brent's idea

<Laura> +1 to Brent

<Andrew> +1 for even shorter

Shadi: anyone want to speak to the idea of removing the subtitle? It seems it does not say much, does it describe the content enough?

Sharron: And the first sentence is quite clear about what it is going to be about.

Caleb: Suggest maybe to do another poll. Since short subtitle won last time, maybe we can do another poll between subtitle and not subtitle

Brent: For me, those three words put together in a title, it is intriging enough to read the article and the first sentence tells you what it is all about.

Andrew: Feel a bit the same. Presenting you with three words, expect a definition and that is what is provided - it works well for me.

Eric: Noticed that we always have short names for docs and this is the short name that we always use, so it fitswell.

Shadi: So it looks to me that a poll may be good, but in the meantime are there any objections to removing the subtitle completely?

<shawn> Shawn: As I think about it, I am warming up to just the 3 words!

<Howard> no objections

<yatil> +99.99 to "Accessibility, Usability, and Inclusion"

<dboudreau> no objections

<Caleb> No objections

Shadi: any concerns? even mild ones? Put those out for consideration.

RESOLUTION: The title will be Accessibility, Usability, and Inclusion with no subtitle.

<Howard> +1

Shadi: Thanks everyone for taking the time .

<shawn> Shawn: Thank you everyone! I know these discussions are hard and we wanted to give up -- but it turns out I think we came up with something that we *all* like much better! Thanks for patience!

Shawn: Yes, thanks everyone for taking the time, I think we have worked through the issues so that now everyone is happy with the outcome.

Shadi: The last point is how long the survey should be open. People need to do one last review. Though the document is short, we need thorough review and if we can combine that with approval to publish, we can get this out before the end of the year.

<Andrew> can review by mid-week

Brent: Want to see if the thorough review can be completed by Wednesday - are there any objections? anyone unable to do that?
... seeing none, we will make that our plan.

<yatil> should be able to do it

<dboudreau> no objection

Shadi: and many thanks to everyone's comments. I look forward to your further review.

Sharron: and thanks to you and Shawn for crafting the doc, good work!

Easy Checks

Brent: Caleb and Shawn have been working hard on this one, trying to get to resolution.

Caleb: Take a sip of coffee and get ready to work through another one. I will walk you through the disclaimer language. There was a request to make the notice big and un-missable that this is not a complete confomance review.
... we created a big highlighted box and added the word IMPORTANT and redrafted the first couple of sentences.
... reads current version of disclaimer

<shawn> "Important: These checks are not definitive and not comprehensive. More robust evaluation is needed to identify all potential accessibility issues. (More info is under Encourage thorough accessibility evaluation.)"

Caleb: also makes the case in the body of the first paragraph and added again at the end. We did not put that into every section in order to not overdo it and discourage people.

Caleb: any objection to the language of the disclaimer?

<yatil> no objection

<dboudreau> nope

<Brent> no

<Andrew> good work

Sharron: good, looks like a very clear statement

<Brent> GitHub Issue# 37: https://github.com/w3c/EasyChecks/issues/37

<shawn> shawn notes the second paragraph says "These checks cover just a few accessibility issues and are designed to be quick and easy, rather than definitive. A web page could seem to pass these checks, yet still have significant accessibility barriers. More robust evaluation is needed to evaluate all issues comprehensively. "

<shawn> and there is another section "Encourage thorough accessibility evaluation"

Shadi: I completely agree with making the disclaimer only once. Such a highlighted section is good and the fact that it is brief. I have a concern with the word "all" in relation to more robust evaluation. Reword so it does not swing too far the other direction.

Caleb: What if we change it to more of a call to action, more triggering to the link. Remove the second sentence entirely.

Shadi: One of the issues is that the gap between doing such a prelimnary set of checks and a full conformance evaluation is a big one. Don't want to mislead people.

Caleb: What is the point of this document except to do a quick check? No on is going to use this for a comprehensive evaluation.

Shadi: It is to get an indication and to speak to an audience that does not have technical expertise. But I have seen it used more definitively.

Caleb: Maybe the language could be more friendly "Now that you have done this...learn how to take the next step."

Shadi: Yes we may not be stair stepping them in the way we expected.

<shawn> Important: These checks are not definitive and not comprehensive. They do not cover all accessibility issues. More info is under Encourage thorough accessibility evaluation.

Shawn: We already have this language in two places. The only purpose of this is to emphasize the point.
... what about the change in the second sentence?

Brent: I like it, I like the change. I was considering the scenario of someone finding EasyChecks under pressure to improve, they realize they have problems, and understand that they need to bring in external help.

<Andrew> +1 to Shawn's suggested change - clearer _and_ more succinct

<shadi> +1 to changed text

Brent: I like the updated language, Shadi do you?

Shadi: I do too it is better.

<Brent> I am with Shawn, clicking the link made me mad. Just went to the bottom with same info as at the top.

Caleb: If we look at the new version, which I like, what if we remove the last sentence if it takes you to the bottom and makes people mad.

<chris_langston> +1

Shawn: I had the same thought, lean toward leaving it for the skimmers but am happy to delete it.

Caleb: My perspective is that this disclaimer would make me forget this document entirely.
... but if people are mis-using it I see that it is necessary.

Kris Anne: Instead of making it a disclaimer at the top, could we put it at the bottom? "You have taken the first steps toward accessibility..." I agree that a strong disclaimer at the very top would be discouraging.

Shawn: I read a research paper that says we have evaluated these sites based on EasyChecks and have found that there is such and such a rate of WCAG success based on our findings. It is a tough balance. One idea was to change the language in paragraph 2 but preferred to have more welcoming language at the first.

Eric: It is too bad that we have to think about that since I think the comment is pretty clear about its intent. Maybe a paragraph called "Scope of Easy Checks" rather than a highlighted box
... could even use an icon to draw the attention.

Caleb: Do you think if it is another section in the document it would serve the purpose, solve the problem of people abusing the document?

Shawn: I personally don't like this highlighted section, but think it may be necessary

Shadi: I am not sure what is necessary. Like the idea to remove last sentence, may make the statement shorter.
... may be the compromise we need. May help not only those who are mis-using but also the peer review.

<shawn> +1 for removing last sentence

Sharron: I want to strongly support Eric's idea of having a Scope heading with a paragrpah that explains it and no highlighted box. Not sure even the highlighted box will ncessarily solve problem and can be discouraging to others. It may be that nothing can entirely stop the problem. What if the Scope section had a heading that says "What Easy Checks Can and Cannot Do". I think we all have understood that the highlighted box is likely to be discouraging.

<Brent> +1 to Sharron

<Laura> +1 to Sharron

Andrew: I often point this to people and give the disclaimer verbally when I recommend it. It must be called out in some way, we must make it very clear, near the top and if we put it into a Scope section could be OK but must be quite clear.

Shadi: It does have quite some impact beyond just a few researchers, so we can follow the idea of a Scope section but it is necessary to be clear.

Eric: I am not opposed to the yellow highlight, in fact I scrolled right past it. I like the "can and cannot do" however because it is straightforward.

<dboudreau> +1 to trying out a scope

Shawn: any objection to us trying the approach of putting it into a scope section?
... hearing none, let's try to get that done today and maybe we can get it out again today for the survey.

Shadi: I think you have all the content there and the section would be quite short. For editor's consdieration, add that this is only indicative and can be misleading if not put in proper context?

Shawn: Look at second paragraph - if there was a clear heading over that does it work?

Shadi: Yes

Caleb: OK let's take a stab and putting the heading over that paragraph and get it back out tot the group.

Shawn: And the next subtopic has to do with the open issues...listed in the wiki
... most are marked done. The activity that is needed is to go through the wiki page and verify that the things that are listed as not done, have they in fact been done? and secondly if not done, move to GitHub issues.

Caleb: I have no background and context to do this.

Shawn: Is there anyone to take this on?

Brent: So we need a volunteer? Is the task to review the listed open issues in the wiki and determine if in fact they are still open and if not, to move them to the GitHub issues?

Caleb: Sharron, at one point it was decided to move these to the GitHub

<Robert> I can take a shot at it, but don't have the background to know

Sharron: I can be available to Robert to provide context.

<Brent> Propose Robert to do the Completion Plan review on the resource. He may ask Sharron and Shawn for information when needed.

Caleb: was it perhaps already done?

Sharron: I don't think so

<shawn> https://www.w3.org/WAI/EO/wiki/Easy_Checks#Completion_Plan

Caleb: We have done everything in the completion plan but there are other random things below that have tangled threads and there needs to be a reconciliation.

Shawn: Looking at things listed and either grey it out or move the issue to GitHub.

Brent: So is that clear?

Robert: Yes but I think you can rely on the fact that I will have lots of questions.

Brent: Sure, and Caleb will send a detailed email about the process.

<shawn> Robert - feel free to call me with any questions (I might be slow to respond to e-mail, so calls are best!)

Caleb: So once we do the Scope section, can we publish and leave the GitHub issues for next version or...?

<Andrew> +1 to get it out after 'scope' added

<Laura> +1

<Caleb> +1

<yatil> +1

<dboudreau> +1 as well

Sharron: I expect that any open issues from the wiki are minor and we should publish after the scope section is fixed

Shawn: If it could be done by midweek that would give me more confidence
... because the disclaimer was one of the buried issues and there could be more that are important and that we do not want to have sit for two more years

Sharron: So we will work through the wiki and maybe we can have a resolution to publish next week?

Shawn: If by chance it works out that everyone is happy with the new scope and Robert does not find issues that prevent it, we can publish next week. Otherwise, it would wait until January.

Brent: Let's work with this plan but recognize that we don't need the urgency.

<Robert> I'd like to keep the urgency to move issues into GitHub, fwiw.

Shawn: One idea is to publish now and do another promotion in January.

Eric: We need to get off the idea that publication and outreach has to happen at the same time.

<Brent> +1 to Chris and Eric's point

Brent: Thanks everyone, next topic...

Tutorials

Eric: I put together a new proposal for Carousels Tutorial and have put questions into the survey. Asked about organization, code examples, links within the tutorial, Will expect to have them completed and published by the end of January

Brent: any questions?

Any other reports or updates?

Brent: Does anyone else have anything to report for the group to consider about you own resources?
... hearing none, next topic

Last week of work

Brent: We will have a lot for your consideration this week. Appreciate your time but remember that you will have two weeks off afterward.

Shawn: Wanted to ask about priority...approval of AUI doc, approve scope and may be last thing to publish Easy Checks, and review of Tutorials. What is the priority?

Brent: I want people to prioritize all of these - we could send Shadi's survey out now, and add your questions when you are done. I want people to did in and get them all done. make it all a priority.

Eric: Approval surveys are always good to prioritize.

Brent: Can we send the AUI survey out? we can send it right after the meeting if so.

Shadi: yes it has been approved

Brent: So we can send out the weekly survey afterwards and send this one now. I appreciate everyone being willing to step up and get the work done.

Shawn: Thanks for patience and extra effort in getting things done.

<dboudreau> thanks everyone :)

Eric: +1