Shadi: We have an agenda, thanks to all who participated in the weekly survey, please remember that there is another one for the Development Tips, open until Tuesday. If you have doubts about using GitHub, go ahead and put it in email or the survey and don't be stopped from commenting by the GitHub, please.
... not many comments in the weekly survey, Kevin anything to add?

Kevin: No there were not many additional comments in the survey, we do have a few things for discussion.
... may not need to do screen sharing today.

Shadi: There are a couple of points on the QuickStrt Tips that need discussion. Kevin will go through these six items.

Quick Start Tips

Kevin: The various points for discussion are linked from the agenda...

Shadi: So from the agenda if you link to the QS-Tips, you will find the intro paragraphs to review. We will have it on the survey but if there are any quick responses now, please share them. Otherwise, it is an item for consideration for your input and thoughts for next week.

Kevin: Next item was to highlight a change we made to the icons. I have gotten around to putting those in place. The designing one is the most changed, but the megaphone for Advocating has also changed a bit. The main thing to note is the slight difference between how the Designing icon is rendered in different sizes. The smaller one omits a bit of the detail.

<davidberman> the icons are delightful and clear: well done!

<Andrew> I also like the latest icons :)

<Vicki> looking good, Kevin!

<AnnaBelle> I like the two versions of the design icon. Makes sense.

Kevin: any immediate thoughts or comments are welcome, otherwise, feel free to bring it to GitHub

<Howard> looks good to me

<Brent> I really like the addition of the double arrow in the small navigation on each topic page.

<Howard> I did notice that tabbing through the icons there are parts where the visual feedback disappears

<shadi> Howard, can you please add a github issue or send it by email to kevin?

Tips - Learn More section name

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

Kevin: There has been some discussion about how to refer to the Understanding link. That led to consideration of the naming of the entire section. Learn More was felt to be a bit distracting and less than accurate.
... to avoid the misconception that this will take you deeper into Tips rather than what it actually does, which is to link users to external resources. The term Related Resources was suggested and has seemed to gain a reasonable amount of support. I wanted to raise it here to see if anyone had thoughts about the renaming or any objections.

<Vicki> +1 Related Resources

<davidberman> Related Resources: I am pleased with how the discussion sorted out on this. I'm +1 on "Related Resources"

Shadi: So the proposed Resolution is to change the title of the section from "Learn More" to "Related Resources"

<AnnaBelle> +1 related resources

Andrew: And since they are all w3c resources, this works very nicely

<James> +1 related resources

<George> +1 Related Resources

RESOLUTION: Change title of "Learn More" sections to "Related Resources."

<davidberman> second

<yatil> +1 good for me (liked the human touch of learn more but this is more precise)

<Andrew> +1

Shadi: Then to discuss the content of each section

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

Kevin: There were some suggestions in GitHub about what we should actually link to within the "Related Resources" section.
... these discussions led to questions about how the sub-sections are ordered as well as what exactly we want to link to. There were ideas and some historical references to people not wanting to be thrown into the deep end of the standards. There then arose the question of whether to link to the TR document itself or the QuickRef.
... the other aspect was what we need to point to and presenting them in a way that is clear and consistent. I have put together a couple of examples based on input.

<kevin> http://w3c.github.io/wai-quick-start/designing.html#provide-sufficient-contrast-between-foreground-and-background

<kevin> http://w3c.github.io/wai-quick-start/designing.html#ensure-that-form-elements-include-clearly-associated-labels

Sharron: Both of them link to the TR?

Kevin: No, they link to the QuickRef and the Understanding docs

Shadi: So we are not linking directly to the TR document or the Techniques but to the Quick Ref and/or to the Understanding. Kevin also was working on the titles of the sub-headings for clarity and consistency. We want people to start using the QuickRef and expect this document to get them there.

<Andrew> I like Kevin's proposed sub-headings as shown in the two examples

Sharron: +1 to Andrew's comment

<Vicki> +1 for the approach

Andrew: Much clearer than what we had previously. People will know what to expect, I think this works quite well now.

<George> +1 for the concept/approach

<davidberman> +1

Vicki: I also quite like this approach, simple and clear.

<yatil> +1

<James> +1

<Howard> +1

RESOLUTION: Accept the changes to the sub-headings, link targets, link names as illustrated in the two examples.

<davidberman> second

Tips - WCAG acronym expansion and linking

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

Kevin: This was a point raised by James, forgive me if I mangled your concern when posting to GitHub. James did some quick usability testing and found that the expectation when activating the WCAG link in the intro was quite different that the actual performance. The other aspect is where to put the expansion of the WCAG acronym. It is found first in the DOM in the side panel (where it is expanded) but in the spot where it first appears visually in the intro, it is not expanded.

James: Yes you have described the problem and when I tested with folks I work with they were not expecting to be moved into the side panel.

<Andrew> I would have intuitively expected to link to another page too

Shadi: The WCAG acronym pops up all over the page. Rather than expand every occurance it was suggested to have a side panel that gave a brief description and link to About WCAG. The idea was not to expand in the intro to save space and avoid distraction. Also it was an attempt to get people used to thinking of it as WCAG.
... the pros and cons: cons are the risk of disorientation and the fact that it is not visually the first; pros are that it is less distracting and makes people aware of WCAG as a referent.

Eric: The problem is that the page jumps, when you are reading in the middle of a paragraph you are jumped into the navigation and it would be startling. We could just expand it in place, I don't think it will add so much distraction.

<Howard> agree with yatil - focus would help

<yatil> #wcagbox:target {transform: rotate(1080deg);}

Shadi: Play around with the styling of the link to make clear that it is another kind of link.

Andrew: I would not be in favor of expanding it in the intro or would prefer to send users to the WCAG Overview directly.

Shadi: In the source code, the intro is just before the first h1.
... the way the focus moves, you are not sure what you are looking at.

<Vicki> +1 James. I support the argument of James for expanding WCAG

James: I think the idea of doing something with the sidebar would resolve the usability issue. People really may NOT know what WCAG is and we need to model the fact of the best practice of expanding on first view and properly nesting the headings.

Shadi: If we have the WCAG expanded in the intro, we would keep it linked as well and look at a different styling for the link. Would that resolve the issue in your mind or do you think we should remove the link altogether.

<davidberman> +1 (we need to eat our cooking!)

James: We should not have to change the styling just because it is an in-page link. We need to do more testing of that, but should expand becasue it is the first instance.

<Andrew> +1 (convinced to expand in intro to 'eat our own dogfood')

Howard: I hear James' arguement, but I agree with Shadi and Eric, that the solution of the focus issue would solve that. I appreciate that it is an in-page link. I would not be in favor of expanding the acronym although I am open on the issue.

Shadi: WCAG does not require expansion on first mention but our tip does say that.

<davidberman> G97 recommends it, and so we should find a way of elegantly doing so.

Shadi: It is a killer arguement to me. But the focus issue that Eric raised may be a separate issue. For now, we should resolve this. Proposed resolution is to expand WCAG in the intro paragraph.

RESOLUTION: Expand WCAG acronym in intro paragraph

Shadi: Do we no longer need the link since WCAG is expanded in the intro?

Sharron: +1 for not needing the link

<George> +1 for not needing the link

<Andrew> good point - maybe not needed

Howard: I would lean toward linking to it. It does no harm and leads to more information for those who need it.

AnnaBelle: What I keep looking for in the side bar, is a link to WCAG
... my natural assumption is that I would be taken straight to the actual specification.

James: Everyone I tested yesterday expected the same.

David: We cannot rely on the About WCAG telling people what WCAG means unless the "About WCAG" comes earlier in the meaningful sequence. And it does, so I think I've just been won over by Annabelle and so I agree that we don't need to spell out WCAG after all.

Kevin: Part of the reason for this was that we had SC everywhere, and WCAG everywhere. We felt that we needed a strong, clear pathway to explain those things. It may be that since we have fewer of those SCs littering the document and we have the WCAG expansion in the intro, we may not need the link.

<davidberman> ... because we already have, earlier in the meaningful sequence.

Shadi: Howard, I think you and I are the link champions, where are you currently in this? For most users, the intro paragraph will come before the side bar.
... so the question is whether to maintain that link?

Howard: I think either way is fine, no objections, will go with consensus. I like the sidebar and would be sure to want that to remain on the page. It is short, concise, clear but whether we link to it or not is fine with me.

<Vicki> I would also keep the sidebar. I would modify the text in the intro. There doesn't necessarily need to be a link in the intro.

David: I am won over to the idea that we do not need the link to the side panel. I do not think there is a need to link it, but am fine either way.

<Andrew> suggest: expand / no link

<yatil> +1 remove link, expand, keep sidebar, relax.

James: I too can go wither way. However if we do keep think, we have to think about focus and styling. If we remove it, however we don't have that consideration.

<AnnaBelle> +1 remove link

<Vicki> ;) +1 relax re yatil

Proposed resolution: Remove the link to WCAG side bar in intro paragraph

<davidberman> second

<davidberman> +1

<Brent> +1

<Andrew> +1

scribe: objections?

<yatil> +1

<Vicki> +1

<George> +1

<Howard> +1

RESOLUTION: Remove the link to WCAG side bar in intro paragraph

James: We have an h2 before an h1 here, do we want to consider it?

<shadi> [[It is good practice to nest headings properly. When stepping down through headings, skipping levels should be avoided. That means that an <h1> is followed by an <h1> or <h2>]]

Sharron: Headings was a big topic at AccessSummit, the online set of talks by Environments for Humans. David McDonald did a talk on WCAG and when the subject arose, he was pretty clear that the order of headings is trivial. Most people seemed to agree. More important issues are the need for headings in the first place, use of just one or two h1's, and the need to avoid overusing headings. But by David's interpretation, this is definitely not a WCAG violation.

Andrew: Yes, it is good to remember that this is best practice not a strict requirement

Shadi: This is a very common discussion and is something that people get dogmatic about. Even in the tutorial, it is a best practice recommendation. The quick tip can be read dogmatically or interpretively. In the case of the tutorial, it is in draft and so dog food is not yet involved.

Eric: The tutorial explicitly does not say that you must start with an h1, it references best practices and says you can move up. You can be consistent with the tutorial and still have an h1 after an h2

<Howard> +1 to Eric's pov

David: Regarding this issue, we really should not be telling people to do this. In PDF UA, this is demanded, it is required. In web dev, it is just confusing. This is an opportunity to clarify. Both in the tips and in the tutorial that this is a poster child of what confuses people.

Shadi: It is a great point, was also an implication of WCAG1

<yatil> ACTION: EricE to clarify headings in tutorials regarding starting with h1 or h2. [recorded in http://www.w3.org/2015/09/11-eo-minutes.html#action01]

<trackbot> Created ACTION-331 - Clarify headings in tutorials regarding starting with h1 or h2. [on Eric Eggert - due 2015-09-18].

David: I would prefer the point of not having content that precedes a heading. So that content does not get buried.

Shadi: I think this should be considered for the tutorials not the tips.
... the tips are not meant for that level of detail.

Sharron: +1 not that level of detail to the tips

<George> +1 not that level of detail to the tips

Howard: I agree with what was said by Eric and David.
... this comes up for me as well as consideration of the logical vs the visual presentation of the heading structure.

Sharron: We should look at it in the Easy Checks as well.

AnnaBelle: Yes, good thing to do for consistency.

Kevin: Thinking about David's conmment and seeing about moving the sidebar to come after the h1.

Sharron: But wasn't the point also made that as long as there is a heading associated with the sidebar content, the order is not so important. This is more about not stranding any content completely outside of the heading structure.

Shadi: One more point not in the agenda...Kevin?

Tips - Presentation of example captions

<kevin> http://w3c.github.io/wai-quick-start/designing.html#provide-easily-identifiable-feedback

<kevin> http://w3c.github.io/wai-quick-start/designing.html#dont-use-color-alone-to-convey-information

Kevin: Last week we looked at how the examples are presented. One concern was the captions are too much blended into the example itself. To explore this, I wanted to give others a chance to review and look at samples...

<Vicki> +1

<Howard> +1 to outside the box

<Howard> +1 to caption outside the box

Vicki: I like the way it is handled in "Color Alone"
... I found that within the box it seems hidden, I don't really understand that there are two, this mkaes it clearer that there are two parts.

<Howard> Clearer that it is not part of the example itself when outside the box.

<Andrew> +1 to outside box

<George> +1 outside of the box

Kevin: It would sometimes depend on the type of example there are. When there are two parts, the caption differentiates.

<yatil> +1 outside the box w/ spacing adjustments (heading too far away from the box, imho)

AnnaBelle: I really like both of them but I tend to prefer the caption outside of the box. It is a bit of apples and oranges since they are not the same type of examples. I like pulling the example title pulled out but it seems squished, would like more breathing room, white space.

Kevin: Channeling Shawn a bit, she wanted it brought more together and less obtrusive.

Shadi: Want to keep them together so the relationship of the two are clear but also want the titles separated enough to understand that they are not part of the example itself.

<AnnaBelle> I'm in favor of outside the box as long as there is a bit more white space. Inside the box I think the white space is probably not as much of an issue

<shadi> +1 to AnnaBelle

Brent: I agree with the outside the box for captions. What should be "inside" the box is only what you would actually see on the web page.

RESOLUTION: Kevin will take feedback and work on the concept of "outside" the box for the captions.

Kevin: I managed to sneak into the captions a couple of small icons of a tick for correct and a cross for incorrect.

<Vicki> +1 for x and tick icons

Shadi: Yes those will be in the survey that will open later today.
... as well as thorough review of Developing by Tuesday.

<yatil> I like check and x, too :-)

Shadi: any other questions, comments on QuickTips?

QuickRef

Shadi: Eric has been working on this for the last week and over the summer. I am *really* excited about this. Eric will re-orient us to the resource and there will be questions on the survey.

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

Eric: There is the link and you will notice that much has changed. We have put real data, all Techniques, it is now a huge document. Therefore the performance is improved to be smoother, the Principles are presented more clearly...

<Vicki> wow. great. looking so much clearer.

<yatil> http://www.w3.org/WAI/WCAG20/quickref/

Eric: comments in GitHub have been addressed and we will bring the results back to the group for discussion. The current QuickRef has a huge introduction and keeps you from the actual stuff you want. I would like to bring the actual SCs and Techniques to the user more quickly.

<yatil> https://github.com/w3c/wai-wcag-quickref/issues/27

Eric: having very distinct blocks of information is something that I am asking about in the survey, how to organize the blocks of text. I have created a place to collect your thought on that in GitHub.
... Not this week, but next we will review the text of the SCs themselves and get a proper taxonomy of tags (along with WCAG-WG)

<yatil> https://github.com/w3c/wai-wcag-quickref/wiki/tagging-success-criteria

Eric: I have tagged them you can review that and created a way for you to review these associations and see if anything is left out, mishandled.
... many tweaks for the functionality, filtering options, deselect all, more.
... making the interaction more coherant, easier to understand. Am experimenting with Share this View which will take your current filtered selection and share with colleagues.

<AnnaBelle> This is amazing. Thanks so much!

<Andrew> looking really good Eric - excellent work :)

<George> Amazing work!!!!!

<davidberman> +1

<Vicki> Absolutely fantastic

<Vicki> ;)

<James> ?

<AnnaBelle> I also like the way you're centralizing places for feedback in github

Shadi: There will be more things to put in there, usual disclaimers to keep the cat out of the microwave. I think the idea of having the info categorized is a good idea so we can tuck things away as needed. The input from you are what are the most improtant things to say?
... what are the key points, look at previous QuickRef and notice the points we need to cover. As this evolves, we will ahve more specific questions about it. Now we are looking for general overview kind of review.

<inserted> /w3c.github.io/wai-gh-training-2015-06-29//Topic: Github Training Video

<yatil> http://w3c.github.io/wai-gh-training-2015-06-29/

Eric: The GitHub tutorial seems for some reason not to play on Chrome. It is a captioned file and works well everywhere else.

Standard reminders