<shawn> https://www.w3.org/WAI/EO/wiki/EOWG_F2F_February_2017
Brent: 1st face to face - 27 & 28 February at CSUN - San Diego
<shawn> Update your Participation if you haven't already
Aim to have agenda done by the 3rd of Feb.
Feel free to add things to the agenda.
scribe: Don't have to wait until
the 5th. Finalized agenda by Feb. 13...
... Link to participation - indicate which if any days you will
participate...
Can also participate by phone.
Hotel Solamar - still waiting for confirmation...May possibly be another hotel. Should know by next week.
Shawn: ... Caleb, can you call in for the meeting to discuss some of your ideas...
Caleb: if stays in country will call in.
Brent: Review and approval survey.
<yatil> https://www.w3.org/2002/09/wbs/35532/tutorials-review-Jan-2017/results
Eric: Will give overview of
survey results.
... All pages received support for publication, some with
editors discretion...
... A few things that needed edits and has made most of those
edits with the ...
... exception of the styles page...
If you had a comment you forgot to put in, please let me know.
<yatil> https://github.com/w3c/wai-tutorials/issues/389
<yatil> https://w3c.github.io/wai-tutorials/carousels/#what-are-the-key-points
One issue raised: usability warning of cursors.
<yatil> [Note: Carousels are disputed from a usability perspective because their content can be hard to discover. Ensuring accessibility can also improve usability.]
Structure, functionality and animation pages - received approval. Minor
issues of missing words, etc. Nothing impactful. From Andrew: should animation be
before functionality?
<yatil> Concepts – Structure – Functionality – Animations – Styling
scribe: Will leave it in order typed in above unless hears otherwise.
Brent: Andrew - clarify thoughts on this?
Andrew: don't recall reasoning on this.
<yatil> [Andrews proposal: Concepts – Structure – Animations – Functionality – Styling]
Eric: order probably doesn't make
significant difference.
... on to styling page: several comments from Shadi for
removing links to ...
<yatil> https://w3c.github.io/wai-tutorials/carousels/styling/##rule%20of%20thumb
Eric: other resources - done; and some wording changes which he also did.
For discussion: button size. How big a button should be on the page.
Document called accessibility mapping - problems of measuring .9 mmeter button size...
scribe: about 45 x 45 pixels but you can't be sure. Shadi recommended removing that recommendation.
Shadi: color contrast is what he suggested be removed.
Was relaying recommendations from mobile accessibility taskforce...
Wondering how it could be phrased without all the details and not overemphasizing it as a strong recommendation.
In other words, this is a proposed idea but not confirmed.
scribe: And that this recommendation may actually change.
Eric: We have research that
supports the 45 x 45 pixel measurement. Complicated due to
display on ...
... different devices, resolutions. Google might be a little
more.
... 9 mm by 9 mm is pretty small.
<Andrew> can we maybe say something like "current best practice indicates a 9x9 millimetre is a good min size for interactive elements ..." ?
Eric: Should probably have used more muted language.
Shadi: thinking outloud:
something like "different recommendations for sizes of these
items." I.e. mention ...
... white space in general. Indicate different recommendations
from different groups.
Andrew: Anything coming out in 2.1 criteria that addresses this?
Shadi: this is recommendation
from mobile a11y group but likely this will be debated...
... Spirit of requirement is to make it big and have white
space.
Andrew: can use wording of current best practices...
Shadi: discussion has become quite technical and detailed.
Perhaps in main body of text we discuss the general spirit of the recommendation and put technical ...
scribe: recommendation in a side bar or footnote.
Eric: will wordsmith to say make
it big and have white space and will mention ...
... future recommendations are in development.
<yatil> https://w3c.github.io/wai-tutorials/carousels/styling/##3:1%20ratio
Other issue on styling page - possible removal of contrast ratios.
<Andrew> +1 to generalising interaction size note
At moment put in there text needs to be 3:1 ration if big and 4.5:1 if smaller.
Shadi recommended removing that much detail. Eric's rationale is to nudge people in ...
scribe: the right direction to
indicate what we think adequate size text is. General ...
... pointers may not be enough without some specifics...
... Wants input on whether we should leave in that
specificity.
Dennis: Don't feel a problem to
mention technical specifics of contrast ratio.
Otherwise...
... folks will have to look for it elsewhere.
Shadi: felt it was too wordy, big
chunk of text. Would have it in every single...
... tutorial. For example, very last paragraph could be
removed. "Aren't really contrast recommendations for text links
and buttons."
<shawn> fyi, there mostly likely will be requirements for contrast of other things in WCAG 2.1 It was proposed by the Low Visin Task Force.
Feels too much is being added. Middle paragraph: rewording success criteria. Doesn't see the need to repeat in this amount of detail...
scribe: Too much detail for this tutorial...
Brent: Agree on wording just being a rewording of actual guidelines.
However this might be sent to a developer and reader won't know what sufficient contrast is. Perhaps provide a ...
scribe: link to the more specific recommendation.
But agrees that language could be cleaned up - a bit repetitive. And should use exact language of ...
scribe: recommendation.
<Andrew> +1 to keeping contrast criteria requirements (too many get it wrong) - could drop last para (a bit repetitive)
Denis: When looking at a tutorial
such as this, want to be able to extract everything from
tutorial...
... and turn into a shopping list for the developer...
... Would want each tutorial to cover all the things needed
according to WCAG...
... So thinks recommendations should be there but could be less
wordy.
Shadi: Like the suggestion of
linking out. Maybe instead of linking to eval tools, to quick
ref, or to both.
... Overall question: how much background do we need to send to
a developer?
Andrew: agrees with Denis. If we can avoid requiring readers to go to a separate document should do this.
<Zakim> yatil, you wanted to say pt vs. px and to comment on eval tools and to agree on language cleanup and to comment on deliberate rewording of the SC for clarity
Eric: a few reasons why included ratio. Agree 3rd paragraph is too much - will remove...
first reason: wording in success criteria is very confusing for many people.
Wanted to make it clearer.
Second is confusion about points values in success criteria. Points and pixels are not the same but ...
scribe: this often gets confused. Wanted to emphasize the pixel value...
Shadi: Concerned about rewriting
a success criteria. Said we wouldn't reinterpret
guidelines...
... Do we really want to repeat everything in every
tutorial?
... In past critiques for repeating everything everywhere.
There are two approaches.
Group needs to decide on this.
<Zakim> Andrew, you wanted to mention fishing
Andrew: being persuaded by Shadi's argument.
Shawn: as per Sharron & Charlotte, try to avoid repeating information.
James: As we look at greater site redesign we should take a philosophy of putting in less...
<Zakim> yatil, you wanted to comment on what a tutorial is from my pov
James: Advocate for linking out?...
<Brent> +1 (I have been swayed)
<dboudreau> +1 to linking out for additionalinformation, as long as we still cover the basics in the tutorial
<Laura> +1 for linking out
Eric: for him, a tutorial usually
means going from a to z. Feels like removing the specifics
...
... takes away too much information. Not sure we should link
out to another resource but sees consensus in IRC.
Shadi: we don't do this for labels for example.
<Zakim> dboudreau, you wanted to discuss focus outline
Eric: okay with removing it if consensus.
Denis: When we get to the stop
button, looks like a hash tag symbol. Can we make a change to
the CSS styling?..
... Especially problematic for the stop function - not clear
it's a stop button.
<yatil> Eric: Now I see it, too.
<shawn> Howard: When folks see "sufficient contrast", peopole wonder what it is. Think we want to make it easy for people to find that information.
<Andrew> howard: agree with eric about making it as easy as possible to find any info discussed
Eric: Consensus is just to link out.
<Laura> +1
<shawn> +1
<dboudreau> +1
<Caleb> +1
Eric: put plus 1 if agree to link out.
<Andrew> +1
<Brent> +1
<shadi> +1
<James> +1
+.88
<yatil> +.51
Denis: thinks a way to link out without taking too much out.
<Andrew> yes - don't remove all the discussion
Denis: Having all the different
pieces as part of the tutorial but a paragraph that says
...
... for more information, go to this resource. A way to
summarize a little more.
... Address the issues but leave the details to existing
documents - success criteria, etc.
... We can still do the a to z but summarize and then link to
other resources.
... Thinking about difficulty finding things on site but at
same time, we're developing this new architecture...
... Leaving out all the details in each document will better
fit the design of the new site.
<Zakim> dboudreau, you wanted to make a cheesy metaphor on wayne gretzky
James: Need to keep in mind the
new architecture. Another technique that might help is
...
... to put a link in the body of the text with more
information. Frequently done in news stories.
<Brent> +1 to James idea of linking in text
Eric: do have resources at bottom
of page but perhaps have to link out more too.
... Will link out for now and then revisit once new
architecture is in place.
MaryJo: been working on this. Put out a draft page.
<shawn> GitHub issues: https://github.com/w3c/wai-policieslist/issues
Brent: Mary Jo has been working on this - didn't get a ton of feedback.
MaryJo: 3 questions posed in survey:
1 - preference for sorting vs. filtering (a few comments, no consensus)
some thought on combining the two if filtering is kept basic...
scribe: A lot of folks found the
table useful for obtaining a quick overview. Question on the
amount of work ...
... to do both.
2 - policy page mock-up itself.
For most part, feedback was positive. Some questions: what does a web policy only mean?
Some comments on particular definitions (she will tweak).
3 - data gathering form
Split between those who approved format and those who had comments. Such as making too many ...
scribe: fields required.
Other questions: choices between using drop downs vs. radio buttons/check boxes.
Conflicting advise on usability regarding this.
Would like to hear opinion on rest of group.
Was leaning towards drop down but up for other input.
Sharron sent out note saying should would like to see this proposal put in wiki so easier ...
<shawn> [ also consider *accessibility* of drop downs vs. radio buttons/check boxes ]
scribe: to review and comment on.
Thinks she can do this but not sure how to represent all the
functioning ...
... in the mock-up.
Were some comments on the front matter being so long and could we put at bottom of page....
scribe: Perhaps make it a collapsible segment.
<Andrew> dropdowns become particularly problematic on mobile devices / touchscreens
<shadi> [I didn't see the questions]
Brent: at a point of getting more
help, develop a team for heling Mary Jo.
... For example, needs help with coding and she had other
questions.
<Andrew> +1 to HTML mockups
<rjolly> I am happy to help with prototyping. Yes.
Need help with prototyping. Robert, are you able to help with this. Someone to document this issues in GitHub ...
<Andrew> happy to help once prototype started + help with issues
scribe: is also needed.
... We're at a point where we're ready to do
iterations...
... Andrew said he would help with GitHub issues?
Robert: happy to help with prototyping and working with Andrew and anyone else.
Andrew: ditto.
Eric: created a first prototype
based on Mary Jo's first draft.
... This can be seen on GitHub.
... If anyone wants to help, let Eric know.
Brent: if you want to help in anyway, let us know. This is a high priority resource.
We did miss comments that Mary Jo made in the document.
scribe: If possible, have someone
come to the planning meeting on Thursday. What we need on next
...
... weekly survey and/or should discuss on Friday.
Shawn: last week's survey some
public comments. Asked for some github feedback from
group.
... Looking for Safari instructions (for text size?)
... Estimating this will take 5 to 15 minutes.
Denis: thinks he can help with this.
<shawn> safari https://github.com/w3c/EasyChecks/issues/70#issuecomment-272595111
Denis: will do after this call.
Shawn: with that, we have almost
everything done with Easy Checks. Will be able to publish
updates for minor comments. Caleb also has to ...
... do some minor recoding.
<yatil> https://github.com/w3c/wai-tutorials/issues/404
Eric: idea of having additional links to working example.
<yatil> [I think it would be helpful to have an additional link to "working example." Perhaps under the first code example on each page of this tutorial.]
Howard suggested link to working example after each first display of code.
Eric: question is should it be
placed in the first example of code. Andrew suggested the
bottom of page.
... Useful to have the working example reachable easily on all
pages.
Brent: First reaction when looked at carousel tutorial, didn't realize the working example and entire code ...
was there. Maybe first few times you have code snippets, provide a link. But then phase out ....
on subsequent pages.
Andrew: people may not go through pages sequentially.
<Brent> agree with your points
<shawn> Howard: As I was going through, saw code, wished I couldsee a working example of it. Didn't see it in the nav. Wanted at top of page, rather than bottom (where wouldn't see it until late)
Robert: could use the informational aside to highlight the working example.
Eric: likes that idea.
... Will implement something that we can look at.
Brent: not sure of content of
weekly survey as of yet but will get updated.
... Hope everyone feels these meetings are more productive.