Planning and Managing - Add in a "Do" activity

Brent: Really a lot of feedback in the survey last week, thanks to all.

Kevin: A number of things we have looked at.
... big picture
... repetition in sustain seems ok, no issues from that
... I have reached out to individuals for clarification and discussion

Kevin: more information and related activities: Suggestions to change the layout, vickiput in lots of resources and I need to implement and check on those.

Kevin: Checking and implementing Vicki's suggestion, if anyone has additional ideas for related materials in WAI resources, please flag those.
... also have a huge set of comments about the expand/collapse but first will look at big picture comments
... Brent's comments about the lack of content around the activity of actually doing the accessibility work. Draft is here

<kevin> http://w3c.github.io/wai-dynamic-planning/implement/#perform-accessibility-tasks

<AnnaBelle> no objections. great idea!

Brent: if there are no concerns about adding this activity, we can look at the wording more carefully later on.

David: No objection to adding this, good ID of the lack of this activity.

<George> no objections

<shawn> +1 to including something like this. +1 to editing wording. +1 to additional resources - at least WCAG Overview I think

Brent: there being no objections, I encourage people to look more carefully and feel free to wordsmith. We put this together quickly so it may need tersification etc.

Shawn: If this is about doing it, should it not have a link to the WCAG Overview?

Sharron: Yes agreed it may have dropped out when being migrated.

Brent: OK we will look at that, any other comments?

Planning and Managing - Expand/Collapse or not?

Kevin: A bit of discussion around the presentation of the pages - expand/collapse or not. The survey was fairly evenly spread across the options. I have updated the Initiate page so it looks a bit cleaner than previously. The hope is that people would read the rationales that were offered for both points of view and then decide which way to go.

<shawn> survey results:

<shawn> updated with expand-collapse: http://w3c.github.io/wai-dynamic-planning/initiate/

<shawn> no expand-collapse: http://w3c.github.io/wai-dynamic-planning/plan/

Brent: Not sure that people had the opportunity to do that, so we may need to let folks consider the tweeks to the Initiate page. The two versions have changed a bit. We can take a bit of time for everyone to review people's rationale and understand both perspectives. Let's take a few minutes for review.

<shawn> [ Shawn thinks it's interesting that Sylvie - a screen reader user - says "No preference, both work fine." ]

Brent: Good rationale for both points of view and now we need to come to consensus. So let's open the floor for discussion and see if we can find one position that we all can at least "live with" for the first release. Have a slight perference for expand/collapse which we will call option 1.

<davidberman> It is possible to reach consensus without all agreeing. For example, I have stated that I will not block consensus on this issue.

AnnaBelle: I imagine we will not reach consensus based on people's strong preference. Can we simply go with majority vote?

Brent: As long as as those in the minority agree

Shawn: I appreciate your bringing that up, thank you. To clarify, the minority can say, this is my preference but I am willing to accept the decision of the group to do something else.
... I think it is good to maintain that distinction and express the preference strongly but still not hold up the decision of the groups.

David: It is actually quite normal to say I have another opinion but will not block consensus. It is cool, we can reach consensus even if we do not agree.

Brent: Thanks David, so keep in mind that if you are OK with the majority opinion, it actually is consensus. At the same time, I do not want for people to feel they must fold under pressure. Open for discussion

David: The tradeoff between printed version and expand/collapse. You must have a separate print version that creates a burden on the developer and the user to get a clean copy without iconography of expand/collapse

Shawn: Not so much - the user can just expand all and print?

David: Icon?

Shawn: Yes, just a few buttons

David: And I guess that way you could expand and print only those you think are relelvant.

<shawn> +lots to David -- with expand-collapse, the user could expand *some* and then print it -- that seems to be a big PLUS

James: I primarily think expand/collapse is most valuable in the mobile view. On desktop, seems less so. I used the inpage link as a way to make up for not having E/C. I am *really* suggesting usability testing becasue the division is so close.
... may make people feel better about their decision.

Sharron: My expectation is that user testing will show a division pretty evenly divided as well

<shawn> +1 to Sharron - users will have the same division

Shawn: David's point kind of tipped me into a stronger support of E/C since it gives more flexibility to print only what they want.

<davidberman> Epiphany!

<shawn> [ Shawn wonders if having expand-collapse only on mobile adds noteable development time ]

AnnaBelle: To summarize the one-page approach I would list these things - it is a usability issue. What people say they like often does not match whatthey do. I am guessing, from Nielsen's work that the buttons add complexity and clutter. Adds at least one more click to get information. Without user data, I am strongly of the opinion that simplicity is best.

Eric: My experience is the same. We have put the user on one page to allow them to have all the information and then re-introduced the need to click by having expand/collapse. The simplest is the best. People will print and I am not convinced that the expand/collapse is so useful for that. I feel strongly in favor of the simple route but won't block majority.

David: Nothing to add except the power of the epiphany of the consensus discussion.

Brent: I was originally in favor of expand/collapse but in trying to do the Big Picture work, I became quickly irritated by having to expand each section. However, now that I think about it, that may not be the most common use case. The expand section to print arguement is also convincing. The idea that the buttons complicate the page should not be the issue since we have used it in other materials.
... the issue is whether there is enough content to warrant the use of the E/C button
... these pages did not seem to have enough content to justify it but I am falling right in the middle and wish I could vote for "either" of the above.

James: I feel pretty strongly that we do not need E/C on desktop but on a smaller viewport, it is so dense it makes me say I do not even want to read this.
... if we could have two versions for mobile and desktp

Sharron:Not sure that the slight preference for not needing it on desktop justifies the extra effort to make two versions. It is a serious extra effort. Would be much better off to figure out one way that we can all live with, and not try to to two. In general I do not prefer expand-collapse. I am a lover of text, walls of text are home to me. But in this case - because these are activities related in a process - to have it so you can see those relations are visually reinforced is good. You see all of them and their short summary before you go into the detail. It gives people the clear idea that these are related activities, not just a long list of text where the headings are buried. The related activities are titled and have short explanatory phrases and in some cases you see all or most above the fold. For me that is valuable. (and I think Howard made that point, too)

Howard: Yes, because this is a process and the steps have relation, it is useful to see them all at once. It is a presentation that is distinct from something more linear like a tutorial, but I would be pleased to defer to the results of user testing.

Brent: Anyone else want to add arguement for Option 1, the inclusion of E/C?

George: It was so much easier to look at on phone and tablet, and the desktop provides logical grouping of the categories. As far as keeping it simple, I feel that the E/C does simplify how it is presented.

Shawn: For me it allows a user to choose how they want to look at it - all expanded, or only sections. The minor additional element of the E/C controls is totally worth the ability to give the users that much choice in how they interact with the material. The functionality is worth the small degree of added complexity.

Brent: Any other comments that need to be heard before we try to get to consensus?

AnnaBelle: I would note that typically the last word has more weight, so I would want the group to know that I am appreciative of other points of view and still come back to the fact that we need user testing. Without the data from a test, we should come back to simplicity - not to give the user another task to get to the information he or she is seeking.

Brent: Is there anyone who is so strongly opposed that they will not accept another decision?

All: No opposition strong enough to block consensus

Brent: That being the case, we are OK with accepting the majority view. After hearing all the comments, you may have changed your mind, you may be on the fence, I would like to proceed as follows:

Brent: if you still prefer E/C, type "Option1" in IRC. If prefer one page, type "option2," and if you are on the fence, type "fence"

<George> Option 1

<davidberman> option 2

<Howard> option 1

<AnnaBelle> option 2

<Sharron> option1

<shadi> on the fence (option 0)

<Brent> On the Fence

<shawn> option 1

<kevin> On the fence

<yatil> Option 2

<James> Option 1

Brent: Tally shows that on the call, it is 5 for option 1, 3 for option 2, and 3 on the fence.
... survey result does not change the majority.

Brent: Based on what we said earlier, we will accept option 1, it will go out for public review and we can revise later if needed.

RESOLUTION: The Planning and Managing Accessibility resource will use expand/collapse in presentation of the activities.

Brent: I greatly appreciate everyone's willingness to spend time on this and to come to consensus.

Kevin: OK so the last thing I needed to talk about was the re-introduction of a couple of docs we worked on earlier this year,

Re-introduction of earlier work

Kevin: One is a policies document inlcuding some simple examples of how you might create policy statements.

<kevin> http://w3c.github.io/wai-planning-and-implementation/pol

Kevin: needs to be thoroughly reviewed to get out of draft. The other is Improving the Accessiiblity of your Website and trying to integrate accessiiblity. More tactical, also in draft state and needs review and revision to get out of draft.

<kevin> http://w3c.github.io/wai-planning-and-implementation/improving

Kevin: both reference the Planning and Managing Guide and are also referenced from within that resource. These will be on the survey for your review this week. Any questions?

Brent: The question was whether to introduce these now since our focus is so strongly pointed at Planning and Managing. We decided to bring them along because they are all so closely related and want to have a complete package as these are released.
... Shadi, any addiitonal comments from you before we open the floor?

Shadi: Yes one addiitonal point...this is a collection of resources that work together and must be aligned. It is time to review those two others that are part of the general package to see how the cross references work, that there are no contradictions. Also think of those other two resources as stand-alone and how they work as a guide for their topics apart from the Planning and Managing resource and process.

Shadi: These two are about prioritization and to help people put out their immediate fires but refer people back to the larger strategy document for longer term planning. If there are inconsistancies, we need to identify them and I will buy a beer for anyone who spots those.

<shawn> fyi - I do not particularly like the the expand-collapse in http://w3c.github.io/wai-planning-and-implementation/improving ... :-)

Brent: Thanks Shadi, does anyone have clarifying questions?

Shawn: Point of order for the time, we got cut short last week on the naming discussion, I wonder if we might want to summarize and table the naming discussion.

Brent: Eric, can we quickly get through your report and on to the naming discussion?

Eric: yes

Gallery of Accessible Web Components

<yatil> https://lists.w3.org/Archives/Public/wai-eo- editors/2016Jan/0007.html

Eric: We needed to get this started from a content perspective. Want to get more widgets, templates, etc into the resource so we can populate it. Howard, Andrew, and AnnaBelle volunteered to help us find stuff to put in, I have sent them email and everyone can find it on the wai editors mailing list, please feel free to submit.

<yatil> https://github.com/w3c/wai-components-gallery/wiki/Submission-criteria

Eric: also when the public submits, we must provide criteria that must be met...those are in the wiki, please read and comment, add to,or edit. There are broad things like WCAG conformance that may be too broad. I am very open for your suggestions and feedback. Will put into the survey.

https://lists.w3.org/Archives/Public/wai-eo-editors/2016Jan/0007.html

Naming the Gallery

Brent: We looked at two things - the describing word..gallery, library, etc and the resource word - compnenet, widget, thingy
... the highest rated describing word was Catalog.
... let's look at the words suggested for the two parts...

More likes: Catalog, Hub, Directory, Compendium, Index (new)

No because sounds like we host them: Repository, Library, Bank, Collection

More not likes: Cache, Co-op, Museum, Toolkit, List, Gallery

Not use "WAI" in name

Shanw: We expect it to contain templates, widgets, frameworks

Shawn: In terms of overall what this is - we have widgets, templates, and frameworks but we may use the tool structure for another purpose like articles and tutorials.
... but those would be in another database for different types of resources.

<davidberman> understood

AnnaBelle: I have a concern about that...I had understood that the reason not to use WAI was a different reason. If we say clearly that this is a pointing resource, it should not be an issue.

Shawn: We did not really explore this question with full attention.

<shawn> fyi, the other things that we have that's kinda like this is the https://www.w3.org/WAI/ER/tools/ Web Accessibility Evaluation Tools List

Shadi: There is the aspect that people will have greater confidence when it is from WAI but we have a tradition about pointing to other people's resource and then maintenence becomes an issue. We must clearly communicate that what people will find are links to resources *outside* WAI and not create expectation that these are only from WAI. That they will find links to things all over the web.

David: Do we want to think of a more widely crowd-sourced resource?

Shawn: That is what this is.
... one of the things to note, this is very much like the Evaluation Tools List. People submit tools and we have a database that you can search to find them.
... we spent time on words to describe the collection, not as much on the items being collected.
... in the big picture when we may have one of these resources that lsits widgetd, etc and anotehr one that lists articles or tutoials, may want to think about the Overview of all of these resources.

<davidberman> Based on what has been said, I would like to add two more suggestions to my entry: "index", "list"

Sharron: What about "list" to emphasize the similarity in function to the tools list?

<yatil> Components...:-)

Shawn: And then what about the items that are listed. Is there a word that encompasses "widgets, frameworks, and templates"

Sharron: What about Development Tools list"

Eric: Bundles

<yatil> Bundles

<yatil> Website Elements

AnnaBelle: Development Bundles
... part, piece, bit, element, constituent, ingredient, building block; unit, module, section.

<yatil> assets?

<Zakim> Brent, you wanted to ask about future of resource again.

Brent: My thinking on this is that we want a name for everything that might possibly be used in the future. The power of this resource is that somone looking for a widget comes and sees that there are all of these other things that might be useful to them.
... I would want it to be in one place so that when they come looking for one thing, they will find all the others.

Shawn: We should actually address this now. If we do it the way you are suggesting, it would make the naming easier - resources.

<Brent> I have a good analogy

Shawn: but the point was made last week is that they are very different things if you are looking for code rather than an article. But you, Brent have just made a case for having these things all in the same place...should they be together or separate? What are your thoughts Eric and Shadi?

Brent: Like Walmart, it began as a hardware store but then they added all these other things and tell others, and soon everyone is going there.

Shadi: Eric and I have been having this discussion and have considered SEO - how will people find this if it is so broad? This cross reference among the different resources are clear. But the specifics of what I am looking for and its relevance to the work I do is also improtant.
... breadth vs focus

Shawn: Shadi, what are the things that you put into a search engine?

Shadi: For now we are focused on the components

Shawn: But Eric is not comfortable with that term.

Shadi: It has had a different meaning in HTML5 but it is changing, there are technical implications but we are for now for this resoruce focused on developer, code-based resources

David: I recognize the challenge and want to support Brent's impetus to make the resource as broad as possible. Maybe we want to identify the benefit to the user rather than the items in the repository.

Eric: We will have things that can be searched and found - at the moment you get results from all three categories. As it is now, it will nto make sense to add articles, tutorials, discussions, etc. We expect there to be vendors submit resource. To make it broader will necessitate adding many more tags and adding breadth.

Shawn: First you said, we do not want articles and tutorials combined but at the end you said maybe we do want that, clarify?

Eric: My personal view is that we do not want to combine the different types of resources.

<davidberman> Ideas for a name for the place you go to find all the things that will accelerate accessibility: "WAI Central"...

Shawn: We are still coming up against time and the issue of what happens to the resource in the furture.

Brent: The discussion is good but yes, we need to decide what it will becoem before we can name it, will try to give more time at the start of a future meeting.

Report on Asia Pacific subgroup meeting

Shawn: Teleconference to connect EO to people in NA Pacific and the Asia Pacific region. Time zone was challenging, had 2 from China, 4 from Australia. One from Japan is interested. This was an orientation meeting.
... current plan is to meet once a month by teleconference and stay current with work in progress by survey and wiki and minutes.

Brent: Thanks Shawn, trying to include that part of the world, you amy be seeing new names.

EOWG Meeting logistics

Brent: Pretty sure we will have F2F at CSUN, leaning toward the 21st and 22nd, will plan for the meetings. Would prevent participants from attending pre-conference, but would not interfere with other sessions.
... survey and W4TW will be posted soon, will inlcude Gallery and Palling and Managing as well as the two new reources.
... Thanks for a good meeting everyone, appreciate your comments and full participation. Bye.