The meeting began with a welcome to the new year and a confirmation of the fact that the next face to face meeting is finalized for February 27 and 28 in San Diego. Feel free to contribute ideas for what work to focus on when we are together. Next MaryJo presented a word document with her suggestions for new Policy page content and some questions for the group. Discussion led to three questions that will be on the survey Andrew and Robert agreed to support - Robert will update the prototype with MaryJos's text and Andrew will take the questions and move them into GitHub. Eric has addressed issues submitted for Tutorials and asks EO to complete a survey for review and approval, due on Tuesday the 17th. Caleb and Shawn reported on the publication of Easy Checks and the comments that have been received. To address those public comments, the following resolutions were made:
Denis and Robert are working on the QuickTips with the goal of clarifying current Tips, considering the publicaion of the three still in draft, and then proposing next steps for development of the resource. Susan had proposed updates for Mobile Accessibility and will put those in GitHub. Laura has begun to develop a template for metadata included in WAI pages. Brent reminded everyone to update their availabilty and to complete work for this week including the weekly survey. Caleb and Laura stayed to discuss with Shawn and the Chairs the approach to improving metadata on in WAI resources while the meeting adjourned for others.
Brent: Happy New Year to all, haven't talked to many since last year, looking forward to a productive year in 2017.
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
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?
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?
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.
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.
<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