Shawn: We have a few specific items on the agenda and it is likely to be a short meeting.

Quick Start Tips

Shawn: Let's start by looking at titles

<shawn> first page: http://w3c.github.io/wai-quick-start/index.html

<shawn> survey results https://www.w3.org/2002/09/wbs/35532/eowg25052015/results#xq7

Shawn: Kevin, have you made changes based on this?

Kevin: Yes, the title changes from Vicki are the ones I chose to put in this draft with some minor changes. We can consider these, happy to change

Shawn: Thanks to everyone who put their ideas in the survey. I suggested that Kevin choose one to put in place but still open for discussion
... if everyone will skim the suggestions and then we can discuss

<shawn> [also, kevin, for "requirements" do we want to provide a printable version (possibly just a print style sheet)

Sharron: This makes good sense to me. Vicki's suggestion was a good one, navigation and page titles match as Melody noted in the survey.

<kevin> Can do a print style sheet

<shawn> [wayne's students were gonna do one ages ago but never got to it :/]

Shawn: Wanted to note that people will focus on just one of these docs based on their own area of expertise and interest. We hope people will be sharing these and if so, do we want Quick Start Tips to be prominent in the headings?

<Howard> I think that makes sense.

Kevin: I wanted to check with you Shawn about what you mean by putting Quick Start Tips prominently in the heading...I have created side navigation that says Quick Tips are also available on...(other topics)

Shawn: Yes I saw that and appreciate that, but in the title do we need to echo the "Quick Start" verbiage to reiterate the fact that this is only a start

<Brent> No

<Andrew> no

<shadi> +1 to shawn

Andrew: We want to keep the headings precise, I don't see any value in adding "Quick Start" especially since it is elsewhere on the page. We don't want to overload the title

<shadi> [[Quick Start: Design Tips]]

Vicki: I agree. The side navigation is sufficient to provide that consistency.

<shadi> [[in response to AA: title seems too long IMO]]

Howard: I am not sure that I disagree exactly, but I am not sure there is enough to indicate that it is one connected resource. If there was a logo or something to subconsciously remind people of the interconnection. But I understand the point about not overloading the title as well.

Paul: I agree with Andrew and Vicki to not overload the title

<Andrew> [[[Quick Start: Design Tips] - that title does not make it clear which type of designer]]

<shadi> [[and that's a good thing! ;)]]

<shawn> Quick Start Tips: <br/>

<shawn> Designing for Web Accessibility

Paul: I think we SHOULD add Quick Start when sharing via social media, email, etc.

Shawn: There is a plan to put a short intro on each.

Howard: Even if there is something just below the banner, a stylized indicator that this is one of the QuickStart Tips that would indicate to people that it was part of a suite of docs

<shawn> Designing for Web Accessibility - Quick Start Tips

Kevin: My concern was to front load with the key word or concept for scability, and not lead with a repetitive phrase.

Shawn: Yes on the Overview page. But if you are sharing just a single one of these, it may important for Quick Start to actually be deliberately frontloaded.

<shadi> [[what kind of designer would absolutely not benefit from the "designing" tips page? what is the level of noise in making the title overly precise vs making it short and more catchy?]]

Andrew: I was going to say something similar about front loading - do we want to lead with who it is for. If we have a brief description we may have more thoughts about what the title should be. Not sure what we want if it becomes a landing page on its own.

Shawn: So let's think about that...how will people find this?

<shadi> [[especially concerned about "front-end" and "champion in organization" limiters, btw]]

Andrew: Will probably not get there by landing on current overview page and navigating through.

Lydia: I like the short titles and how it is broken out, short and catchy that leads people to just what they need for themselves. I think people will get there from a search - designing for accessible web pages - or something. Many of them will be looking for accessibility resources specific to themselves and their own role.

Shawn: One of the things to think about in the title then is SEO so people will find it and click on it...quick start probably not good for SEO but good for drawing attention. Shadi has mentioned that there is too much stuff in the title, we need to think about that for a bit. Anything else on SEO?

Vicki: Think people come through search engines, so titles are important. You search for things pertinent to your search. It is important to make clear in the search result that this is the information you need.

shawn: I think accessibility gets lost a bit...

... BTW: Wayne has mentioned that they would benefit from not having the WAI side nav.

Shawn: Kevin, do you need more info to proceed?

<shadi> [[Quick Start: Tips Accessible Design]]

Kevin: There will be a need for more input to come, but would I be wrong to say they are OK for the moment?

<Andrew> +1 ok for now

Howard: Can you summarize what we decided?

Shadi: I find some of the titles overly, unecessarily restrictive. For example, why is "front-end" in there, seems Ok for all developers. Adovacy may be internal but may also be external to an organization. In making the titles longer, we are making them restrictive in a way that may cause people to miss or turn away.

<Brent> +1 to Shadi - which is what my title wording was based on in the survey question

Shawn: We do not have consensus yet on the titles and there are still several differnt opinions, so these are more like placeholders. Let's think of what we should do now. Kevin, can you summarize the options?

<shawn> [tangent: "Authoring: Tips for writing accessible content for the web." -> Writing ]

Kevin: The current approach is to use the same phrase that is on the section overview. Starts with the activity or role and provides a short phrase that includes more info. Another option is to use Quick Start in the title and shorten the title, remove qualification info into a subtitle. There were other comments about the prominence of accessibility overall.

Brent: My response in the survey was to try to keep it as short and simple as possible. Designers may come from different perspectives as well as the other roles. As the conversation developed today, I am beginning to agree there is a need to tie it back to the QuickStart. I like the side navigation but also liked Howard's idea for a logo or banner or something that identifies that you are looking at related resources.

<shadi> +1 to Brent

scribe: but not in favor of lengthening the title, need to make titles not wordy.

Shawn: The other idea is that the title of each page is a common title "Design for Web Accessibility with an icon, masthead, something that says quick start tips or something that identifies it as one of the Quick Start Tips

<Howard> I like the icon idea at top

Sharron: If we are thinking of visual iconography, we have to address the left navigation, which has been identified as distracting and even disruptive for some.

Andrew: Agree

Kevin: "Design for Web Accessibility" form of titling works better for some than others. If I need to remove left hand nav, I will have to do more with the relation to the WAI styles and how that design might work to avoid vast white spaces.

Shawn: I wonder if we have thought enough about the issues of the site wrapper or if we should table that and bring it to the group later on.
... a sub-topic then is a consideration of the overall navigation. When we expect people to remain within a specific tool (like WCAG-EM Report Tool) we present it without the WAI wrapper. With most other resources, however, we present it within the WAI site design. A benefit to that is that it encourages people to look through the left nav and investigate other resources.
... for some people, however, it creates clutter and distraction and for people like Wayne, it causes reading barriers. One suggestion has been to allow the site nav to be collapsible. Initial thoughts?

Shadi: The essence of the problem is that we need a new WAI web site design. In the interim, I wonder about the issues of consistency and the exploration potential. I wanted us to consider how the Business Case is presented. It is not ideal but support consistency and maintenance. Here is the link:

<shadi>http://www.w3.org/WAI/bcase/

<Andrew> consistency is preferable unless there is a very good reason not to have it

Sharron: If we make the side nav collapsible would it be so everywhere on the WAI site?

Shawn: It is a choice we could make

Andrew: It would make it less likely for people to explore resources.
... there are a lot of issues to make that decision, especially site wide for a whole range of different types of users.
... As we don't need all the space like we did with the WCAG-EM tool, I would be reluctant to remove the left nav.

Brent: I agree that if it is collapsed, people won't explore it. I am curious about feedback of the BizCase presentation and how people used it. Do people feel that they got lost? do the tabs keep people anchored within the same resource? and do people even like that presentation?

Shawn: From my perspective, we have not done any user feedback sessins so we don't know for sure. Before we had the top and bottom navigation that the nav on the left was not sufficient. We added those tabs across the top and a Prev / Next on the bottom.

Shadi: I have heard from people outside within the context of WAI-AGE that some people were alerted to the fact that there were in a multi-page resource, but have also heard that people get lost becasue they do not realize the relationship between the resources. a design aspect is needed to visually tie the pages together.

Brent: if it is not the ultimate solution, Kevin should not pursue it.

EricE:"Developing a Web Accessibility Business Case for Your Organization" should be above the horizontal nav, "Overview" below, to make hierarchies

Shawn: The business case is different than this since it really is a more linear, more tightly connected document. The subpages of this resource are more loosely connected and independent. Some people are likely to look at just one resources.

<Howard> I think that's a key point - these pages are less connected

<kevin> +1 to Shawn's many users focusing on one page comment

<shadi> +1 to Brent and Shawn

Eric: I agree and think a bit of styling could address the problem and make it clear that these are related resources.

Shawn: Other input?
... Several comments in the survey, people had also left comments in Github

to talk about "ensure"

<shawn> [ e.g., "Ensure that all interactive elements are keyboard accessible" - "Make all interactive elements keyboard accessible" ]

Brent: Ensure is a very strong word and needs to be there

Shawn: To me, ensure means I am checking that someone else has done something

<Andrew> definition: make certain that (something) will occur or be the case / to secure or guarantee

Brent: It means I must take the responsibility to double check that something is done.

Shawn: If the task is something that you do, ensure is not the right word.

<Andrew> definition: When you ensure that something will happen, you guarantee it.

Shawn: first it must be clear that the thing is done, then you ensure that it has been done.

Shadi: To me, it works either way.

<Lydia> I agree with shadi

<Andrew> me too

<yatil> http://www.thesaurus.com/browse/ensure?s=t

<Lydia> It all depends on the role you have

Kevin: In terms of its meaning, it is to make certain that something gets done. making sure that something happens. It works either way.

Shawn: For me it does not work, but it is not a huge show-stopper.

Brent: It is used in both ways so I am in favor of that as well. Either you do something to ensure it or you check to be sure something has been done.

<yatil> [Thinks ensure is fine, make sure probably clearer.]

<Andrew> http://dictionary.cambridge.org/dictionary/british/ensure

Howard: The alternative would be to use "make"

Shawn: Some preferred ensure over make

Sharron: I like "make" it is more direct. The fact that we had this discussion shows that there is ambiguity around ensure, why not use make, it is clear.

Jon: Make is ambiguous to me. Ensure creates a connection.

<Lydia> I vote for ensure

<shawn> [ me notes it doesn't have to be "make" -- there might be something better than either term.:-]

Shawn: Since we do not have consensus, maybe Kevin can work on that. There are preferences, but there was not a strong objection either way, leave for editor's discretion.

to talk about overlapping (e.g., alt)

Shawn:There was an issue in early drafts of how some of the tips overlap roles. For example, alt text...written by content developer but implemented by coder. Kevin, any discussion needed?

Kevin: The main overlapping issue was with images and how we needed to reference them in several places

<shawn> [ /me agrees sometimes it is the designer -- e.g., the writer/author might not even know the image 'cause the designer does it. ]

<shadi> [[please don't over complicate this - these are quick start tips for newbies]]

Kevin: as I thought about it, the major responsibility lies within the authoring role. There is slight repsonsibility among designers but that is edgy. there is also the consideration of the developer to be sure they are properly placing alt text. I am not averse to putting it into developing although I think that is more likely to be a matter of content management.

<Andrew> +1 to kevin's rationale

<shawn> [ I also wonder if there are many real-life cases where no one writes it so the developer needs to -- e.g., small development shop.]

<Andrew> [[as per Shadi - they are tips, not a comprehensive "how to" manual]]

Kevin: there is also quite a bit of overlap between managing and advocating. There are items there that require a bit of clarification.

Shawn: alt and overlap between managing and advocating, those are the only cases to consider?

<shadi> [[and labels]]

Kevin: Yes for now.

<kevin> +1 to Shawn's comment on small developer shops - but then they may be reading 'Authoring' as well

Vicki: I think alt considerations should be referenced in design so that they are aware. They may play a bit of all of those roles so it could be useful to remind people in all related roles.

Shadi: We have 9 tips in design as it is. We should not exceed between 7-9 tips for each. If we add alt, we might consider removing one. Some degree of overlap is OK and probably inevitable. I agree that clarity is needed between managing and advocacy.
... my main point is priorities. If we add to a topic, should we drop another?

Andrew: and recall that it is a Quick Start, not an authoritative How To and we lead them to new resources.

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

Shawn: Vicki, with that in mind would you be comfortable leaving alt text out of design?

Vicki: If it is added at the bottom or somehow referenced I might be OK with that.
... even at the bottom with learn more

<Andrew> maybe learn more includes the tutorials

<shadi> +1 to making it specific to each page -- eg "learn more about accessible design"

Shawn: So "learn more" would link to something specific to that role?

Andrew: Related to developing, it does not need to be added since it is included in code validation.

<Howard> +1 to alt for developer

Shawn: I propose that alt does belong on developing. I imagine there are many developers who receive content that does not have alt attached to it. Also even if someone is given alt if they do not realize the importance they may think it unneeded and not put it in. It is easy, good for a tip. Finally, we don't have alot in this particular list so it would not be a burden.

<shawn> Vicki +100

Vicki: +1

<Andrew> if we add, need to tell them who to get the text from

<yatil> +1

<paulschantz> I'll add my +1

Shawn: any objections?
... Kevin continues to work on these, please put on your "let's make this awesome" hat and continue to engage with his work. We will prompt you but you are encouraged to look and comment as you have time and inclination

Quick Ref redesign

Shawn: Eric is working on incorporating survey comments and feedback from AccessU. We can leave the survey open for your comments.

Eric: I have little to say about it, I am working on making a more active view so we can have a design that we can use and discuss. I think it will be a good direction and we will see more next week.

Shawn: And we may have opportunity for more informal testing/feedback in June. Will keep you posted.

Providing feedback on draft projects

Shawn: Wanted to provide an update and address any questions you may have about how to submit suggestions or comments. Previously we have asked for preliminary way to do requirements and early drafts.
... some find wiki hard to use and so feedback can be submitted via the survey or email to the list.
... once a draft gets more robust, it is moved to GitHub where you can raise an issue, make a comment, suggest a change. That is the current process. Once a project moves to GitHub that becomes the preferred way to comment but if you are not comfortable with it, we want you always to be able to submit via email or survey.

Sharron: This reminder is prompted by my experince last week when I made extensive notes on paper about the reource and then went looking for the best way to submit. I started on the wiki, moved to the survey and then decided to try again to use GitHub but had forgotten a bit about how to use it properly. So I was interested in a GitHub refresher tutorial and thought others might be too.

Lydia:Yes that would be useful

Andrew: Yes I could use a GitHub refresher.

Vicki:I would attend if I could.

Sharron:OK I will look for some dates in the next few weeks and put on the survey to see if we can find a good date for that.

zakim & webex

Shawn: zakim is going away, we will miss him. There are some barriers to WebEx but some advantages as well. I wanted to alert people to that it is likely to happen at the end of June.

<jon> I have lots of experience using Webex.

Jon: Could you use Google apps for nonprofits which is free?
... you could get the Google apps for business but get them for free. You can create your own plugins and integration with internal systems and screen sharing etc.

<Andrew_> google docs/apps has accessibility issues too (at least it did last time I investigated)

Jon: There is also the GoToMeeting with an improved UI and is used by a couple of ADA Centers and Blackboard.

Shawn: I will put you in the loop with those who are making this decision, any other comments or questions?

<Andrew> cisco is also a W3C member

Shawn:OK then, thanks all and we are adjouned, have a good weekend!