The meeting began by welcoming new participants to the group. Brent Bakken of Pearson and Reinaldo Ferraz of the Brazilian Network Information Center introduced themselves and were welcomed by all. Shawn began the meeting with a reminder to all to stay current on notifications for your availability to attend teleconferences. Next there was discussion of the comments collected on the progress of the Organizational Policies document. Two major considerations regarding the document were how to address third party content and how to define the scope. With the understanding that the guidance in the document must align with WCAG, a consensus began to emerge to reduce the emphasis on 3rd party content demonstrated in the 2002 version, while maintaining references to it in policy recommendations and beling clear that if a 3rd party tool is required in order to complete a task, it must be inlcuded in policy statements. In considering the two currently offered options for scope definition, the first would focus on web content owned by the organziation with an emphasis on WCAG and only passing mentions of ATAG and UAAG while the second would be broader and include greater consideration of ATAG and UAAG as policy is expanded to include internal tools and browsers. Consensus is emerging for support of the first option, although there is recognition of the need to reference the bigger picture in some way. Consideration was next given to progress on the Dynamic Guide which is in a much earlier stage of development. The group reviewed the analysis of the goals and considered the Dynamic Planning Tool prototype. Suggestions were made for additional task considerations,such as risk analaysis and QA, and general approval was given for the direction of the project development. The group expressed their strong approval of the surveys as a time and task management tool and asked to include the weekly work as a survey. Shawn thanked everyone and asked them to try to complete surveys early - including approval of the publication of the Evaluation Tools list - to allow time for participants to review each others comments.
<shawn> Availability for Upcoming EOWG Teleconferences https://www.w3.org/2002/09/wbs/35532/availability/
shawn: Please make sure you keep that survey current.
<shawn> http://w3c.github.io/wai-planning-and-implementation/pol.html
<shawn> https://www.w3.org/2002/09/wbs/35532/eowg8dec2014/results
shawn: Thanks to the people who filled out the survey. It helps in trying to make the call time more effective. Please answer the survey early in the week so we can collect thoughts before the call.
<shawn> Subtopic: 3. Policies doc: Third-Party Content
shawn: 2002 document had a lot of information on 3rd party content, especially educating providers for 3rd party content. Nowadays more people know about accessibility, so should look at how to address this. Kevin drafted a new wording. Context: We have a document that guides people to what their accessibility policies may say.
... Some comments on the reality of the situation, how does this impact what we want to say in the policies document?
<shawn> latest draft: Your organizational policy should clearly identify what website content it will cover to. Consider to what extent the policy will cover new, updated, and existing web content, and also any third-party provided content.
<shawn> Other considerations: Where you have legacy content, consider how the policy covers new, updated, and existing content.
<shawn> If you have web content or code supplied by third-parties, consider how the policy applies to them.
<shawn> example: This policy applies to all web content produced or updated by ACME Inc. In addition, ACME Inc. will ensure third-party content providers are aware of our web accessibility policy. ACME Inc. will also preferentially select providers based on their accessibility conformance claims.
Lydia: Policies for 3rd parties are very important in higher ed.
... We tell them what our policy is and we tell them that they need to provide an accessible product/service.
shawn: One approach is that the policy is "everything is accessible", 3rd party content included.
kevin: If that is a legal policy and 3rd parties are not mentioned, they may be not covered. But I'm not a lawyer.
shawn: Other thoughts about the current wording?
Lydia: First one very simple, to the point. Second one may be to broad, sometimes the resources are quite limited. Several colleges may not be aware what it takes to make 3rd party content accessible. Selecting 3rd party based on conformance claims seems hard.
shawn: Is this, in general, the level of coverage for 3rd party content?
Wayne: This may have a large push-back in higher ed.
shawn: We need to find a balance between ideal and realistic.
Paul: We experience this all the time. For example with elearning software, where an inaccessible platform was chosen. If the 3rd party tool needs to be used to complete a task, it should be covered by the policy.
<shadi> +1 to Paul
<shadi> [ in case it has not been discussed, we need to make sure that the advice in this document is aligned with corresponding WCAG 2.0 conformance requirements ]
<shawn> QUESTION: model policy vs example (ideal vs. realistic)
AnnaBelle: Model vs. Example, I probably would expect a model policy instead of examples.
<Wayne> Some wording: If the content effects participation in essential functions of the institution then it must meet accessibility policy.
shawn: Anything else on this for now?
Subtopic: Scope
<shawn> https://www.w3.org/2002/09/wbs/35532/eowg8dec2014/results#xq1
shawn: Two options for scope: (1) Focus on an organization's web content (sites, apps,...). WCAG focus, mention of ATAG and UAAG. Procuring tools for internal use wouldn't be included in the document.
... (2) Broader, including ATAG and UAAG, would include developing internal tools and browsers.mMost people seem to be leaning to option (1).
Lydia: Leaned to (1) but after re-read (2) might help organizations to be better with accessibility. But the details may quickly become outdated.
shawn: Document wouldn't talk about specific tools, only what guidelines to target.
Wayne: Lot of web apps are internal facing. For example CMS that have their UI through the web, probably the question was not split at the right point.And internal facing web apps needs to be accessible.
shawn: It could be "web content provided internally" as well for option (1).
Jonathan: That was one reason why I selected option (2), it might also have a more overarching impact, for example on 3rd party content providers. People who might look at policies might say "this is not web stuff", if ATAG/UAAG are not covered well.
<Wayne> +1
shawn: Focus of the document is organizations that develop an internal policy.
Lydia: Including it separately would help people to include tools easier into the policy. It makes it much more clear.
shadi: there are actually two questions: Scope: Is it guidance on (a) web content accessibility or (b) on web accessibility. And how we address that.
... Speaking of scope: The strategic planning document that talks about how to get accessibility throughout the org. Policies are a central theme in that. So it would make sense that this policy document covers what is addressed in the strategic planning document.
Wayne: I agree with Shadi, the employee part of the accessibility documents seems to be missing. In many organizations they think someone with a disability can't do a certain scope. It should be part of the scope.
<Wayne> I really like the the surveys.
<Jonathan> 1. Web Accessibility Broadly. 2. In the least snooty way possible.
shawn: If we look at a level above: Do we want to cover (a) Web Content Accessibility OR (b) Web Accessibility?
<paulschantz> +1 for option a web content only
shadi: Maybe there are three options: (aa) Just speak about Web Content, (bb) web content + some general web accessibility guidance, (cc) bb + detailed guidance on web accessibility.
Paul: I'm for web content only.
<Wayne> (a) with the caveat all web content (internally and externally facing)
Lydia: I would like to have more guidance on general web accessibility.
<Jan> +1 for option a
shawn: Generally WAI provides information on web accessibility broadly, this document may focus only on web content accessibility.
AnnaBelle: I was afraid that option 2 means we need years to put that document out. I'm still not sure. But now I'm thinking option 2 may be more efficient as well as effective
Lydia: If we only talk about web content, people may forget about tools and other factors.
Jan: Option 1, I think other things are covered in other places. But if other things are not included, it might not be taken seriously.
shadi: (aa) Would talk only about web content. (bb) Would mention that there are things to look at. (cc) Giving guidance on how to implement this in the policy.
Jonathan: I wonder if there is a way to compromise by somewhat blending the bb and cc. It seems there are two extremes: Focus and be quick or broaden and add complexity.
shawn: Straw proposal: This document covers web accessibility broadly, with two different sections, one talks web content policy and one that talks about other general topics that might be included in policies.
Jonathan:re: scope - how about how those other policies have to do with web stuff
Wayne: It depends on the scope of the second part. I tend to agree but we need a discussion on how to scope this part.
<shadi> [ and obviously 10 years was an exaggeration :) ]
<shadi> +1 to Jon to not lose focus from web content
Jonathan: We need to cover how other policies do affect the policy, we need to make sure that the baseline is WCAG.
AnnaBelle: So what is the perspective of Kevin and Shadi?
<shawn> [ Kevin, Shadi take off objective hat to share individual perspectives :-]
Kevin: I think the document needs to refer to something like that, it is important to reference it. Readers need to consider it.
Shadi: I feel strongly to put this document in the context of the larger picture. It's always idealistic vs. realistic. I want to explain the bigger picture, even if some people won't do it.
Wayne: People tend to forget to be more inclusive in policy as they don't think where accessibility is useful.
shawn: I think the document should cover ATAG/UAAG, I think it would be separate policies in the end.
shadi: So do we need to change the title?
shawn: No.
... Thanks for the survey. It was good to get initial thoughts in the survey and follow up in the meeting. Surveys help to share ideas in advance.
<Jonathan> I REALLY like the survey
Eric:Like the survey as well!
<Jonathan> As we don't share screens for context, I find this to be a very helpful way to keep track of things.
<AnnaBelle> I really like surveys too
Lydia: Like it, was more streamlined, could focus better.
Wayne: To have a few focused questions is really helpful.
<AnnaBelle> I like overt and implicit prioritization of the surveys
Lydia: Could we add the work of the week to the surveys as well?
<Eric>+1
<kevin> +1
shawn: The issue is the timing.
Lydia: I'd like to have everything in one place, not getting back and forth. Questions like "have you read this...?".
EricE: I think we could add questions during the week.
shawn: What do you think? OK?
Wayne: I'd look on Monday and Wednesday evening, that should cover 90% of the cases.
Jonathan: Shall we just try it out?
shawn: Let's try it.It is good that we refine how to work as a group.
shawn: The policies document is pretty well along, this project is the opposite, we are in the early phase and try to work out what this might be. This is a working handle for the project title, and it may change.
... Now is the time to think about what users need, users are project manager type, generally less technical people. Broadly project management-like tasks. We had once thought about having this as a dynamic access to the strategic planning document but now it may become much broader.
... Last week's personas discussion indicated that we may need more information than in the strategic planning document. Any questions?
<Jonathan> When you say "dynamic" do you mean interactivity? Or do you mean something more esoteric?
<shawn> content analysis https://www.w3.org/WAI/EO/wiki/Planning/Content_Analysis
shawn: We don't know yet, it is very open at the moment.
<Jonathan> ok
shawn:could be regarded as more of a placeholder word. To give you an idea of what is in the content analysis document. Kevin collected documents and how they might relate to PM types.
...the second part of the document shows tasks and how well the resource supports specific personas.
Kevin: The first part of the document doesn't say anything on how the document applies to PM types, those are only desciptions.
<Jonathan> wow
Lydia: Would the document also include QA?
shawn: Only on a project management level, let's take a look when the resource shapes up. Kevin created a rough concept idea sketch.
<shawn> http://www.w3.org/WAI/EO/Drafts/planning/prototype/home.html
shawn:He is using a task based approach, filtering options that would change the tasks shown below. Reactions?
AnnaBelle: I like that it is quite dynamic, it seems less intimidating.
Brent: Accessibility pages are often overwhelming, it is good that this gives them a place to start.I like that they can start with and then develop it further out.
shawn: Some people are just getting started, other may want to read a bunch of stuff to get going. Others have a certain task to do. We want this to cover all of those use cases.
Kevin: People who are generally not aware of accessibility are in my head as well.
Jan: This is what we're dealing with where I work.
Jonathan: I am currently helping creative and development departments translate policy to practice, I am happy to share the problems and situations that tend to come up when dealing with this material.
shawn: Jump over to the personas and let's think about the tasks.
Subtopic: Tasks for Personas
<shawn> https://www.w3.org/WAI/EO/wiki/Planning/Personas
Kevin: Let's go through personas and try to add additional tasks to the personas.
... Cedric is a development manager, technically competent and has a team of developers. Needs to do design briefings. What else may he need to do? Lydia, you mentioned QA earlier.
... anything in the QA process that those people might be doing?
Lydia:We had to address the risk analysis.
Kevin: Is that something that a development manager needs to do?
Lydia: Yes.
<Wayne> +1 risk analysis
Lydia: I like how the tasks fit to the role, I think that developing risk analysis should be in those tasks.
Jan: I agree.
<Wayne> develop coordinated, dynamic process to address implementing accessibility
... development managers need to understand the legal risks.
<Jonathan> +1 process
Wayne: Process is important so it might be the right place to assign some responsibilities. Raising awareness and keep people moving.
Kevin: Do we need to split process up?
Wayne: I think that this is a possibility. Need to think about this more.
Jan: Development managers have a huge power to assign specific tasks (like adjusting contrast) and they need to be aware of that.
Kevin: Hibah and Megumi are more broadly working on understanding accessibility and organizational change. What else could they doing?
... Setting up a specific accessibility team?
Lydia: Ensure testing would be done in phases during the entire creation cycle. Not just testing at the end.
Kevin: So having checkpoints throughout the project. Others?
<Jan> General Comment: In the age of "Universal Design for Learning" (UDL) in the educational field, I think that we need to be careful about using language that says "building accessibility in ...." The APIP standard for high stakes assessment is rooted in UDL and the basic premise of APIP is to have "accommodations" in the system that would eliminate the need for assistive technology. This is not a good model for students who rely on the use of third party AT. I would recommend changing any language that refers to "building accessibility in" to something like "meeting accessibility requirements ... etc."
Jonathan: Another important aspect is what to do if something doesn't fit what is required by accessibility.
Jan: Tracking where things are is a big problem in addition of Q and A.
Kevin: Like a tracking matrix of accessibility?
Jonathan: That is a part of that. Also important to figure out what is needed in the planning phase.
Reinaldo: One thing: It is important to consider for managers to put accessibility skills on the development team.
Kevin: Matt is an intranet manager, anything specific what he should do?
Lydia: There might be no persona for other roles like people who actually do it and it may be helpful to add that.
Kevin: We looked at who does the planning, how do they affect change.
Shawn: Initially the scope was on a higher level, but we can think about lower levels as well. We narrowed down the personas list and we don't really plan to add more.
Lydia: Development managers may also work with users directly. Maybe a task is learn how to explain accessibility.
Kevin: It's like an internal business case.
shawn: Personas+Tasks are all in the wiki you may want to add that yourself. It is a wiki, add whatever you want. We may discuss that and archive it, but feel free to edit... other comments?
<shawn> Reminder: Eval Tools List - review recent changes and make sure you're OK with publishing this as done
<shawn> http://lists.w3.org/Archives/Public/w3c-wai-eo/2014OctDec/0047.html
shawn: We think we're done with it. Make sure you're comfortable with what we have. If you have comments, share them asap. We want to put it out next week.
... Any other comments on how we can improve? Feel free to share that with Sharron and me! Thanks everyone, watch for a new survey and we will see you next week!