Tips Q1

Shawn: This one is about luminousity. Comments linked from the agenda, GitHub issue 36.

<shawn> https://github.com/w3c/wai-quick-start/issues/36

Kevin: My perspective is that as much as possible we should use the correct terminolgy. There is still a sense that the common useage is still "color contrast" even though it is technically incorrect. So we might introduce luminousity and explain it.
... I would not refer to "color contrast" and include "luminousity" as a term and let people know that's what we will be using. Need to be quite aware of audience.

Shawn: To summarize: Will NOT use "Color contrast," will include short note about the correct term.

<Andrew> yet 'colour contrast' is common usage - should it be mentioned?

Kevin: Would use phrase contrast ratio, and sufficient contrast.

Shawn: Not contrast between colors?

Kevin: No was going for succinctness.

Shawn: If the tip text is "provide sufficient contrast between colors?" would that be close enough?

Andrew: It is borderline. In my circle, it is the most common usage. Even if included in brackets, as we did in Easy Checks.

<shawn> (This accessibility requirement is sometimes called sufficient "color contrast"; however, that is incorrect - technically it's "luminance contrast". On this page we use "contrast ratio" as short for "luminance contrast ratio" because it's less jargony.)

Andrew: so if we use luminosity, add (color contrast) in parentheses.

<shawn> tip text/title: Provide sufficient contrast between colors

Shawn: Kevin, I think we need to consider what Andrew is saying and at least mention contrast between colors to trigger the association.

Kevin: Fine with that.

<kevin> RESOLUTION: Change tip to 'Provide sufficient contrast between colors'. Include additional information in description about luminosity a la Easy Checks

Shawn: So where we are is to provide sufficient contrast between colors and we mention even parenthetically the luminosity.
... and there were additional ideas included in some of the comments.

Kevin: There is quite a lot of suggestion for background information
... different use case, suggestion for stating the numeric ratio, etc.

Shawn: So in the first case, the low vs high contrast, the issue is that the contrast ratio stated in WCAG doesn't work for all, some need low contrast. The real issue is to allow people to change the contrast to suit thier needs. Does that belong here and is it relevant.

Kevin: The facility to change colors is more of a development rather than a design issue. Will consider and come back with proposal.

Shawn: So the second point is the question of whether to define sufficient contrast numerically? Comments?
... my question is if I don't know much about accessibility do the Tips give me enough to get started or how many of them would require more research to be able to implement?

<Andrew> e.g. http://w3c.github.io/wai-quick-start/designing.html

<shawn> if i miss it, feel free to speak up

Kevin: With a quick glance at the Design tips, this one about contrast is the only one that would require the reader to find a tool, learn more etc. However if we link to the tools list, there is a concern that they are out of date.

Shawn: So shall we give them something to use?

Kevin: I would be OK with a short sentence.

<Andrew> +1

<Howard> +1

Eric: I think the best is to keep it short, point them to more info.

Shawn: What does EasyChecks do?

Kevin: Refers to the IE toolbar, but does not inlcude Juicy Studios and other.

Shawn: Maybe pointing to the Tools in the Understanding docs. We should encourage and help WCAG update that.
... anyone interested in helping WCAG with that?

<Andrew> http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html#visual-audio-contrast-contrast-resources-head

Shawn: basically the task would be to look at our tools list, poll WAI-IG and help WCAG to update that document so we can point to it with confidence?

Paul: I don't feel that I have kept up with those tools enough to contribute in a menaingful way.

<shawn> http://www.w3.org/WAI/ER/tools/index.html

<shawn> also add http://leaverou.github.io/contrast-ratio/

Shawn: The task would be to look at the list that Andrew put in IRC. If any are out of date, suggest them to be deleted. Second would be to look at our evaluation tools list and pull the relevant tools that might be added, and you might send a message to WAI-IG noting that the contrast analyzer tools are being updated and ask for their contributions. Once you have compiled all, send the suggested updates to WCAG.

Howard: I hestitate only because of a number of current deadlines I have.

Eric: You might raise an issue in the WCAG GitHub and put links in there. (the link to the current list of tools)
... then, using that platform, you would ask WAI-IG to submit suggestions there.

<kevin> RESOLUTION: Add in something like: 'The guidelines provide a minimum ratio and there are tools to help you determine the ratio'

<paulschantz> I'm happy to provide additions as they present themselves to me

<shawn> [ Sharron sings Beattles song ]

Shawn: Any objections to this idea: The guidelines provide a ratio and tools help us figure that out?
... did we catch all the points?

Kevin: Yes I think we have.

Shawn: How did we address reader enabled contrast change?

Kevin: I will have a think and bring it back. I can raise an issue but it always starts with browser responsibility.

Shawn: But there are designer/dev tasks as well. we can start with that.

<shawn> https://github.com/w3c/wai-quick-start/issues/28

Tips Q2

Kevin: There is broad support for leaving in the acronym guidance and moving to bottom of list.

Shawn: Any comments or objections?

<kevin> RESOLUTION: Keep Expand acronyms and move to last on list

Tips Q3

<shawn> https://github.com/w3c/wai-quick-start/issues/29

Shawn: This is about Keep it short and simple.

Sharron: Howard added a good refinement: Keep content short and simple.

Shawn: Do you think most people writing for the web call it content?

Sharron: Absolutely yes

<yatil> +1

Paul: I work with marketing and others, they use it all the time.

<kevin> +1

Howard: Yes especially for writers, they will understand immediately.

<egyrs> +1

Paul: It is no longer a specialized term and has not been for many years.

Shawn: Proposal is that the phrase become: Keep content short and simple. Any concerns with that? Objections?

<kevin> RESOLUTION: Use 'Keep content short and simple'

Shawn: Another point is the idea is that a qualifier may be needed. Depending on the subject and goal of the content, simple may not be possible and short may not be a goal.

Kevin: The approach I have taken is to refer to context and not over complicate it.

<Howard> I like that qualifier Kevin just offered

<Brent> +1 to the phrase

Shawn: OK that is a proposal...discussion?

Andrew: Might the word audience be less jargony than context?

Howard: I think context includes the audience but then there is also the subject and the info you are trying to convey. My slight preference is for context.

<shawn> +1 to howard

Andrew: Use plain language where appropriate.

Shawn: Thanks for mentioning this Andrew, it is a good brainstorm but there is a case where our audience is a bunch of smart academics, we don't need to consider disability. Any further discussion?

<kevin> RESOLUTION: Change sentence to 'Write in short, clear sentences and paragraphs, as appropriate for the context'

Kevin: one other item was raised - the question about avoid using overly complex words and phrases...should that be wrapped into this one?.

Shawn: Andrew what is your thought about those...are they 3 separate things or should they be combined?

Andrew: It seems like they are so closely related as to be one thing.

<yatil> +1 - very similar concepts

<shawn> http://w3c.github.io/wai-quick-start/writing.html#keep-content-short-and-simple

<kevin> http://w3c.github.io/wai-quick-start/writing.html#avoid-using-overly-complex-words-and-phrases

Howard: The concept of plain language is covered by the previous, do not need to add.
... for the other two, I like the very short sentences. However I see the similarity so I am on the fence here.

<egyrs> clear and succinct?

Brent: my gut feeling is that 2 and 3 can be combined but 1 should remain separate. You are talking about being concise. The second (2 and 3 together) tells to avoid overly complex vocabulary.

Paul: is our language getting to be too nuanced and the most straight forward solution is to combine them?

<egyrs> I think clear and succinct is more "clear" than "short and simple". Because one sentence can be clear but not necessary simple ;-)

<Zakim> kevin, you wanted to give example

<kevin> https://github.com/w3c/wai-quick-start/issues/41

Paul: I have some hesitation. Keep it simple may be saying "Dumb it down" so to add the qualifier may say "Keep it a simple as possible BUT no simpler"
... roll into one Tip seems good.

Kevin: I was thinking that the first is about general structure and flow. The second is very much about the language choice. There is an overlap but they are both worth saying.

Shawn: As chair it seems there are people who thought initially that these should be combined, others unsure, and at least one who believes them to be separate.
... with chair hat off, I see two points. Short sentences and paragraphs and point two is avoid overly complex language. So It think we could easily combine two.
... my inclination would be to put it together, but not a strong inclination at all.

p class='phone'>Sharron: after listening, I want to change my vote... I now agree that both are worth saying and it is preferable to have two separate points

Andrew: I am taking advantage of the reserved right to change my mind - vote to keep them separate.

Howard: Change short and simple to clear and concise...or succinct. It is more nuanced and make the distinction clearer and eliminates the overlap to some degree.

<egyrs> Agree with Howard!

Shawn: Andrew were you suggesting to actually use the phrase Plain Language?

Andrew: However the references I know of are generally all about plain English rather than other languages.

<yatil> +1 for separate

Emmanuelle: Concise is not the same as simple. Important to bring in concept of clarity as well.

Kevin: I am comfortable with those. Succinct does bring the connotation of clarity as well.

<kevin> RESOLUTION: Keep first two writing tips separate

Shawn: Proposal is to maintain two separate tips. any objections?
... next proposal is to consider instead of short and simple using clear, succinct, concise or similar phrase.
... discussion on that?

<Andrew> clear and concise - more definitive

Shawn: First reaction is that short and simple IS short and simple and nice. But as I considered it, the alternate suggestion seems more appropriate regardless of content, encompasses more.

<egyrs> clear and succinct. Short is not equal to clear, and simple is not equal to suscint ;-)

<kevin> RESOLUTION: Consider 'short and simple', use 'clear', 'concise', or 'succinct' - or combination thereof - make GitHUb issue

Andrew: Clear, concise is more defintive. leave it to Kevin's good command of the language to come up with the right phrase.

<egyrs> I'm confortable with concise too :)

Tips Q4

<shawn> https://github.com/w3c/wai-quick-start/issues/40

<paulschantz> The order is not as important to me, just that it's consistent

Shawn: Consensus seemed to gather around consistency, any discussion?

Kevin: Do we want to discuss whether we want to link to all of the kinds of things in the list?

<kevin> RESOLUTION: Stick with a consistent ordering

Shawn: Let's look at the next topic and see if an issue remains.

Tips Q5

Shawn: This one is about the format of the links in the Learn More section

<shawn> https://github.com/w3c/wai-quick-start/issues/39

Kevin: I would like to get a recommendation for how to categorize the links. There is a bit of thought required, for example is EasyChecks part of HowTo...or where?

Shawn: Can you do that consideration and bring a proposal?

Kevin: I think it will be an ongoing process.

<kevin> RESOLUTION: Use link structure as in example 2, and raise any questions on labelling as they arise

Tips Q6

Shawn There are two points here. One is the question that was opened...

<shawn> open question https://github.com/w3c/wai-quick-start/issues/27

scribe: and a related issue

<shawn> related issue images overwhelming https://github.com/w3c/wai-quick-start/issues/30

Shawn: On the specific point of should we include bad examples, it seems we have unanimous support for that. Any concerns?
... objections?

All: none

<kevin> RESOLUTION: Stick with including bad examples as well as good, where possible

Shawn: next issue is the overall distraction of the examples for me. Any other input?

Sharron: In general, I am a text lover. I look at text direction in Google maps for example jsut cause it makes more sense to me. I like the narrative. In this case, however, it seemed easy enoough to just skip past the graphincs and read about the issue, so it was not a huge problem for me. Maybe I am just very accustomed to doing that.

Andrew: I don't but I understand that people do have a tendency to be distracted by graphics. Can we hide them and allow them to be expanded for those who wish to see them? That would also allow a few more examples to be added.

<egyrs> +1 to expand / contract

<egyrs> And add text examples too, so people like Sharron can have advice about examples, not only graphic ;-)

Shawn: For me, I like the graphics and I want the examples to be there, I just don't want them to be so attention getting or would prefer if they were collapsible.

<paulschantz> I support Andrew's idea of making examples collapsible

Andrew: It may also be appropriate to have hide/reveal for developer's with code samples.

Howard: I would not want to see the examples collapsed. The graphics help break up the page, tend to make it MORE readable. As you move along, the graphics are easy to scan. If you collapse them there is a good chance they will be overlooked.

Sharron: +1

Shawn: Can I note that if we chose to have expand/collapse we could choose to have them expanded by default. People would automatically see them but for those who are distracted, they could be collapsed.

Howard: Providing flexibility seems good, would not argue against that.

Sharron: +1

Brent: I like expand/collapse a lot but am not sure this is a place to use it. I like the examples to be shown and like it to be part of the page. When I hit the exmaples and get drawn in, I must back out and think "What am I doing ". Wondering if the title of the Tip might be emphasized to draw the eye in. Maybe the problem can be solved by design.

<shawn> +1 to Brent - some way to help focus away from the examples

<shawn> +1 for if expand-collapse, have expanded by default

Eric: In the tutorials, we have boxes that fence in the examples against the surrounding text. We may need to weight the Tip text more prominently. There are ways to give the examples more weight without hiding them. I would vote for keeping them visible.

Shawn: Looking at the tutorials, I have NO problem with those examples. So the issues amy be size and color. In the tutorial, the font in the examples is smaller or the same size as the surrounding text and are mostly grey so they do not pull focus. In the Designing page, the font is larger and much more colorful. So I agree with Eric that we may be able to modify so they are not so attention sucking.

Kevin: I understand and mostly agree although I do not care for expand/collapse. However, the prospect of being able to add additional examples with expand/collapse is appealing.

<Andrew> +1 to more examples via hide/reveal :)

Shawn: Not sure why opposition to expand/collapse except for the fact that it is not especially elegant. Many like the images, some are opposed to expand/collapse, some are OK, some are distracted by examples, maybe need more visibility for text and less for examples...anything else? additional points?

Kevin: If I leave the issue open, I would appreciate any good examples of how to emphasize text, de-emphasize examples in terms of grabbing focus.

Shawn: The text size of the narrative should be larger and more attention grabbing than in the examples as a wya to de-emphasize.

<kevin> RESOLUTION: Explore an show/hide option for examples; explore providing additional focus on tip heading and/or description and less for the examples

Kevin: Will keep all this in mind.

Shawn: Thanks to all for commenting in GitHUb, editors have appreciated it. If you are not comfortable, feel free to comment in other ways.

Brent: Perhaps if we had another color, there is no font that is the same as the titles, it may help them stand out.

Shawn: Had we discussed making the h3s black?

Kevin: I am happy to try that.

<shawn> +1 to Brent to have the examples be different colors AND the h3 not orange

Shawn: And in many of the examples, you use the same orange as section titles in main text. That may help if it is a differnt color to differentiate from main.

Upcoming sub-groups

Shawn: Sharron and I have been working on these. The Showcase Examples with Video. We have reviewed and commented. These will take a lot of work and so we are suggesting a separate Task Force for that work.
... this allows a sub-group of people meeting and perform a lot of the background work. They bring that work to EO where it is reviewed, refined, and approved. Everyone would be invited to participate if you wish, but are not required to.

Andrew: People can work on the TF without being a fully contributing participant in EO

Shawn: Anybody who works on the TF is technically a participant in EO but is able to only focus on the TF work. Your time and input may be only on TF work without having to stay current with all EO tasks.
... We have a work statement in draft, will be refined and brought to the entire EO for comment next week. Any questions or comments?

Shawn: for the Showcase TF, Shadi will be the staff rep and Brent will be the Facilitator. Thanks Brent.
... if anyone else would care to co-facilitate or participate on the TF, you are welcome, please speak up.

<yatil> Props to Brent!

<shawn> [ /me claps and cheers for Brent! ]

Shawn: Next sub-group is focused on updating policy page. Started years ago, have defined tasks. Need to get shared understanding of what needs doing and then individuals will submit info that they find. Any questions comments concerns about doing this work without a formal TF?

Andrew: Glad that this is formally back on the agenda :)

Work for next week

Shawn: Reminder that the GitHub training is on Monday...Eric?

Eric: Don't be confused by the email that said it was cancelled. That was a fluke it is not cancelled at all.

Shawn: The Tips for Designing... will be updated with issues discussed today. For the most part then, we will be ready to review it all in their entirety and in detail. Remember you can fork and edit - that is a good way to comment. Batch suggestions so they can be accepted or not by the editor.
... anything else Kevin?

Kevin: People can start looking now if that is the time they have. I will collate resolutions and get to those on Monday. Design of examples will take a bit longer but that should not prevent you all from looking at text.

Shawn: Plan time, please on Wednesday for the next review. Any other questions or comments for today?
... thanks everyone, practice with GitHub and have specific questions on Monday for the GitHub training. Have a good weekend and we are adjourned.