<trackbot> Date: 16 October 2015

<scribe> Scribe: Sharron

Showcase examples

<shadi> https://www.w3.org/2002/09/wbs/35532/EOWG-ShowcaseExamples2/results

<yatil> Responders: Anna Belle Leiserson, Melody Ma, Sharron Rush, David Berman, Brent Bakken, George Heake, James Green, Kevin White, Eric Eggert, Shawn Henry, Vicki Menezes Miller, Howard Kramer, Andrew Arch, Adina (via E-Mail)

Brent: We received survey results, thanks to everyone who responded - we appreciate all of your input. Response from EO participants inlcuding Adina who is participating only in this Task Force. Adina sent comments outside the survey.
... thanks especially to James and others who put extensive comments in the wiki. Have reserved a weekly time to meet. So far it is just Shadi, Adina, and me and we are recruiting other participants who will work on edits to the document. We will bring back our updates as we make progress. Just wanted to say thanks to everyone...anything else Shadi?

Shadi: It looks like we have agreement about what we are covering, some comments about approach, really appreciate all the useful feedback.

WCAG2 Errata

<shawn> http://www.w3.org/TR/WCAG20/

<shawn> http://www.w3.org/WAI/WCAG20/errata/

Shawn: As I understand it, if you go to the URL above, you come to the Guidelines, dated Dec 11, 2008. Below that is a link to the errata. Currently there are only editorially fixes, not substantive errata.
... WCAG-WG is discussing updating WCAG2 to incorporate the errata. The result of that would be an "edited Recommendation" with a new date.
... I wanted to get EO's feedback about how that would land. Anyone have insights about pros and cons, messaging, outreach, etc?

David: May be beyond scope but I have often found it frustrating that there are things untrue or "future links" that never seem to appear. Have inquired with no response. Are these kinds of things in scope for this? I have experienced it and heard from others. Is this an opportunity for improvement of that?

Shawn: This is only WCAG2 itself, not the Techniques documents. You are in fact *encouraged* to provide information to update and refine the Techniques.

<kevin> http://www.w3.org/WAI/WCAG20/comments/

David: is the participation in EO likely to bring more attention to my comments?

Shawn: Anyone can comment.
... back to the issue, what are the repercussions of integrating the errata into a newly published, edited WCAG?

James: I think it has the potential to be confusing. A new date may make people think there have been real edits, beyond errata.

Brent: if the distinction is not made that it was only the errata that is being addressed, it could cause panic. Can see people painstakingly going through every SC to see what has changed. Is there a way to indicate that it was only an editorial pass to address errata?

David: I agree with Brent. Since people use this for conformance, I think that it could cause significant confusion.

Brent: I do think it should be updated and the errata incorporated. It is not useful to have the errata as a separate statement. It should be done but only with a clear indication that it was an editorial errata only.

Kevin: Is there intended to be a change log that shows what changes have been made?

Shawn: That leads to the next question of what can we (WCAG-WG with EO support) do within the document itself to make that clear. So if we assume it is to be done, what are your ideas on how we might present that?

James: There is a standard way of showing diffs on W3C, am I right?

Shawn: Yes
... if you have any other thought about pros, cons, how to do an effective outreach, how we might minimize negative reaction, increase positive reaction, please submit those thoughts. We have a related questions on the survey.

Quick Ref redesign

<yatil> http://w3c.github.io/wai-wcag-quickref/

<yatil> Responders: Kevin White, David Berman, Sharron Rush, Melody Ma, George Heake, James Green, Eric Eggert, Shawn Henry, Brent Bakken, Vicki Menezes Miller, Howard Kramer

Eric: How to Meet WCAG2, the customizable interface to WCAG, is progressing. I have tried to make the experience easier to follow, created a way to deactivate the yellow highlight. There were some very interesting comments, particularly in response to the filtering, design thinking about what has/has not been selected. Have been experimenting with a few approaches and will bring them next time. The yellow flash was commented upon and other small issues that I am working to address. There was good feedback to the browser issues which I am working on. Two big things were the tagging issues and intro messaging.

<yatil> https://github.com/w3c/wai-wcag-quickref/issues/27

<yatil> https://github.com/w3c/wai-wcag-quickref/issues/28

<yatil> https://github.com/w3c/wai-wcag-quickref/issues/28#issuecomment-148341106

<shawn> ^^^ new proposal

scribe: many thoughts were put forward that I must process. The feedback was straightforward and I must simply process and prioritize. The tagging question is less straightforward. There are a lot of things going on there and a really good discussion. I took the input and made a new proposal for tags which is now in GitHUb.
... there is still open the question of the tag "compatibility" which has two SCs currently related to it. We had good proposals to move things into other categories to remove those complex terms. We need to think about a word that fits the concept and relates to the SC more intuitively. I am looking forward to your ideas.

Shawn: We will spend some time on the call now to discuss what to do with compatibility.

Brent: For clarification, why is compatibility an issue? Because it is obscure?

<shawn> [ /me looks at WCAG 2 at a glance... Robust: Maximize compatibility with current and future user tools. ]

Brent: is it because we want the tags to be just one word? Is the issue not to have a phrase? What truly is the issue?

Eric: It is the fact that it is an abstract word and not likely to be a common term that people will think about.

David: I was more concerned about the word itself. Since WCAG uses "robust" why not use that term?

Eric: The Principle is Robust, and the SC says compatibility.

<shawn> Guideline 4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies.

David: Fair enough, but when you use that term with students, they think of browser compatibility.

Sharron:Well, it is not like the engine has to match search terms. We are not depenednet on what people will think of themselves but how well the SCs map to the tags we present to them. Becasue the term aligns with the same word in the guidelines - then it seems OK to use it. Understanding it maight be hard for some, but it's a 1-to-1 match with the guideline and SC.

<davidberman> I hereby step away from my position on "robust". You guys have changed my mind.

Vicki: I wouold not search or look for more about Robust. Compatibility would be closer.

James: I agree, I am not a fan of Robust, particularly with a learning audience, it would not resonate.

James: we may not find one that is perfect, but compatibility is closer.

David: I am convinced. I can let go of Robust but hope we can find a third word.

Sharron: I agree with David to find a better word than either one.

<kevin> +1 to explore other options

Shawn: Markup, coding...other brainstorms?

<kevin> cross-platform

David: Reliability

Vicki: Validation

Sharron: adaptability

Shadi: +1 to validation

<kevin> Resilience

<davidberman> +1 on "validation"

<davidberman> +1 on "resilience"

Shadi: The two SCs we are looking for relate to syntax

<kevin> Versatility

<yatil> syntax

<James> Code

David: Like resilience because it says "robust" in a more clear way. Also like validation.

James: Part of the problem is that validation is good for parsing, but not so good for name role value. Finally I land back on compatibility or code - both encompass both of the guidelines we are trying to point to.

Shawn: WCAG conformance does not in fact require valid code. It could reaggravate that debate.

Howard: What exactly is it that we are trying to do?

Sharron: A tag that will lead people to 4.1 and 4.2

Brent: I like compatibility best, especially after reading the SCs themselves.
... to me it is making content compatible to assistive technology.

<James> +1

<shawn> 1

Brent: a person may not understand the terms within the tags list, but it will become clear once they use it.

James: I move we stay with compatibility unless others have further objection.

<davidberman> +1 for "compatibility"

<shadi> +1

<Howard> +1

Shawn: Straw proposal: leave as compatibility. Eric it wouldnot be a big deal to change the term in the next few weeks would it?

Eric: No

Kevin: How flexible will we be going forward, once it is published? Could we add tags or change them?

<yatil> https://github.com/w3c/wai-wcag-quickref/blob/gh-pages/_data/tags-sc.yml

Eric: We can change later on once approved by the group.

RESOLUTION: Retain the term "compatibility" until and unless someone has a viable (brilliant) alternative before publication.

Quick Ref: Tagging activities

Shawn: Originally was an idea that we could filter by task or activity, had that function in an earlier prototype, but it has not been used in recent prototypes. Now the issue has come up again in the review of the tags.

<yatil> https://github.com/w3c/wai-wcag-quickref/issues/28#issuecomment-146147991

Eric: Kevin's comment mentioned activities tags as a possiblity. The thought was that, among other useful attributes, that approach would reinforce the activity groups from the Getting Started Tips. As I thought about it, it seemed difficult to have SCs that map directly and clearly to activities.
... it seems people are quite interested in the activities approach. There are advantages and disadvantages to the approach. It may be easier for people to relate if they have a specific role. The disadvantage however is that the taxonomy is not so clear and correlating all of the SCs to the activity can be confusing. So we would need to grey out things like "compatibility" for a designer, for example.
... people will have to realize that there are two sets of tags - taxonomy for activity and for specific accessibility features or topics.

Howard: You mean the role of the user when you say "activity," like we did in the Getting Started?

Eric: Exactly

David: I love this idea of filtering by activity.

Shawn: We should give consideration to the fact that it adds complexity to the interface.

David: In other cases where we have filtering, it is a pleasant experience.

Sharron:What filter mechanism are you referencing, David?

Howard: Similar to David's perspective, considering the interface at the AccessIQ page, you might find what you are looking for relevant to your role
... were you thinking of the categories in the GSTips?

Eric: Yes, but I am not sure it is possible to tag all of the Techniques using that filtering system. So we may need to tag only the SC since the techniques may not map to the role.

Howard: Could you use the term audience instead of activity and maybe use the AccessIQ map as a place to start?

Shawn: We have some role-based work we have done in WAI-Engage when Denis Boudreau was in EO.

<shawn> http://www.w3.org/community/wai-engage/wiki/Accessibility_Responsibility_Breakdown

Shawn: was started in EO, moved it over to WAI-Engage hoping for more and broader input.

<yatil> Kevin's approach

<davidberman> I was not referring to relatively-complex filter system on the the /ER/tools

Shawn: AccessIQ is related to Media Access Australia is a W3C member, so we could use all of these resources for input but it would require focused work on the part of EO volunteers to develop and polish.

David: One of the documents is the checkbox that customizes what you see.

Sharron: The old QuickRef?

David: Yes, if we could use a series of checkboxes along with a role, and get a customized view, that would work

<Brent> http://www.w3.org/WAI/WCAG20/quickref/

Shawn: Is the difference only that it be a checkbox rather than a button?
... currently the prototype had both. If we chose to filter by tasks/activities/roles it could be presented as checkbox or as button.

David: Was thinking that a checkbox for tasks/activities/roles would subsume the tags and then the two types of filters would not be confused.

Shawn: The complexities that are introduced require us to think about the importance of making the filtering process very clear "You can select to filter by activity or by topics, but not both."
... we must decide what will be most useful along with consideration of the complexity or the interface.
... doing either/or might be less complex, easier to understand.

Shadi: Are you asking about the complexity of coding if both are presented for the user to choose, or are you saying EO should choose only one approach?

Shawn: Do we want to offer that a user can choose from two ways to filter, or do we want to choose only one way to present it and stick to it?

Shawn: it sounds like there is a lot of support for filtering by activities/roles. If we decide to pursue it we need to decide how to pursue it.

Shadi: are we saying in addition to the other?

Shawn: Not yet

Shadi: No one that I have heard has suggested to replace the topics tags with activities tags.

Eric: We need to think about what a user would expect to happen. So if I choose by activity, I will no longer be able to choose a topic tag like alt text and vice versa. If I begin choosing topic, the roles will go away.
... if so, that is quite complex but doable.

Brent: Could you choose to filter by topic or by activity. Once that choice is made, only the relelvant buttons would display.

Brent: what Eric suggested is even more powerful. If someone wanted to look at video but only the design aspect and was able to filter for that, it would be helpful.

Shawn: Big issue is that we do not have a taxonomy for this yet. Sharron and AnnaBelle are working on this.
... is anyone else able to work on that?

Vicki: I would

David: I would

Shawn: The conclusion is that there is a lot of support for activities/roles filters. There are questions about complexity of interface and having a solid taxonomy would be a requirement for that.

RESOLUTION: Explore the development of a functionality of introducing activites filters dependent on the creation of a workable taxonomy.

Shadi: Let's get a timeline for when that might be ready so we can integrate with the production schedule.

Sharron: Will do

Planning and Managing suite of documents

<shawn> https://www.w3.org/WAI/EO/wiki/Planning/Background#Approach

Shawn: The general approach is the same but there is a bit more information so let's take a quick reading break to be sure we all have same info

Kevin: We have three existing docs and one in development. The recommendation is that the Roadmap replaces the Strategic document and does even more. The Roadmap is more expansive, has value for a broader audience and I want to be sure this approach is fine with all. There are overlaps between some documents that should be considered.
... the policies doc is referred to from other planning documents but as a separate topic without much overlap. The question is whether this is a reasonable approach. Shall we move forward with the Roadmap with that assumption. There is also the question of how these relate to the Tip for Managing that should be kept in the back of your mind. How the Managing Tips might support them.

<shawn> Sharron: If there is good material to reference, then it would be easy to write Tips.

Shadi: Question is also what the expectations are in terms of what level of detail. The Planning docs are meant to be high level. The scope question is how much we assume the Planning docs will contain detail.

Shawn: Remember this was originally called a dynamic guide. The point is that if this is developed well enough with progressive disclosure, then we might not need Getting Started Tips for Managing...
... the idea was not to create new content but to make it easier to use existing content.

Shadi: The question on the table is whether there is concern with replacing the Strategy doc with this dynamic planning Roadmap "widget?"

Shawn: Where are people on this question?

Brent: Is the purpose to streamline the number of documents or is it to replace old material with new?

Shadi: We have many of these resources already such as Implementation Plan with good content that is not presented in a particularly engaging way. There are overlaps, common audiences, and we learned that many people have trouble finding what they need.
... this Roadmap has a broader audience since it will point people to the content that is most useful to their specific needs. This project may result in a reduction in the numbr of docs but will certainly guide people more easily to the specific information they need.

Howard: Will the Strategic Planning document disappear once the RoadMap tool is published?
... the RoadMap is much easier to work with and is a great improvement. The interface is much more useful.

<shawn> [ shawn wants one long doc with everything (even if don't print) ! ]

Shadi: Yes what is currently called Strategic Planning will be replaced with what is currently called Roadmap. You would still be able to get the long document on one page for printing or whatever, but this would be the way to present.

David: I support all of this but have concerns that the word Roadmap is not as precise as Planning. A Roadmap is very high level. There are nitty gritty details here that are not captured with this title.

Shadi: We will be discussing the title later on, it is an open issue.
... it is a question as well how this relates to the Improving document. For Policies, it is a separate path. The more interesting question is the relationship to Improving. While there is an alignment, it would be challenging to inlcude them both. For someone who just needs immediate rescue, there is a slightly different approach than the planning.
... so the proposal is to keep Improving as well as a separate doc rather than try to incorporate it. And add a pointer to resources supporting a plan for the longer term.
... So what we are seeking is approval of the approach.

Shawn: To further clarify, now is the time to craft the approach. We will not want to change that later on.

Shawn: To summarize the proposed approach: We will have three main documents - the first (final title to be determined) will encompass a format like the Roadmap and the content of Strategic Planning. 2nd would be Improving with no significant change other than updating references. 3rd would be the Policies draft, may need minor tweaks as well. Last to be determined is if we still want a GSTip on Managing.

Vicki: I support it as long as all of the content of Strategy is included and there is an option for one long document.

David: I support the three documents as described and request that there is a mother document that points to the others as long as there is a structure or tree from a parent document.

Shawn: Other questions or concerns?

Howard: The one being phased out is the Strategic Planning and the others will be pointed to?

Shawn: Not phased out as much as updated, reformatted and made more useful.

<shawn> vicki +1

<James> +1

<Brent> +1

<Howard> +1

<davidberman> David seconds

<davidberman> +1

RESOLUTION: Three documents (and a possible GSTip on Managing) will comprise the suite of Planning and Mangaging: A newly formatted Roadmap with content from Strategic Planning, the current Improving (with minor tweaks), and the current Policy (with minor tweaks.)

<davidberman> +1

<davidberman> bye to all!

Shawn: Please put your thoughts in the survey about the WCAG2 errata, watch the wiki, thanks for all your help and input. Have a great weekend