Introduce new participant James Green

James: Met several of you earlier this year at AccessU. I work at VISA working in accessibility and usability, shared service and raising awareness across the company.

Tip Examples

Kevin: Asked for suggestions about what the examples might be. Great feedback from several people. Shawn and I have gone through the feedback to determine how to respond.
... I have updated the GitHub with our responses. If you feel that I have closed too early or without due consdieration, let me know.

Shawn: Any comments or questions, points of discussion?

<Vicki> bravo, Kevin

Shawn: The examples appear in the draft document as Kevin is working on them. There is a GitHub issue for each example. If you need help finding - go to issues and look for a specific tag, such as writing if that is the one your want to comment on. Ask Sharron or Kevin for more help if needed.

Writing Tips

<shawn> https://www.w3.org/2002/09/wbs/35532/EOWG24July2015/results#xq1

Shawn: Thanks to everyone who rated the tips. For those who have not done the survey yet as well as those who have and may wish to update
... We also have the question of whether readability tips should be separated (making 10/11 tips) or combine them (making 7)
... shall we determine that first?

Writing Tips, separate or together?

<shawn> https://www.w3.org/2002/09/wbs/35532/EOWG24July2015/results#xq3

Brent: Originally I wanted separate tips, but when I saw how he laid out the example, each sub-tip seems clear and can be understaood. The example was excellent and drove home the clarity of the "good" version. They all seemed to work well together. But Kevin has strong feelings and I want to hear his perspective as the author.

Shawn: The page with more detail.

<shawn> http://w3c.github.io/wai-quick-start/writing.html

Sharron:I was not clear why we wanted to reduce the number. But if that is the priority, could possibly combine some but not all of these. Worry that if all are combined, some points maybe lost or minimized.

Shawn: One of the goals was not simply to reduce the number but to actually make the points stronger together by grouping similar concepts... and by contrast the others outside the grouping have more distinction and greater clarity

Howard: I think the way they were put together as a group is very nice. The example is great, really demonstrates the issues. Especially the breaking up of text. The example was done really well and can see the advantages of putting them together.
... I think the 4th bullet "use list formatting..." should be rephrased. The line is too constraining.

Kevin: I worry that without more specifics it becomes a bit circular.
... could you send me you ideas, Howard?

Howard: Break long blocks of text into bullet points when appropriate or something like that...I will think and send more ideas.

Shawn: lists rather than prose or something like that.
... let's accept that one may need more processing. Andrew may have ideas as well.

Vicki: I feel that these really are stonger together. The examples for each could be incorporated into the paragraph and that the ensemble is powerful and becomes quite a strong statement.

Kevin: I feel as though the title of the tip does not convey enough information. There is so much hidden within the title, it is not as clear as the others. The title of the other tips allow the user to almost get away with not reading the tip.

Shawn: I get that last point. But when they are separate, there seem to be so many things going on it is not as clear. We considered having separate tips but having them grouped. We may need to revist that idea as well for the Developing Tip
... when they are grouped they become easier to understand. Because these are all related, it seems easier to grasp when the relationship is explicit.
... Kevin would it be useful to discuss any of the individual ratings?

Kevin: Can't really do that until we decide on approach.

Shawn: OK any other comments on the Writing Tips?

Developing Tips - approach to ordering

<shawn> https://www.w3.org/2002/09/wbs/35532/EOWG24July2015/results#xdevorder

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

Shawn: There are very different opinions here. Any additional thoughts for the question of ordering the tips?

<shawn> Easy Checks TOC with subheadings http://www.w3.org/WAI/eval/preliminary#toc

Shawn: I want to point to the EasyChecks
... we have categorization as a way to group the items. This may work with the Writing Tips as well and perhaps the Developing Tips to group the specific as distinguished from the more general.
... if the Tips had some kind of group association I might be more comfortable with the order that others have suggested. What does the group think about grouping?
... for example, one possibility might be in the Writing Tips, there were all the other Tips then a sub-heading Readability with the related tips below that.
... in Developing there could be a category for general and Specific.

Howard: When I first looked at EasyChecks, I did not know what you were talking about, don't know if I ever noticed them before. Nevertheless, it at least breaks up the long list whether you consciously notice the words themselves or not. I see an advantage in simply breaking up a long list of text into more manageable pieces.

Vicki: It could be helpful, it is an interesting idea. It is a quite long list and breaking into sub-categories could be useful.

Lydia: Yes I like the groupings, saves on scrolling. Making a decision about what to look at becomes easier.

Sharron:I didn't notice categories in Easy Checks either. They break up the list and make it less daunting without being obtrusive

Kevin: There are a few things where my personal views tend to trip me up, such as what are these categories? I was never sure about how these things helped me - for example, what does General mean?...I wonder if the lables of the categories are useful - are they really providing anything other than spacing between the groups?
...How would we ensure consistency across the different sets of tips if we start making sub-categories? It will be peculiar if only one or a few have these. What problem are we trying to solve? is it the number of tips or the ordering? Just grouping them will not necessarily change that.

Brent: I like how they just march down the page ungrouped. As long as they don't go below the fold. Rather than grouping them in categories, I would prefer to consider the order without grouping and breaking the consistency with other Tips.

Shawn: In what we are talking about for both Writing and Developing, I think the labels will help even if some people mask them out.
... I understand the need for consistency however these are focused on specific roles and people may not look at all of them so consistency becomes less important. I think grouping would definitely help with ordering in Writing and Development Tips but if grouping is not needed on others, we should not do it.
... let's go back then to the general question of order. Sharron, Brent, and Andrew commented. Anyone today want to add thoughts to that?

Kevin: I am not sure how much of an issue the order is for the reader. I wonder despite the fact that some are big picture and others are more specific, how users actually will read and apply what they learn. people will be at various stages of development. It is meant to be short enough to read in one sitting and so I am not sure that where readers are in the project is relevant to the order.

Shawn: How does that affect your opinion about the order?

Kevin: I am not convinced that where the specific Tip should be considered in the order of the project is relevant to the order they are presented in the document.
... personally I would start with the easy things and work up to the harder.

<Vicki> like big picture first too. but more I look at it, more I think some grouping would be helpful for this particular list.

Sharron:I get the Kevin's point about easy first. I'm OK with the other order. For me personally, I like the big picture first, before the little details. But if others want the details first, I'm not going to insist. If we want to make resolutoin to start with Easy, and the go with big picture, I'm OK with that. I'm happy to go with consensus.

Brent: I completely agree with the perspective of the big picture first moving into specifics that Sharron expressed. But in this case, the Quick Tips are meant to help people have some quick successes and build confidence. They will feel that they can understand and implement

<shawn> +1 for Brent -- agree with sharron that in some cases, best to start with big picture. however, this is getting started tips. and so for this, the very first ones should be easy. I can understand this!...

<kevin> Requirements: https://www.w3.org/WAI/EO/wiki/Quick_Start_Guides/Requirements_Analysis

James: Agree with Brent, I had earlier said we need to give people the why behind the tips. But hearing from the group that these are QuickTips, that is precedent for not starting with big picture things here.

Lydia: I like the big picture first as well. If that is presented at first, they can work back down.

Shawn: Sharron has said that she is willing to put aside her personal preference for group consensus

Lydia: When I do training, I start quickly with the big picture and move to the specific.

Shawn: Yes, that would be the approach in a training situation. However, here since these are Quick Tips are you OK with starting with the easily achievable things?

Lydia: Yes I am OK with starting with easily implemented tips and moving up to the general.

Shawn: Propose to order the Tips in general from easy to more difficult

<Vicki> +1

Shawn: any discussion or concerns with that proposal? objections?

RESOLUTION: In general, the Tips will be ordered from easy to achieve to the more difficult, conceptual tips

Development Tips, rating

<shawn> https://www.w3.org/2002/09/wbs/35532/EOWG24July2015/results#xq2

Shawn: Looking at survey results...
... we have more variation with these than others. Kevin, what will be useful for people to consider going forward?

Kevin: It becomes quite challenging to determine which is more useful than another. What will a developer just getting started find to be most useful? Are these quick and easy, will it add to their understanding, will it improve the accessibility of the deliverables?
... these are the questions we should consider to bring the number down to around 10?

Shawn: We will be asking people to consider grouping or culling from these tips?
... so think of maybe we can get rid of this because of that. If we want to include fewer tips how might we do that?

<Brent> Could the two Code tips be combined?

<kevin> Considerations for potential tips:

<kevin> How relevant is this tip to the purpose of this resource? (getting started tips, not comprehensive guidance or even the most important things)

<kevin> How often do you think that this issue occurs in practice?

<kevin> How much of an impact does the tip have on real-world accessibility?

<kevin> How relevant is the tip to this task versus other tasks? (e.g., Designing versus Writing)

<kevin> What is the priority of this tip related to the other tips?

<kevin> (From https://www.w3.org/WAI/EO/wiki/Quick_Start_Guides/Requirements_Analysis#Criteria_for_Tips)

<Vicki> +1 sharon

Sharron: I would consider getting rid of Tips by considering 1. If they are not that common. 2. How easy understand? How do they map to WCAG?

<Vicki> +1 to Sharon

Shawn: Any other thoughts on what criteria we might use?

Sharron: Code validates, ensure compatibility of code are commonly covered in general coding practices, they don't map as clearly to wcag; ... also language

Vicki: Language is important and easy to do

<Lydia> concur with vicki

Sharron: good point, I withdraw the language one

Kevin: How much does the language tip affect real world accessiiblity?
... it is very specific.

Vicki: It does affect how the screen reader pronounces. If you change within the paragraph it does make a difference. At the UN it makes a great difference. And again, this is a tip that is very very easy to do.

Shawn: Great perspectives, any other thoughts about what might be dropped?

Lydia: Web testing with an automated tool, it will fail if language is not declared. Not sure what it means to use progressive enhancement.

Shawn: I was going to ask about progressive enhancement these days

Sharron: Maybe combine progressive and adaptive into one tip?

<shawn> [ shawn agrees they are different things... although I'm not sure if "progressive enhancement" is an appropriate tip for this getting started tip]

Kevin: My understanding is that reponsive uses media queries to present content in a different way for various vewiports. Progressive enhancement is more of a coding approach that encourages the developer to start with basics of content and function, making sure that everything works in a basic platform. Add to the basics with styling or scripting, content retains the basic function and the layers will enhance it.

Sharron: Yes, good distinction.

Shawn: Do we have "Learn Mores" for that?

Kevin: no

Shawn: Without that can we have it as a getting started tip?

Kevin: It becomes problematic

Jon: We should not get rid of it until we look for Learn More resources.

Shawn: OK but keep in mind that we try not to link out too much to other resources that may not be stable.

Jon: we could write something?

<Vicki> Can they be combined? How do we map them to WCAG?

Sharron: (to Vicki) 4.1.1

<Vicki> Can the design approaches be combined into one tip?

Jon: Let me think about a good one liner and best practices, to delineate it from the others. Give me an afternoon to come up with a suggestion.

Shawn: Kevin, can you add under Learn More we need to find a reliable link to more about Progressive Enhancement?
... others to not include?

Vicki: Can we combine those two design approach Tips into one more general?

Shawn: Kevin, maybe we can think about the common purpose and how we might combine them?

Kevin: Challenge will be that there is much that separates them and an example might be hard to come up with.

Sharron: About code oreder that reflects reading order - I'm not sure it is phrased properly but the concept is important to accessibility.

<shawn> +1 that it's not phrased properly

James: It is related to Progressive Enhancement, may need to be presented differently but it is important.

Kevin: So we could connect Progressive Enhancement to this?

James: Developers who are new to accessibility tend to think of themselves as the user, how they themselves act and how they perceive. PE says don't assume everyone uses the same tech. Responsive says don't assume about the veiwport. So there is a thread of commonality.

Kevin: I like the adopt responsive design tip because it is current, this one has a validation effort as well and evaluation consideration.

Shawn: I don't think so, it is not check at the end, it is how you design from the start.

<shawn> reminder survey link: https://www.w3.org/2002/09/wbs/35532/EOWG24July2015/results#xq2

Kevin: I took a mathmetician's perspective and ordered them along the scores. The ones that dropped off the bottom were CAPTCHAs, PE, etc (see link)

<kevin> Use progressive enhancement 3.40

<kevin> Provide meaning to non-standard interactive elements 3.33

<kevin> Ensure that CAPTCHAs have accessible alternatives 3.33

<kevin> Ensure compatibility of your code (see discussion at GitHub 118) 3.00

<kevin> Reflect the reading order in the code order 3.43

<kevin> Check that your code validates (see discussion at GitHub 154) 3.43

Brent: I caution against using this rating approach since only 7 people responded.

<kevin> +1 to Brent

Shawn: Yes, this is only a preliminary discussion. The idea was to try to get an idea of where things were falling. I encourage everyone to reconsider and go back into the ratings

James: I see developers do cool things using custom controls so I think it is important to remind them to name them correctly so it will work for all.

<kevin> +1 to James

Work for Next Week

Shawn: Open until next Wednesday, please think careful about answers. Be brutal in your ratings since we want to cut some of the developing tips. We shared perspectives on why things might be cut. We have some open GitHUb issues where you can add info. Kevin, do we need to add links or add issues?
... if I am looking at non-standard interactive elements and want to add a comment where should that go?

Kevin: In the survey for reasons why an item should be culled.

Shawn: Wanted to let folks know that there as been a suggestion to add an item to EasyChecks and we will be bringing that to EO as well. Any other questions for now?

Shawn: welcome James, thanks all, happy weekend, adjourn!