Shawn: We want inital discussions today and since it is a holiday and we have several missing, we will not make final decisions today but will allow for review before finalizing

Showcase Taskforce Work Statement

Shawn: A few comments were left in the survey and Shadi replied. Brent did you see those?

Brent: I did and I think that was a perfect adition to identify specific resources.

Shawn: Kevin were your comments sufficiently addressed?

Kevin: Yes I am happy

Shawn: Concerns for discussion?

RESOLUTION: Showcase TF work statement approved

Quick Reference re-design

Shawn: We will get a summary of the finding and update from Eric.

<yatil> Findings from the UT June 2015

Eric: There have been a few considerations after the recent round of user feedback. I have analyzed for themes and threads in the feedback.
... in the end, I have seen there have been two groups - first are those who did not expect customization and did not find the controls to do that and second were those who DID expect to customize and so looked for and found the controls.
... People did not at all like for the navigation to move and scroll. This was quite different from our first round where people DID like that. Since we have such a difference, we need to think about this a bit and decide how to proceed.
... another major thing was using the checkmark with rotating hour glass. People did not find that to be intuitive. Need to think aobut how to let people notice that it updates.
... we have good information to process as we proceed. Because of the result of the column discussion, we have a prototype with a 3-column customization on the right and navigation on the left.

<yatil> https://w3c.github.io/wai-wcag-quickref/8

Eric: this is one that worked well for those who knew to look for customization but not for others. We have therefore created another prototype to draw more attention to it.
... so you can see in this one both options at the same time and want to try this out and discuss how it works and if it meets the need.

Shawn: Question on any of this...the user feedback? Eric got a lot of feedback and video and summary of issues posted to the wiki. Any intial thoughts on the latest prototype?
... first reactions?

Brent: I like the two tabs. One concern is the actual word "settings." People don't generally go to their settings unless they have a personal reason to. It is not a word I associate with filtering and that. But I do like the tabs - they are clear that they provide options, maybe that would be a good word to use.

<shadi> [[ filters? ]]

<kevin> [suggests 'Filters' instead of 'Settings' to tie in with main panel that has 'No filters set']

<shawn> +1 to like the 2 tabs on the left AND +1 to "settings" not best

<yatil> [[Edit?]]

<shadi> [[ filter, customize, options, ...]]

Brent: Filters could work since 2 out of the 3 things you do in there are filters, the other is tags. Seems better than settings

<Howard> agree filters better than settings

Shawn: In the other prototype what was the word used?

Eric: Customize

Shadi: Minor consideration was to keep words short since the menu is already quite broad.

<Reinaldo> Filters sounds better to me

Howard: I agree that settings is the wrong word, something you don't pay attention to unless you must.

<kevin> https://w3c.github.io/wai-wcag-quickref/8

Shawn: Look at link in agenda or IRC to see various options

<inserted> Version 3

Howard: #3 shows an extra column on the right. Did the user feedback prefer #8?

Eric: User feedback was indifferent about layout. What was most important was the mindset that people brought to the task. Their expectation was what dictated whether they found the customization options.

Shawn: I initally really liked version 3. There were others who did not and when we talked about it a few weeks ago, we had 2 points of view.

Shadi: What I understood from the feedback sessions was that #3 was most preferred by those who knew to expect customization. The issue really is that those who do not expect customization, completely miss it and have a hard time finding and using it. The use of the menu bar is very differnen than the customization bar, so with approach #8 we compromise to bring it to the attention of those who

might otherwise miss it.

scribe: there is a bit more to do, but our hope is that it will draw attention.

<shawn> "Filter" is an action -- myabe better than "Filters"

<Brent> "Filters" or "Options"

Howard: That makes sense and the layout on both is quite nice. Would not use Customize. A word like Filters or Search would be better. Customize makes me think that it would change the look of the presentation. Filters, search options something like that.

Shawn: Maybe "Filter" as a call to action. Need further discsussion of this point Eric?

Eric: No, I have a good idea how to proceed.

<Howard> or outline

Kevin: The menu label doesn't quite sit right. I think Contents is better.

<shawn> +1 to Contents

<Brent> +1 Contents

Shadi: Contents or Overview?

<Reinaldo> +1 contents

<Howard> +1 contents

Shadi: Reiterate that the TOC has a specific function as it scrolls with you, etc

Kevin: Clever Content

<kevin> +1 otherwise to the new design structure

Shawn: I like that you moved the from the center to the left. Something other than a checkmark?

Eric: Yes, will do that.

Shawn: And we may want to send out a survey. More feedback requests are coming soon.

Tips on Designing

<shawn> 'Provide visible controls for audio and video players' - should we have this tip? GitHub 54 https://github.com/w3c/wai-quick-start/issues/54

Shawn: Should we have this tip?

Kevin: The feedback is summarized as : No we shouldn't
... there were a couple of points about keyboard accessibility and focus but since those are covered elsewhere, seems OK.

Shawn: Any other thoughts about removing that Tip?
... objections to removing it?

Howard: I think that is too bad to lose it since accessible media players are a common problem that people have. It is a helpful tip. It is too bad it does not have a direct WCAG reference.

Shadi: I feel the same way. The one point that convinced me was the one that since this is a resource for beginners, how often will theybe building a media player.

Remove the 'Provide visible controls for audio and video players' tip

Shawn: Maybe we need a tutorial or WAI-Engage wiki page on that topic.

<shawn> alt text - should we have a tip on alt text in Designing? GitHub 25 https://github.com/w3c/wai-quick-start/issues/25

RESOLUTION: Remove the media player control tip

Shawn: Next question about alt text in designing...thoughts?
... Eric what about the perspective that the person who is creating the images and design elements is the most likely source of good alt text?

Eric: I think that is a different role. I think the alt text is more likely to be done well by authors, content creators. What is an actionable tip for a designer?

Sharron:I completely agree that thedesigner may not necessarily be the best person to provide good alt text. But I do think it useful to make designers aware of the general need for text alternatives to graphic content. What might be an actionable tip to do that?

Shadi: Most of the images we would hope would be in the CSS. More substantial images will come from content providers. This is not the highest priority for image. Issues most often arise from images placed by content providers.

<shawn> +1 to Brent - the people choosing the image should know that alt text is included

Brent: I understand that these designers are not necessarily the ones who will make the best alt text. The content people choose images, and should be the ones to understand the purpose and write alt text. But the designers should at least be aware that it is needed.

Eric: I see designers not as the one who choose content images. Main thing designers do is visual styling, layout, those kind of things. Designers do not usually do a lot of content images unless it is an infographic or something brought to them by a content provider.

Shadi: I can imagine them being focused on non-informative images, decorative etc. So the question is priority, how important is it?
... what is the reality in development situations?

Shawn: The key is the fact that there ARE very different development environments. That should be kept in mind as well.

Eric: If they have more than one role, they would read both writing and designing

Shawn: What about referring in Learn More rather than a tip?

<Brent> I am not strong either way about this one if in fact it is covered elsewhere.

Shadi: For the designers there will be mostly images that are decorative.

Kevin: A designer may not be limited to that. They may in the course of designing the entire site, use placeholder images, icons, etc

<shawn> +1 that "designers" will sometimes create/pick content images (not just decorative)

Shadi: One can be geared toward the design aspects and another to the informative aspect of images
... what is the priority compared to others.

Shawn: My personal perspective is that I don't feel strongly either way. Vicki has strong feelings that it should be there. There are certain situations where the person providing the images - not sure if it is quite low - but still important. Even though covered elsewhere, giving Vicki's strong feelings and Brent's mild feeling, we should address it. Maybe in the learn more section link to tutorials. Not necessarily an explicit tip but guidance to know more.

Shadi: I have similar feelings, I am becoming more convinced that we should put something in to refer to the need for text alternatives. That would be preferable to wedging into learn more.

Sharron +1 to Shadi

Shawn: So Kevin, giving some strong feelings are you OK with giving this a try?

Kevin: Vicki has provided suggested text...I am willing to work with that and take it from there.

RESOLUTION: Kevin will write a suggested tip based on Vicki's suggestion for alt text

Examples in general

<kevin> Examples Feedback Summary

Shawn: Here are two points, let's discuss

Kevin: There was a lot of discussion of the broad topic of examples that overlapped with the specific suggestions for individual examples.
... overall there are difficulties with how the examples are visually presented. There is scope to address that and I have begun a few experiments but not necessarily on target. Will try again with the feedback recently received.
... the other question was if the examples are usefu overall. I summarized and am open to correction if you feel I did not summarize accurately. I will go through them in order.
... provide sufficient contrast: bullets list in GitHub summarizes comments.

Shawn: Yes I wanted to present my perspective, but given Brent's strong claim that the examples are helpful, I am happy to let it pass.

RESOLUTION: Remove button example, look at grey-on-grey as a more common misuse of low contrast.

Kevin: There were questions about providing an example of text on a gradient. I will think about how to weave that into the discussion. Do people feel it should be added as an example?

Sharron: It is certainly a common error.

Shadi: We will not be exhaustive and unless we describe that issue, it may not be useful.

<Howard> I think we should keep it simple, leave out the gradient example

<Howard> +1 Shadi

Shadi: Tips should be simple, not try to make every point.

Brent: It is just bad design but what is more important is to show the concept directly and clearly.

<shawn> [btw, I think contrast ratio in the good example should be 7:1 (AAA) !]

Brent: to illustrate those things that they can completely understand.

Eric: We should mention the situation but not present another example. That level of detail is not what the Tips are for.

Shawn: My original position was that it is common, it is a design issue, it may be good to have an example, but not strong feelings and happy to let it go.

Sharron: +1 to Shawn

Shadi: We will tend to scope creep, so be cautious. This is not How to Develop...but Quick Tips. Be aware of that as you ask for things to be added.
... we should maintain a high threshold to add to these Tips.

<yatil> https://github.com/w3c/wai-quick-start/pull/55/files

Eric: It is appropriate to present the idea to a designer that text on an image has accessibility impact. If they only take away that idea - to consider that fact. It will make the sentence a bit longer, but it will be worth reminding them that there IS an accessiiblity consideration when they choose to put text on an image.

<shadi> [[ Text needs to have sufficient contrast between foreground and background colors, including gradients. ]]

<yatil> [[ Text needs to have sufficient contrast between foreground and background, including background gradients and images. ]]

RESOLUTION: Weave in the notion of text on images without adding too much text and no example.

Shadi: Each of the examples has its own border and background and takes up quite a bit of space. Is this finalized?

Kevin: No we will be looking at how the individual components of the examples are presented and return with an alternative.

Shadi: I guess it is good in one way to separate out the example that way and stand alone. But on the other hand, this makes it more attention grabbing and introduces cognitive challenge.

Shawn: There have been many suggestions about this and not sure what else is left for discussion.

Kevin: Saying "this will be fixed" is too strong right now since I need to come up with something that is less visually imposing.
... there are comments that the white space and borders need to change to stop grabbing all attention.

Shawn: Text size and colors

Shadi: So you are looking to make it more compact?

Kevin: Yes by reducing the number of them
... the comments that came round was that the presentation of the examples in general are too imposing, too much white space, colors, font sizes, etc.

Shadi: So how will you address those comments in this particular example.

Kevin: First the borders and yellow used to make the example stand out are too strong and white space and example text will be reduced.

Shawn: And taking out fake text and replacing with real?

Kevin: Not sure about that since there is a need for consistency in presentation of examples.

Shawn: My opinion is that if something can be clear and simple, it is OK to break consistency
... Shadi, did you get an answer?

Shadi: yes

Brent: One thing that bothers us all, the example looks like a button. Can it be made to look more like a snippet, one area, not two discete items that look like buttons.

<shawn> +1 to look like snippet from a real web page - instead of looking like buttons

Kevin: Next is not using color alone. Request was for simplicity, suggestions given.
... I prefer the idea of finding another example other than required fields in red. Will look for example that is simpler than pie chart.
... will suggest a couple for the group to choose among

<shadi> [[ not sure if you considered but maybe BAD can help here? ]]

Shawn: What will most effectively, most simple convey the jist of what is meant here?

Shadi: Could review the way it is presented in BAD

Kevin: OK will have a look at that.

RESOLUTION: Simplify the example (but ideally not required fields in red)

Kevin: next is to do with visible focus...summary in GitHub. Shawn your comment was that you were not at all sure what these were.

Shawn: Yes it confused me, the change in style seemed inconsistent.

Kevin: in the text?

Shawn: yes but again these look like little buttons rather than an example of text in the middle of a web page.

Kevin: Yes could put text around it to provide context.

Shawn: You could use the context of what you are trying to say to illustrate.

Howard: looks like example 2 and 4 should be switched?

Kevin: how do you mean

Howard: Image 2 looks more like a common hover state

Kevin: Image 4 is supposed to be a link that is clicked, may need a look that is completely dissimalr from the WAI style. The similarity may be adding to the confusion.

Shawn: Is it important to have a changed style for touched or clicked?

Kevin: Possibly, being conscious of what happens when an element is touched was raised. I can't think of a use case where it is of benefit.

Shawn: if not high priority and/or common, maybe we do not even need it here. Focus and emphasize the important thing. Having the other peripheral example may distract and confuse?

Kevin: For cognitive it could be very important.

Shawn: Don't you get feedback other than the flash of the touch? Like the page changes or something?
... and since we are trying to get the most important most common situations, maybe it should com out as an example.

Howard: The hover is very important. And the change of appearance of visited links is also important so I think these two examples should remain.

Shawn: I agree with those two. it is the activation one that I think may be distracting.

Shadi: I think this example is most important on a touch screen to indicate that I have selected the right button.
... however, I think the presentation overall could be much lighter, much more integrated. I don't mind keeping all the examples, but it must be less of a cognitive challenge in how it is presented.

Eric: I use touch screens and never notice the active state, never felt that an active state helps me.

<shawn> [ /me imagines the few touchscreens she's used... kinda nice, but not a priority]

Sharron: Are you saying the example could be omitted?

Sharron: I guess the question should be is the touched state example distracting from the more important point?

Eric: Yes, it's a very brief change in any use case and not much of an issue.
... if we could leave one out, it will reduce the cognitive challenge.

Shawn: The issue is whether having the touch example is of enough importance to be included in this example?

<Zakim> yatil, you wanted to (briefly) say active vs. focus on touch

<Howard> scribe: Howard

RESOLUTION: Address clarity of captions, change styling to be different from WAI styling for examples, change general styling of example boxes, put links in a contextual paragraph.

<shawn> sub-topic: Ensure form elements include clearly associated labels

Kevin: feedback that bad example for label on forms to extreme...

suggestion to have more interesting bad example. Willing to do this if provided...

scribe: suggestion for radio or check-box to show positioning.
... may drop bad example if can't find a good 'bad' example...
... some styling issues will be addressed.

Shawn: Someone pointed to nielson-norman group for bad example.
... someone suggested placeholder text as bad example.

Kevin: that as an example could be problematic.
... happy if someone could come up with good 'bad' example.

Sharron: may have one that I will send.

Kevin: next issue - provide clear feedback.
... has come up with a couple of commits to address some of the issues mentioned.
... next issue - create different designs for different viewport sizes.
... started with ability to change font sizes and evolved into responsive design.
... comments more about success criteria related to this and if the SC were appropriate.
... some discussion on mobile display vs. desktop display.

Shawn: How much of this is design vs coding issue?

Kevin: will open it up for comments.

Shawn: agree, comments more at tip level than example level.

other tips examples

Shawn: important for EO to agree on the concepts of the existing examples before going onto examples for other sections.
... before Kevin spends time on creating those images.

work for next week

Shawn: if haven't completed the weekly survey, please do that.
... should do thorough review of tips for designers.
... Current survey is a required survey so all active participants must fill out.
... If done all that go ahead and review rest of pages - writing, evaluating, etc.

Kevin: for the tips, if it doesn't have an example or idea for an example written in, means I don't think one is needed.
... but feel free to suggest one if feel it's needed.