Brent: Happy New Year to all, haven't talked to many since last year, looking forward to a productive year in 2017.

February Face to Face

Brent: It is confirmed that we will hold to f2f, on the pre-conference days, Monday and Tuesday. There is a section of the wiki page to indicate your participation
... please let us know what your plans are and if you will join us.
... if you need justification or a letter from the chairs to let the bosses know that you have a commitment to EO, we will be happy to do that. Similar to the one Sharron wrote for Laura.
... exact location is still tentative and should be confirmed next week.
... also list of tentative topics, feel free to suggest work that you would like to focus on. On wiki or here in the meeting. Draft agenda is coming and hope you contribute your ideas. .. comments or questions about the f2f?

<Brent> participation: https://www.w3.org/WAI/EO/wiki/EOWG_F2F_February_2017#Participant_Availability

Weekly Reports

Subtopic: Policies

Mary-Jo: I made updates to the pages, sent a couple of files for consideration. Continued to update the full mockup of the page in Word, filling in the categories that I expect each county to have. Trying to get an idea of how extensive this will be. Added several countries trying to see how long it could get.
... Trying to decide about sorting vs filtering. Since I am not a web designers I need help from the group about which would be better. My own perspective is that a table sortable by category...but open for other ideas.
... also created an input form. Need to know if we think this is the right info, so appreciate your consideration of that.

<yatil> https://lists.w3.org/Archives/Public/w3c-wai-eo/2017JanMar/0011.html

Mary-Jo: So 3 questions are: sorting vs filtering; is the information level correct?; is the form OK?

<shawn> +1 for putting it in GitHub so we can propose edits easier for all

Sharron: We could probably discuss filtering vs sorting but the other we would need some time to consider and comment.

Brent: I agree

Shawn: First of all, GitHub is a good place to comment and suggest changes. Thanks tons MaryJo it is so exciting to see it moving forward.
... it would be good to have an "other" or "I don't know" option on some of the questions in cases where people may be entering the info and not necessarily know the right answer.
... recommendations is a word that is weighted differently at W3C so we may want to find another word for that.

Shawn: those are two quick things about the form and generally it is so great to have this form to get the specific information.

MaryJo: I had thought about the "recommendation" thing as well, will take that into consideration.

<shawn> 1 for filtering -- e.g., I was to see which policies are using WCAG 2.

Eric: Feel that this is a good direction, great work, thank you. I tend in the direction of filtering and think this is a very good approach. We cannot depend entirely on what people submit. There will be some basic fact checking needed.

<shawn> +1 for us needing to review all submissions before they are posted

<shawn> +1 to multi-select for some of those, e.g., Type of policy or law

Eric: In some cases the dropdown is insufficient for the multiselection that is probably needed. That is a detail for later.

Denis: Do we want to go to the provencial level in Canada, I know we are not doing the states, but I do have data for Canada.

MaryJo: Yes but on a separate page.

<shawn> old page https://www.w3.org/WAI/Policy/CA-Provinces.html

Shawn: I was thinking about how people may want to use this, especially if we include filtering. If the content will be filtered, we may be able to put it all on one page. I wonder about including states/provinces in same list if we have filtering...

<yatil> [Eric: That can be done in the UI, it can be a disclosure. We need to make it simple.]

Sharron: Caution to conside the complexity of the filtering. Filtering on the QuickRef is complex for people and folks who use this may be even less technically experienced. Maybe just a sortable table. Or very, very simple filtering. So if we do go with filters, I would suggest we keep them quite simple.

<Eric> +1

<shawn> +1 to simple filtering if any

Eric: That is true that the people researching the policies may not be as accustomed to tech tools.

<shawn> +1 for Policies audience not necessary high tech skilled or heavy repeat users

Brent: Typically when you filter it is because you are seeking info from many sources. In this case, we are looking for information about one country or one use case etc. When would filtering be required vs sorting and how frequent?

MaryJo: I frequently get questions like - what countries use WCAG2, which have new regulations, where to focus resources? So I get this from both a very specifc and very broad international context.

Shawn: That brings up a good point. The central questions will be who is using WCAG2? etc. The majority of use will be very simple filtering.

Brent: Then it seems that we need something beyond a sortable table and the level of filtering should be quite simple.

Eric: I agree for a simple filter and I think once we have the data we will work with, some good solutions will suggest themselves. We can try and refine. Need to think about a ne
... notification mechanism about what is new.

Brent: So that once a new submission is made, people who subscribe to the tool can get a notification.

<yatil> [RSS, Web Notification, Mailinglists]

Sharron: and a note sent to WAI-IG

Brent: Have discussed the filter, pretty much agreed that we will use a simple one. And we need a simple presentation of these documents that MaryJo has created. So we need to get these posted and a comment area set up in GitHub.

Shawn: I am not convinced that we want both the table and the filtering. It could get really long and unruly

Sharron: What would people see if there was no table?

<shawn> Shawn: Table will get *very* long. Table and filtering? Filter changes the table?

<yatil> [filter change table was what I was thinking, like a pivot table]

Eric: Would prefer to have the documents on a wiki page or something. There is a prototype at this time. Doing an open comment/brainstorming round.

<shawn> GitHub repo : https://github.com/w3c/wai-policieslist/

Sharron: We will use the GitHUb link from the prototype to comment on this?

Eric: That will be OK with me.

Brent: If we use the Word mockup, people will just look at that and make their comments in GitHUb.

Sharron: Yes that is where we were going...and I will add those questions to the survey.

Brent: Is that OK for next week?

Shawn: may be tight with all else we have.

Sharron: let's put that as a goal and extend if needed

Brent: MaryJo, thanks so much, this is great work. Any other questions for the group or group, any Q for MaryJo?

<yatil> [supports Shawn�s approach]

Shawn: The UI may be a great thing to work on at the f2f. In the meantime we finalize the form and make it active then on content, wording, data collection, etc.

Brent: Good idea
... any other comments?

<yatil> [also the data collection will show us if there are any gaps or information that we need addititonally]

SubTopic: Tutorials

Eric: I did send out a survey for review and approval, due on Tuesday the 17th. Have ironed out the issues that were raised. Hoping will get into the shape needed for publication. Hoping to get the remaining tutorials also into shape soon so can publish in one big push.
... there is an approval for each page so if there are objections we can narrow those done pretty quickly.

<yatil> [Link to the survey: https://www.w3.org/2002/09/wbs/35532/tutorials-review-Jan-2017/]

Brent: Focused on carousels right now and will send a reminder since we have one survey closing Tuesday and another one Wednesday. Any other RM reports?

Denis: Quick Tips have been under consideration by us - Robert and me - we have met and are using the previously submitted spreadsheet and as we refine and address them we will bring those to GitHub and the group for discussion.
... the goal is for us to prompt each other to keep us honest. Will review the 3 existing categories and get back soon. The content there needs to be fleshed out and we will start with those.

Shawn: Quick Tips were finalized and approved within the last year. I wonder about improving existing tips vs creating new ones?

Denis: I have been using them a lot and want to be sure that the things that are not quite right about those are addressed before moving on to the newer ones.

Sharron: So if I understand the plan, it is 1. to suggest changes to already published QuickTips, 2. address the three drafted tips that were not finalized and published. Is that right? Previously you mentioned a bigger picture vision that would change requirements, etc

<shawn> +1 for finalizing what we have before going bigger picture !

Denis: Before we go into anything more ambitious, we want to validate what we currently have and consider the existing drafts and only then move to something else.

Brent: Yes very glad that the two of you have this interest. Having someone like you who uses the resource in trainings be the steward of the document is great. let us know when you are ready for feedback.

Denis: Likely to be one at a time...design tips are what we are working on now.

Sharron: Remember that these are meant to be short quick tips and not expanded too much :)

Shawn: Ideally if RMs have requests for EO attention, it is best to try to come to the planning call on Thursday to make sure that we make this call as efficient as possible.

Brent: agreed thanks Shawn. Any other QT comments?

EasyChecks

Brent: It is published and have asked for public comments. Shawn has been looking at the six comments that came in.

Shawn: I have reviewed them and have recommendation, we are hoping for initial resolution today. Feel free to ask for more time to consider.

<shawn> https://github.com/w3c/EasyChecks/issues/66

Shawn: they are in GitHUb, if you agree it would be helpful to add to GitHub but fine to just do it here in the minutes as well.
... Issue #66 basically asked about the contrast ratio. Unclear about "normal sized text." Proposal is to more specifically define what are the sizes of text. Resolution would add two bullets with specific text size.

Caleb: I would remove points and define it in pixels and remove the parentheses
... Normal text refers to text that is not headings

<Susan> "normal" = not bolded imo

Denis: 4.5 to 1 for all text under xx pixels

Eric: Current discussion in WCAG-WG about pixels vs points. Same measurement as defined in CSS. Need both in general but in Easy Checks pixels alone should suffice.

Robert: In first bullet, there is a typo.

Shawn: (applies edits)...agree with current change?

Denis: I agree with what Caleb brought up to focus on pixel but becasue the SC refers to points, are we risking confusion by departing from that?

Eric: The Understanding doc acknowledges the alignment.

<yatil> [[Note: When evaluating this success criterion, the font size in points should be obtained from the user agent or calculated on font metrics in the way that user agents do. Point sizes are based on the CSS pt size CSS3 Values. The ratio between sizes in points and CSS pixels is 1pt = 1.333px, therefore 14pt and 18pt are equivalent to approximately 18.5px and 24px. https://www.w3.org/TR/WCAG20-TECHS/G18.html (greenish note)]]

<KrisAnne> +1

<Denis> +1

<Robert> +1

<Brent> +1

<Caleb> +1

<shawn> +1

Shawn: Other discussion? Can you +1 if you support the change?

<Susan> +1

<Laura> +1

+1

<yatil> +1

<shawn> https://github.com/w3c/EasyChecks/issues/68

Shawn: Issue #68

RESOLUTION: Accept the change to Easy Checks defining text size.

Shawn: IMO, don't need to add "images of text" since it adds complexity, instead just add the word "all"
... discussion?

Eric: grammar of all text and background?

Shawn: How to rework?

Caleb: minimum contrast is what makes the phrase awkward.

<shawn> All text should also have a minimum contrast with the background by default...

<shawn> All text should also have a minimum contrast to the background by default...

<yatil> All text should have a minimum contrast to the background by default�

<Brent> option: provide enough contrast between text and its background

<KrisAnne> agree with brent

<Caleb> +1 Brent

<KrisAnne> provide minimum contrast between text and its background

<KrisAnne> All text should provide minimum contrast between text and its background.

<yatil> [actually should provide minimum contrast sounds like they should not provide more contrast]

RESOLUTION: All text should provide at least minimum contrast between text and its background by default

<yatil> +1

<Denis> +1

<Brent> +1

+1

<Caleb> +1

<shawn> Sorry I can't process this well now. Probably OK but I need a little focus to confirm.

Shawn: Issue #70 is one where I want people to look at this in different browsers.

<KrisAnne> 5 for Chrome on Mac

Shawn: how many times you must do cmd + to get to 200%

<Susan> 2 on chrome

<Susan> sorry, thats what I use. :)

<shawn> in Firefox and Safari

<Laura> 5 on FF

<Susan> Can we just avoid telling the key presses and number of times if it varies browser by browser and platform by platform

Shawn: It is kind of a challenge since the number of + are different in different browsers. What is simplest way to do this accurately?

<Susan> that seems to be the simplest

<Susan> Also... not everyone is set to 100% by default.

<Brent> I agree with Susan as well.

<KrisAnne> Firefox didn't tell me

<Brent> I couldn't find the percentage in FF

<Laura> FF for me gives me a visual que

<yatil> [Safari does not say it, unless you set the default in the settings.]

<Brent> Windows 7 and FF - I have no add ons and it took 6 to get to 200%

Eric: Yes, there are so many variables. maybe just say...make it responsive and you are good :)

Denis: Or we can just say "hit this 6 times" since in some cases we need to cur corners. Simplification supports our goal in this case. Can it really matter if it gets to 210% instead?

Shawn: I will take another pass based on this input

+1 to Denis' point

<shawn> https://github.com/w3c/EasyChecks/issues/67

Shawn: Issue #67 is related to text size and the commenter brings absolute text size as another example. What each browser does with absolute size is complex and so I propose that we continue to avoid the complexity and leave the text as is.

Caleb: I am trying to understand the point of this comment.

<Zakim> yatil, you wanted to iterate (briefly)

Shawn: I think she wants us to add to the example the case where absolute text creates the same problem.
... the proposal is not to make any changes.

Eric: I think people who do accessibility are expecting us to address broader issues and we are not trying to be comprehensive.

<Brent> agree with one example too

<Denis> +1 to leave as is

<Brent> +1 to leave as is

RESOLUTION: No changes will be made to that text about text resize

<Caleb> +1

<shawn> +1

<KrisAnne> +1

<yatil> +1

+1

<Laura> +1

<shawn> https://github.com/w3c/EasyChecks/issues/69

Shawn: Issue #69 is media vs multimedia, I addressed, she agreed, any objection?

Sharron: No objection

<scribe> ACTION: Caleb to work with Eric on code fix of bug for Issue #65 [recorded in http://www.w3.org/2017/01/13-eo-minutes.html#action01]

<trackbot> Created ACTION-375 - Work with eric on code fix of bug for issue #65 [on Caleb Watson - due 2017-01-20].

Brent: Any addiitonal Easy Checks comments?

Mobile Accessibility

Susan: Sharron represented us in the planning meeting yesterday, and we have some ideas about how to update language and approach.

<Brent> Mobile Overlap page: https://www.w3.org/WAI/mobile/overlap

<shawn> main mobile page: https://www.w3.org/WAI/mobile/

https://www.w3.org/WAI/mobile/overlap

Susan: There is a lot of confusion in the way the pages are titled, what their purpose is, how they differ etc. The disclaimer indicates the age of the page.
... would like to make titles and intros to the pages
... more clear. Mobile is one of the highest hit pages and people are looking for testing and development tips and they get frustrated. Need to also clarify our goals. Since we do not want people to think that mobile and accessiiblity are separate, we do not use that approach as we talk about it here.

<Susan> https://www.w3.org/WAI/mobile/experiences

Susan: must go all the way to the bottom to find these check points about how the principles of accessibility apply, Could be misinterpreted as being the only things that apply to mobile.

Sharron:Sharron: Plan to open GitHub so consider ways to clarify. Will look at ways to streamline and update current text and align with work of Mobile TF.

<shawn> +1 for focus on current info. *however* people are still finding those other pages useful for specific use cases, so not just old archive info

<shawn> [ use case for other docs@@]

<shawn> [ use case for other docs -- a case study that provides a use case for people wanting those resources: the business case case study at <https://www.w3.org/community/wai-engage/wiki/Social_Networking_Application_Business_Case>. It directly links to the /WAI/mobile/overlap ]

<shawn> [ Shawn eager for ideas on how to present this so the overall message is what we want (while maintaining other useful info) ]

<Brent> When we say it has a high rate of visits, how many visits is a high rate?

Eric: I tend to agree with the fact that people land there is not enough justification. More relevant is the question of is this what we want them to see and use. I guess the term "overlap" is hard to parse and we can do better. testing that, using those three pages as an example of how to move forward into the redesign.

Caleb: When I search for mobile, I look for native mobile. The "overlap" implies that but does not deliver. There is a lot of opportunity for clarification but there is also a huge hole.

<Susan> +100 Caleb

<Zakim> shawn, you wanted to say retitling good, and also looking at where it fits in nav (I think all pages maybe go elsewhere -- so looking forward to redesigned IA!)

Caleb: native is an issue that we have not addressed.

Shawn: We need to look at how these things are positioned, linked to, referenced. All these pages probably belong somewhere else in the IA. So I think yes, the main point can be made more clearly and we want to be sure that people can get the info the need.

<Susan> +1 shawn

<yatil> +1 shawn

Susan: Yes and we need to look at how to integrate mobile accessibility and not make it a separate islnd.

Brent: Thanks for this work and we look forward to the next steps.

Wrap Up

Brent: Standard procedure ...look at work for this week, answer surveys, email coming today. Those who need to go may do so, Caleb and Laura will stay for discussion of meta data.

Metadata

<shawn> https://www.w3.org/WAI/EO/wiki/Metadata_Guidelines

Laura: Am starting to create my process...should I be only be working on production versions?
... does Eric want these in any order?

Shawn: Just send them as they are ready. Do not need to be done at once. Whatever is conveninet for you.

Laura: Just want to be sure I am working on the right content.

Shawn: He created metadata guidelines.
... Caleb?

<yatil> moz.com

Caleb: FB and Twitter have preview tools and guidelines for optimizing. I can add those links if it helps. Google as well. I think the modeling you have is great but I will say that Google is a bit different. They have a container element that limits what will be parsed. Stick with what moz says you will be good.
... that is the gold standard

Shawn: It is most useful if you send us a "to do 'this'...and a link to more"

<shawn> Laura, descriptions, too.

Eric: We need description of pages and tags. When we build our own search we will use those
... most will be evergreen for the majority of the resources.
... I will take care of syntax, it is working perfectly so far. You will not have to thinkmuch about that.

Caleb: Really you need description around the title then, don't need a ton of editing on the wiki guide.

<yatil> [Internal comment to shawn: We might want to add the descriptions to the pages.yaml file and then generate the overview pages automatically as well.]

<Zakim> shawn, you wanted to tak about annotated nav pages

Shawn: Great thanks Laura for taking this on and thanks Caleb for your support.
... anything else?

<shawn> Eric: I have spoken.

Eric: Thanks so much!

trackbot, end meeting