Approach for October

Shawn: We have talked a bit about this and sent the email about the need to post drafts of these works in progress by TPAC. Ww will not consider them complete but will post in DRAFT form. Following TPAC we will polish and be able to announce publicly.
... we will be able to review at a more reasonable pace, polish the documents and announce them after TPAC.

Shawn: Wanted to be sure that we discuss any comments in the survey. Does anyone have comments about the tutorials that they would like to discuss today?
... or on the tools?

Paul: things are looking pretty solid to me

<Wayne> +1 with paul

Shawn: Eric, there is a comment from Andrew about the Evaluation Tools list. Was that clear?

Eric: Yes I know what to do.

Shadi: If there is time today I would like to discuss the WCAG Report Tool

Wayne: I focused on the other papers, not the tool.

Shawn: Yes that was the right thing, thank you

Strategic Planning document

<shawn> http://w3c.github.io/wai-planning-and-implementation/Overview.html

Shawn: Shadi and kevin, want to discuss the title?

<shawn> Strategic Planning for Web Accessibility: Guidance for Developing a Plan for Your Organization or Project

Kevin: Judy has reservations about the title. Using the term "Strategic Plan" may be a leap too far. Is it delivering on that title? She shared some of the thoughts expressed by others last time about expectations raised.

Shawn: We had that discussion last week and had decided to sleep on it. Do we want to reconsider? Paul, since you were not here last week, would you review with a fresh perspective. See how it fits, express any concerns you might have.

Paul: I share Judy's concern - it does not really seem like Strategic Planning. Planning is right, unsure about how well strategic fits.

<shawn> one motivation for title change was to differentiate from Improving the Accessibility of Your Website

<kevin> Former title was Implementing Web Accessibility Across Organizations and Projects

Shawn: When you sent the new information to Judy, did you include the subtitle?

Kevin: Yes and I included the link to the GitHub

Shawn: I think it would make a difference if she saw the subtitle and the page content.
... so where are people now?

<Andrew> no concerns with 'strategic', especially with subtitle

Sharron: Well, I feel pretty strongly that introducing the concpet of long term startegic planning sets the right tone for this document. I am still strongly in favour of the way it's worded and positioned now. it is a long range plan which is strategic to my point of view. From what others have said, the term "strategic planning" has other connotations, some of them downright painful. But I think the way we've clarified in the subtitle and how it is more clearly referenced throughout the text now, seems to make the concept less likely to be misunderstood.

<Andrew> +1 to keeping title

<paulschantz> +1 to keeping strategic in title, with slight caveat

<shawn> s good

Wayne: I agree with that as well. People in large organizations think of slick people in Italian suits leading stragic planning sessions. We don't want that association and Judy may have had that reaction. But it makes more sense now. Looking at what it is, I am in favor of keeping it.

Paul: The mention of security in the first part was disconcerting. Both security and accessibility would belong in overall strategic planning. I understand where Judy was coming from however. OK with strategic - but need to tweak first paragraph

Shawn: thank you Paul. We have on the agenda to talk about the intro so we will address the reference to security.
... so is the final judgement that you are OK with strategic in the title?

Paul: Yes but we will need to tweek the title

Eric: I really like strategic planning. Most teams ask - where do I start with accessibility. Having a strategic plan leaves no doubt that is what you are doing.

<paulschantz> the word "strategic" elevates the importance of planning for web accessibility

<Andrew> accessibility planning needs to be strategic!

Shawn: We want to encourage people to develop a strategic plan for accessibility. If we make sure that we clarify that we are providing guidance to companies to develop a strategic plan that fits their individual needs. We are NOT providing a full strategic plan - a be all and end all.

Shadi: I was getting more comfortable with the title. It is one thing to say that developers want such a plan and that we want to encourage people to do it. I like the word strategic planning but I understand the lack of confidence that we are actually delivering on that.
... I am happy to reconsider after TPAC, but perhaps put strategic as part of the subtitle. Making it clear that YOU must develop the plan, this document does not do it for you.

Eric: Considerations/Guidance for Strategic Planning of Web Accessibility

<Andrew> strategic - relating to the identification of long-term or overall aims and interests and the means of achieving them (Oxford Dictionary)

Andrew: As I look at definitions of strategic plan, I feel that I am missing something. The title seems clear to me that this in NOT a plan but a guide to delivering a plan.

Shadi: We say consider your long term goals, but we don't say how to identify or define them. Or how to prioritize. Perhaps that is necessary since it is necessary because of the wide context in which it will be used. But there are strategic considerations missing here.

AnnaBelle: The term generally has negative connotations for me. Even when I hear that it is being done well, those outcomes are not usually clear to me. That said, I like this document and the way that it is presented as a power-under rather than power-over approach. It lacks the self-importance that is so often associated with strategic planning
... I like the way we use it.

<Andrew> another definition: Strategic planning is an organization's process of defining its strategy, or direction, and making decisions on allocating its resources to pursue this strategy. It may also extend to control mechanisms for guiding the implementation of the strategy. (Wikipedia)

Kevin: I did not have the chance to talk with Judy but only an email exchange. She said she was concerned with the title "Strategic Plan for Accessiiblity" However, the title is actually "Strategic Planning..." which has a different connotation.

Shadi: I appreciate AnnaBelle's perspective and think it is due for more consideration, perhaps after TPAC

<Andrew> and also: strategic planning - A systematic process of envisioning a desired future, and translating this vision into broadly defined goals or objectives and a sequence of steps to achieve them. (Business Dictionary)

Wayne: I really understand the hesitation with the term. many people have been dragged into a painful process with dubious outcomes. It is a common experience in the US. But I changed my mind when looking at the actual definitions. So I am in favor of putting it up as a draft and seeing what is the response. If the visceral reaction is negative, we can reconsider. I disagree with Shadi that we are not delivering.

<shawn> Planning for Web Accessibility: Guidance for Developing a Strategic Plan for Your Organization or Project

Shawn: To put in context we had two documents "Implementing Web Accessibility...." the other was "Improving...." and it created a great deal of confusion. If we move the word "strategic" to the subtitle...

Andrew: I could live with that as a compromise, but would prefer it in the main title.

Shawn: I'd rather toss out the one that is less likely to get negative reactions. If we put out the alternative, we can see if the reaction is positive enough to put into main title.

Kevin: I think I broadly agree with what most people are saying that this will guide you toward a strategic plan. I am comfortable with the more cautious approach but would prefer it as part of the main title.

Andrew: prefer in the main title, can live with it as subtitle

<Wayne> +main ok with subtitle

Sharron: +1

Paul: +1

Kevin: +1

<yatil> [[Slightly prefers main title as well, but doesn't have strong feelings.]]

Sharron: Here is my thinking. Saying something so generic as "Planning for Web Accessibility" is likely to induce the reaction of yawn and move on. Strategic is a strong word. Sometimes there seems to be a strong negative reaction but the strength of the word itself can be really useful to us in my opinion.

Andrew:I agree that strategic in the main title lifts the title up a level

<shawn> [[ Shawn comfortable with leaving it in main title (and keeping it open to get additional feedback) ]]

Shadi: The question is do we have a gripping title and then the content makes people yawn and move on?
... I prefer the more conservative approach for the reasons we have discussed.

Sharron: That is an excellent point and if we claim "strategic planning" in the title we should be sure to deliver in the content

Wayne: I built a strategic plan for a large organization and most of the steps taken are included here. I have confidence in this as a draft and we can continue to improve and sharpen it.

<shawn> RESOLUTION: Keep current title for now (and check how it flies)

<shawn> another idea: https://www.w3.org/WAI/EO/wiki/Feedback:_Implementation_Plan_for_Web_Accessibility#intro

<shawn> e-mail thread: http://lists.w3.org/Archives/Public/w3c-wai-eo/2014OctDec/0008.html

<shawn> A successful plan for web accessibility addresses many areas of your organization and projects: training, quality assurance, recruiting, purchasing, marketing, content development, visual design, and more.

<shawn> This document provides IT managers, project managers, small business owners, accessibility consultants, and others with guidance on what to consider in developing an effective web accessibility plan for your specific organization or project. When you want more tactical guidance on fixing accessibility barriers in existing websites, see Improving the Accessibility of Your Website.

<shawn> [+] expand all key actions below [-] collapse all key actions below

<shawn> ---

<shawn> Some rationale: * The first sentence gives them an idea of the range of areas to entice them into reading the document -- e.g., "hum, I hadn't thought about [xyz area], I'd better read on to see what I need to think about there." * The subtitle now says "Guidance for" and this intro idea has "guidance on what to consider" which I think is enough to cover the point we wanted to get across. * The

<shawn> [+] expand buttons in this document are all on "Key actions" points, and the first one is just a short paragraph below the buttons (and thus visible in many configuration). Therefore, I think we can change the button text to: "expand all key actions below", "collapse all key actions below" and then not need any extra explanation.

Shawn: Kevin brought up the idea that EO wanted to include the idea that accessiiblity is not a bolt-on or separate activity but seen as an integral part.

<Andrew> like the comparison with security - grabs senior management attention

Shawn: current intro was based on the previous title. With the current title, how does the intro fit?

<paulschantz> has similar implications, too

<Wayne> This document provides IT managers, project managers, small business owners, accessibility consultants, and others with guidance on what to consider in developing an effective long range web accessibility plan for your organization or project. A successful plan addresses many areas of your organization and projects: training, quality assurance, recruiting, purchasing, marketing, content...

<Wayne> ...development, visual design, and more.

Andrew: I like having the comparison to security. I have used that analogy quite a bit in the last few years to get attention, it works well.

Wayne: It looks good if you take the first and append it to the second paragraph, it looks pretty good.

Shawn: How would you includethe idea of security?

Wayne: Well, I think that reference may be too big and profound, so I would leave it out

Shawn: Some people see access by assitive tech as a security risk, so is that enough of a serious issue that we want to avoid bringing it up?

<paulschantz> no

Andrew: My experience is that it is not an issue, it does not become a barrier.

Shawn: It is a belief that by accomodating AT we make sites less secure, are we feeding that belief?

Wayne: We would have to futher explain and may not want to get into those weeds.

<paulschantz> I think this is a red herring. Security and accessibility are often used as a way for people to say "no," exploiting FUD (fear, uncertainty, and doubt)

<Andrew> good point Paul

<paulschantz> don't connect these topics that way

<paulschantz> it's a losing battle

Shadi: I agree with you Wayne. But aren't the typical systems managers and developers already challenged by the bring-your-own device paradigm? So there is already the challenge in place. We must be mindful of the fact that there is sometimes a negative association of AT and security. It may be a good time to bring out the issue and clarify the reality. There are so many devices breaking security in a traditional sense that AT can be seen as just another one of those personalizations and so less threatening.

Paul: Creating a security risk is a red herring. The real issue is that both security and accessibility are used to give people a way to say no. Not wise to associate them.

Eric: I agree with Paul. Could associate instead with performance for example. It is something that must be tested and checked iteratively

Shawn: It seems that security is enough of a concern that we should not refer to it.
... any objections?
... When the title was Implementing, EO felt strongly that we needed to make very clear that this is not a linear process, that it is iterative, that the order is customizable, etc. Is that still a need with the new title?

Wayne: This is not a sequential document. There is much to learn, you may want to redo sections as you learn more throughout the process. As you clarify your plan you WILL go back and change things, etc

Sharron: Why would we not want to let people know they can use it as they wish and would be likely to circle back trhough certain sections?

<Wayne> Tersification

Andrew: It is implicit in the way it is presented. There is no step by step numbering, so people will know that without explicit instruction.

Shawn: Can you fork it to put the other intro in now? We will discuss Andrew's comments on the Policy doc in the meantime.

Developing Policy document

Kevin: Andrew your comment on the Policies document was that you would prefer that at least some of the examples would ask for public feedback.

Andrew: Yes. For example if the policy says "We are attempting to meet WCAG2AA" it should also say if you encounter barriers, here is how to provide feedback.

Kevin: But these examples are not necessarily meant to be public facing. That is not to say that there should not be conformance statements but policy may or may not be public facing.

Andrew: My reading of the wording of some of these suggests public facing however.

Kevin: Would it be good to clarify?

Wayne: Yes there are some of these that could easily be public facing and browsing through the examples, the reader won't know how to distinguish. I thought of these as something you would put on your web site so I think others will have that impression as well.

Kevin: We say there could be a version that is public facing but these are not necessarily meant to be so.

Shadi: I agree with you that policy and public conformance statements are separate things. But I also understand that some people do not see that. So perhaps we need a section that makes that clear "Making Public Statements" or something of that sort. Something to differentiate between policy and public statements.

<Andrew> +1 to future section on public statement on intent

Shadi: given that, even if there is only an internal policy why not suggest a point of contact or feedback pathway?

Andrew: Yes, that public or internal feedback loop should probably be part of the template.
... it would make someone responsible for monitoring the policy impact.

Wayne: Yes, we should clarify the difference between our references to "policy" and any public facing statements about accessibility.

Andrew: The public statement will be a statement of intent rather of conformance

Shawn: The most conservative thing to do is to make what have now to be clearly identified as for internal use and put on the queue the need to make public facing statements.
... so for now, we should simply clarify that this document is talking about internal policy documents.

Andrew: But it could be referenced into the Next Steps section

Sharron: +1

<yatil> +1

<Wayne> +1 just a next step point, no discomfort

Shawn: Any objection to that?

Kevin: I may need to change the subtitle of the section and tweek a bit

Wayne: My interpretation was Next Steps and Maintenence, not a qualifier
... it can stand just as it is, not confusing at all.

Shawn: Didn't we agree that this document needs a statement that it is for internal use only.

Kevin: yes and I could add - this is concerned with internal and you may also need to consider developing external public facing...."

<shawn> This document guides you through topics to consider when creating or updating an internal web accessibility policy. (You may also develop an external statement of intent for accessibility.)

<Andrew> (You may also consider publishing an external statement of intent for accessibility.)

Shawn: Finding previous versions in GitHub?

Shadi: yes, Eric can help you do that.

Kevin: OK this is good and Andrew has also made a suggestion. We will clarify in a sentence or so.

<Wayne> +1

Kevin: will include the word internal in the intro and add a short sentence making the distinction more clear between that in the external statement.
... and I will change the wording of the first example to be clear that it is internal

Shawn: And consider Wayne's formatting comment, that the presentation itself encouraged thinking it was externally presented.

Strategic Plan redux

<shawn> previous intro: http://w3c.github.io/wai-planning-and-implementation/Overview.html

Shawn: Getting back to question of the ongoing, iterative nature of the guidance while keeping it tersified.

<shawn> another idea with new title is here: http://www.w3.org/WAI/EO/Drafts/strategic_planning_intro.html

Wayne: This paragraph is a place for clarity - the introduction - but it is a place for clarity. it takes some words to say it, we want to say it.
... what needs to be communicated is the need fo long term commitment, it identifies elements required for a successful accessibility implementation, it is likely to be iterative and who it is forr.

Andrew: On going implies long-term
... and that is important

<Andrew> I'd like to retain "accessibility is best approached as an intrinsic and ongoing activity" or similar

Kevin: I think that the first paragraph of Shawn's suggestion along with the second sentence of the original might do it. Give the idea that it is a long term consideration.

Shawn: Why "intrinsic?"

AnnaBelle: Yes "intrinsic" doesn't work for me either

Sharron: Maybe "integrated"

<Andrew> intrinsic synonyms: inherent, innate, inborn, inbred, congenital, natural, native, constitutional, built-in, ingrained, deep-rooted, inseparable, permanent, indelible, ineradicable, ineffaceable

Shawn: The other point about the fact that the document itself has evolved, so we need the sentence saying that the order doesn't matter?

Wayne: Not needed

<Andrew> what about "integral"

<scribe> ...ongoing, iterative, integrated

Shawn: Anything else for now?

Sharron: I really like how this has evolved Kevin, good work

AB: Yes, thanks you

Andrew: agreed

<Wayne> Actually, I love the suite.

Shawn: Yes please look at all these, complete the survey

Face to Face Teleconference

Shawn: Who will be available for that teleconference?

<AnnaBelle> I can call in some on 10/27 not 10/28

Wayne: I will be there in person

Shawn:Thanks everyone, please complete the survey as soon as it is feasible to do so. Update your availability for future telconferences, especially for TPAC F2F. Thanks all have a great weekend. Bye.