W3C

- DRAFT -

EOWG

29 Oct 2010

See also: IRC log

Attendees

Present
Doyle, Shawn, Ian, Shadi, Liam, Jennifer, Sylvie, Suzette
Regrets
Yeliz, Alan, Emmanuelle, Andrew
Chair
Shawn
Scribe
Doyle

Contents


<scribe> Scribe: Doyle

<scribe> ScribeNick: doylesaylor

Shawn: Let's get started.

WAI-ARIA review - approve EOWG comments

Shawn: Thanks for the comments Ian.

Ian: yea or nay on the comments? And I'll submit.

<shawn> bottom http://lists.w3.org/Archives/Public/w3c-wai-eo/2010JulSep/0017.html

Shawn: Go to bottom to the notes.
... Teleconferences do not always represent a consensus. Gives time for persons who weren't in the teleconference.
... lets take a look at Ian's comments.
... on the first one for the abbreviation. We thought it should be abbr in several places in the document.

<shadi> <acronym>WAI-ARIA</acronym>

Shadi: I think the entire document is WAI-ARIA and does not need expanding, even someone who lands in the document anywhere their being there would be related to WAI-ARIA. I would use the acronym element without title attribute so it would not be read out every time, and not show in most browsers as an acronym. I don't know if that coding has any use, but it is still marked up as acronym.

Liam: I think it is taken as a pronounciation cue.

Shawn: I think it does. If it doesn't have the title most browsers won't distinguish it?

Ian: that's right.

<shadi> s/not abbreviation/without title attribute

<IanPouncey> " * For instances of the abbreviation after the first in each section markup as a <abbr/> without a title attribute"

<sylvie> hello I am in a noisy environment today so i'll stay muted

Ian: changing the second bullet.

Shawn: I think what you want to say is; what Shadi proposes, WAI-ARIA is explained in the title in the H1 and the title is not needed elsewhere - to avoid clutter do not include the title attribute and any other abbreviations. What you want to say.

Ian: I would prefer that each section have an abbreviation.

Shawn: we discussed last week also.

<IanPouncey> "After the first use in each section do not markup WAI-ARIA as an <abbr/>"

Shadi: there is a bit of overkill about that abbreviation. I caught in several sections and it is in many places. In some of the references. Have in one paragraph two or three instances, a first occurrence in a sub section is ok.

Ian: in a sub section?

Shawn: you can mark up as an abbreviation but not as a title.

<shadi> #1. use abbr elemenet for each occurrence

Shadi: also don't use as a title in the text. The very first heading of the page the H1 right at the top.

Ian: We have the problem of rich applications for WAI-ARIA.

<shadi> #2. use title attribute ONLY for first occurence in a section

Shawn: Shadi?

Shadi: I think that is a different one if WAI needs expanding a short name for Accessible rich application. The WAI does not need an expanding.

<shadi> #3. do not use title attribute if name is already expanded in text

Shawn: we just need to get number 3. Attribute only. Ian see the 1 2 and three?

Ian: Yes.

Shawn: anything else?

Ian: I think WAI should be expanded.

<IanPouncey> WAI-<abbr>ARIA</abbr>

Shawn: In this case we actually never say WAI Rich Internet Applications. It really is an abbreviation. If you spell it out, it is still ARIA Accessible Rich Internet Applications.

<shadi> no <abrr>WAI-ARIA</abbr> or <acronym>WAI</acronym>-<acronym>ARIA</acronym>

Ian: Ok.

Shawn: Not ideal but are we ok?

<shawn> http://lists.w3.org/Archives/Public/w3c-wai-eo/2010OctDec/0012.html

Shawn; we are set on that one. Back to Ian's draft emails. Comments?

<shadi> +1 to "non-disabled users" -> "using a visual browser"

<LiamMcGee> +1 ditto

<IanPouncey> "We felt that in places marking up WAI-ARIA as an abbreviation in every instance was causing a great deal of visual clutter, the last paragraph of 1.1 is a good example of this where the term is used 7 times.

<IanPouncey> * Use abbr elemenet for each occurrence, but only use title attribute for the first in each section

<IanPouncey> * Do not use title attribute if name is already expanded in text

<IanPouncey> "

Shadi: couple of comments further down. On technology example. We there yet?

<shawn> "This content needs to be available in text form within this document." what about longdesc

Shawn: Let's look at longer description for figures. You have could be long desk for this document but could be outside? Yes. Content needs to be available in text form.

Ian: Originally long desk.
... we skipped over the WAI-ARIA link. Is that ok?

Shawn: yes

Ian: We drafted replacement suggestions.

Shawn: you got several for that.

Shadi: first is to expand the full name PWD use the web.

<shadi> http://www.w3.org/WAI/intro/people-use-web

Shawn: for Ian to use in the comments. We try to write out to not use PWD in written publications.

Shadi: that is where the final draft will be published.

<shadi> [[which is currently being updateded by EOWG]]

Shawn: we purposely made that link publishable. For further comments in EOWG, go ahead PWD use the web. It is a referencible link.

Shadi: Could be updated by EO rather than when it is completed. Available soon that is wording nuances for editors discussion.

Shawn: we said last week we didn't have time and wanted to coordinate with Shadi, is on the agenda in November.

<IanPouncey> "For 4. Important Terms we would like to give further input on the AT section based on documents EO is currently writing. Additionally we would like a link to 'How people with disabilities use the web' which is currenlty being updated by EOWG (http://www.w3.org/WAI/intro/people-use-web) and which will be available shortly."

Shawn: I talked to Michael the staff contact and he said there is some flexibility if they get a comment next it would be fine, but in three weeks they plan to move on.

<shawn> For 4. Important Terms we would like to give further input on the AT section based on documents EOWG is currently writing. Additionally we would like a link to 'How people with disabilities use the web' which is currenlty being updated by EOWG: http://www.w3.org/WAI/intro/people-use-web.

Shawn: Anything else on that one?
... next one host language semantics. Document focus?

Ian: we talked about this, do we want to include in the comments?

Shawn: Instead of consideration given, we want to say some EO participants the scope of this should be focused on what developers want, and the User Agent comments in the User Agent guide.

<shawn> "we feel that this separation may make it more accessible to the target audience" -> "we feel that this separation would make it more usable for the target audience"

Ian: replace that sentence?

Shawn: the second part of the sentence.

Ian: ok

<Zakim> shadi, you wanted to propose new comment on definition markup/styling

Shawn: Anything else on document focus. Style consistency Shadi?

<shawn> consider using styles from recent WAI TR documents

Shadi: Style consistency, brings the question, for all documents? No. To avoid that we want to make the point, re-using styles. To recommend that. One comment. I have a couple more.

<shawn> consider using styles from recent WAI TR documents, such as WCAG 2.0

Shawn: consider using styles from WAI WCAG 2.

Shadi: or consider using styles from WCAG 2.

Shawn: the one that jumped out at me, was the term analogy one.

Shadi: when you click a term when it is black it is hard to select again that is already visited is hard to make. Regardless what style they use that should not happen.

Doyle: I agree with that.

Shawn: yes.

Ian: in the same section?

Shawn: they may still do that, it is egregious we should point that out.

Ian: belong in style consistency?

Shadi: call the section style. One on consistency and so on. One thing Style for the notes is quite gray. Check color contrast on that?

Shawn: It's fine. I'll give you a number in a bit.

Shadi: It is still quite gray.

Shawn: they still should have good reason to use WAI-ARIA styles. I will go to them and we will address it. I imagine they will say oh that is ok we'll do it. Michael felt the Authors Guideline needs some help. So we will work on that later.
... Ian more time?

Ian: making it hard to distinguish in the links.

Shawn: the definition links are italicized in green. And other things are italicized one could say there is not sufficient color coding.

Ian: Quick glance everything I see italicized is also green links.

Shawn: the main thing is to get it recorded as an issue.

Ian: is that acceptable?

Shadi: yes to me that is acceptable.

<Zakim> shadi, you wanted to go back to the acronmy markup comment

Shadi: to go back to the initial comments on the use of acronym. We mostly talk about the WAI-ARIA expansion. In general use the same principle for acronym after WAI-

Ian: that is part of the solution. Put in a follow this principle.

Shadi: that would work for me.

<IanPouncey> "follow this principle for other abrreviations and acronyms."

Ian: after the two solution bullets.

Shawn: anything else comment? Ok to send for Ian.

Ian: I will email them now, if anyone wants to take a quick look.

Shawn: It would be fine to send if you have a note on the bottom. Anything else?

How People with Disabilities Use the Web (survey)

<suzette> sorry have to leave now - see some of you next week.

Shawn: Shadi sent some issues in email.

<shadi> http://lists.w3.org/Archives/Public/w3c-wai-eo/2010OctDec/0016.html

<IanPouncey> need to step out for a minute, brb

Shadi: Thank you for comments. The email is linked from that and is a summary of comments that need discussion. Let's go down the list. The first comment from Sailish. Using connected list, related sections. Basically in most of the section there is always a related end. He suggests not to use nested list. To use headings or bolded as another paragraph. Liam suggested that. Thoughts?
... Nested lists are often not the most comfortable thing to use. I would like to avoid using heading level. Overkill of headings.

Jennifer: I agree.

Shadi: Bolded paragraph as a list level. Agree?

Shawn: I think just a paragraph to do bold and do spacing between stories of web users and the intro and the beginning of the list.

<shadi> ACTION: change nested lists in related sections to bolded <p>'s as list intros [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action01]

<shawn> +1 for leaving CMS

Shadi: ok gone. In the stories page. Let's focus on that page. In the section there called Mr. Jones. First story there. That talks about Content Management Systems. Second story. Talks about CMS get them into to highlight as one of these situations. The effect of them. The specific comment was that it was too technical. Shawn was for leaving here.

Jennifer: I am for leaving in.

Shawn: take out of the first sentence, where it might scare them off.

Shadi: have in the last paragraph. Would there be a disconnect?

Shawn: (states alternative)...tool is a CMS Content Management System. Take CMS out of the first sentence. YOu can still say but take out of first sentence. Put in the second sentence.

Shadi: Ok.

Jennfier: I am ok with that.

Shadi: move down a little bit and keep it.

<shadi> ACTION: soften down "CMS" by taking it out of the first sentence and putting it into a second one [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action02]

<shawn> something like maybe: Mr. Jones is a reporter who must submit his articles for an on-line journal using his publisher's tool. The tool is a content management system (CMS) that he can access via the web. Over his twenty-year career,...

Shadi: action taken. Staying there in Mr. Jones. The story talks about Mr. Jones RSI using the keyboard, using the keyboard would re-damage his hands. change to increase his pain. Liam agreed with that comment. An odd use that jumped out at him. I wanted to highlight it is not only pain, but to really say that ...

Jennifer: what about further damage?

Shawn: worsen?

Shadi: worsen what? Pain, damage, health?

Shawn; let's brainstorm for a minute.

Liam: deterioration.

Jennifer: acerbates.

Shawn: acerbates RSI.

Shadi: RSI is often progressive. Not only re-inflaming.

<shawn> EXACERBATE is : to make more violent, bitter, or severe

Shawn: to make more violent or severe defines acerbate.

Liam: worsens means the same as exacerbate.

<shawn> he would have to use a mouse instead of voice recognition or typing, and this would worsen the RSI

Shawn: worsen RSI.

Jennifer: works for me.

Liam: me too.

<shadi> ACTION: change to "would worsen his RSI" [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action03]

Shadi: next comments from Jennifer. I will skip the one on the overview page. Staying on the story page. This was original title was scenario for users. The suggestion is to use stories throughout. We went a little back and forth if scenarios be a better term.

<shawn> This page outlines selected stories (scenarios) of people...

Jennifer: to be clear, on my comment. I still like the word scenario, I would like stories to be in there in and it would be odd to have the title and then not use further on.

Shadi: there are two uses of scenario. In the first sentence for example we could change that to stories. We could leave one as scenarios, and one as story. Used in the overview page as well. Michael in his comments agrees we should use throughout.

<Zakim> shawn, you wanted to suggest using BOTH "stories" and "scenarios" in the intro, eg This page outlines selected stories (scenarios) of people...

Liam: having come back to this I originally said to be consistent, but here scenario is used to clarify here I think that is fine.

<shadi> [[these stories outline scenarios of ...]]

<shawn> These stories are scenarios...

Shawn: something like using terms interchangeably, make clear in the first sentence. Fine what Liam said as well.

Shadi: something along that line.

Shawn: It don't need to have that outline, just these stories are scenarios....

Shadi: ok.

<shadi> ACTION: use "these stories are scenarios ..." to use stories and scenarios interchangeablly from the start [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action04]

Shawn: you say interchangeable? In the intro and where else?
... you could take outlines out.

Shadi: let's go to overview page now. There were comments for there. The first sentence (Shadi reads) that is the opening sentence to draw people in. Jennifer and Michael were commenting on the flow or grammar of this. Liam suggested using a hypen or colon to break that up.

Jennifer: Liam's idea works for my suggestion.

Shadi: you were talking about the second sentence?

Jennifer: the third one.

Shadi: Michael felt it didn't flow for him. We'll take Liam's suggestion.

<shawn> &mdash;

Shawn: M dashes not hyphens.

Liam: you could use hairline spaces.

Shawn: would look really nice there.

<LiamMcGee> http://en.wikipedia.org/wiki/Dash

Liam: It is a very small space on either side that allows a line break. See link.

<LiamMcGee> U+200A

Jennifer: there is a way to code them so they do that.

<shadi> ACTION: use "m-dashes" with "hairline spaces" [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action05]

Shadi: ok. disagree?

Shawn: I did kind of like the pauses of the sentences. I'm thinking about the m dashes. You want people to stop and think there.
... I think it is acceptable to be not grammatically correct in a situation like this. I put in somewhere else to see what the m dashes and that doesn't work in how we want people's brain to processes that.
... who brought this up?

Shadi: Michael.

Jennifer: to fix my thing is simple to make that a full sentence and your are done.

<shawn> How do people who cannot move their arms use your website? What about people who cannot see well or at all? Or people have difficulty hearing or understanding, or have other accessibility needs?

Liam: You could put all people in. As the explanation.

Shawn: that is something to consider where we can choose not to have perfect grammar to get the point across.

<shawn> How do people who cannot move their arms use your website? What about people who cannot see well or at all? Or people who have difficulty hearing or understanding, or have other accessibility needs?

Jennifer: I can live with that. We are getting to how people would think that is the most important in the beginning.

Shawn: Shadi?

Shadi: added the word people?

Shawn: I took out another who.

Shadi: we did do a fair amount of the different kinds of disabilities without listing them. That affected the grammar. Live with that?

<shadi> ACTION: use "How do people who cannot move their arms use your website? What about people who cannot see well or at all? Or people who have difficulty hearing or understanding, or have other accessibility needs?" [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action06]

Shawn: I think that is the way to do it. The non grammaticalness of it gets across the flow we want.

Shadi: moving on, to continue to Michael's comments. Sylvie is next. There seems to be a little confusion with the page contents.
... I am not sure how much is related to the first view and to the page order. The introduction heading does not appear visually, and invisibly in the page content. Using the style sheet, select that link and see the page content. We removed the links within the page content. The comment still is a H2 heading. To navigate to easily. Within the introduction. Anyone having trouble navigating. Navigating by headings?

Jennifer: I didn't fiddle with the heading navigation too much. I thought the page was in transition and didn't want to bog down in that. I believe when you navigate, you expand all and go to heading is to the link collapse, that might be window eyes incorrect.

Shadi: change headings?

Jennifer: I think I had to arrow. It is not our responsible to accommodate there.

Shadi: the script is not good there either. Sylvie?

Sylvie: I think the problem I had with this after the introduction and then in somewhere in the page content and then the introduction and the contents.

Shadi: that is the organization aspect. So if we don't have the H1 have the heading and then after that page content.

Liam: I am looking for consistency with other documents.

Shadi: I think that is what Sylvie points out also.

<shawn> http://www.w3.org/WAI/WCAG20/wcag2faq.html

<LiamMcGee> suggest: Page contents as at: http://www.w3.org/WAI/intro/accessibility

Shawn: we do have things like WCAG FAQ. We don't call it page contents. I don't know if we have an invisible introduction there. Maybe if looking at consistency, maybe change the word page content. All right page content is floating there. In this case do we want the introduction to be first, and then this list on the page and not floating on the right because it is so long. Call it something besides page content?

Shadi: I looked at the FAQ it does not have a heading there.
... change page contents to on this page?

Shawn: I don't understand?

Shadi: temporarily.

Liam: don't lose it because it is a good idea.

<sylvie> see for example eo page

Shadi: what are other ideas for page content.

Shawn: I was looking at the stories, you could say 'stories:' but wouldn't work for other pages.

Shadi: Sylvie writes EO page.
... Let's stick with that idea. Stories on this page or something like that. Diversity on this page?

Shawn: I think we want to stick to stories.

Shadi: thoughts or suggestions on this?

Shawn: I am looking to the others. No it doesn't work.

Shadi: using the flow approach we have to shorten quite a lot.

Shawn: remind me what you are thinking. There would be a separate contents list. To process expand all and collapse all. Fine for diversity users, fine for web browsers, for web principles, and for stories fine to use name, but not to focus on.

<Zakim> LiamMcGee, you wanted to hesitantly suggest more story-like headlines... e.g. Mr Lee goes shopping

<sylvie> other resource example :

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

Shadi: and principles is fine to use here. Ok with WCAG here. More story like headings? Look at later. Stay on page comments for a little bit. How about using on this page for now. Rather than page contents.

<shawn> On this page:

Shawn: works for me. On this page colorn.

Shadi: Sylvie points out business case.
... On the business case the page contents comes before. The issue though is the page content is loaded the right side. Rolls up the side of it. The introduction floats between the left navigation menu, and the page contents. but that is very wide, and we can't have them side by side. They definitely need to be moved. Liam says if we use story like headlines. Like Mr. Egos shopping. For here?

Shawn: not for this draft, not for this day.
... the other thing is these are stories, but realistically the color blindness and the RSI are really the focus. Even though the name is made to be realistic.

Shadi: the compromise solution is to use page content colon, rather than the heading? Agree?

<shadi> ACTION: use "On this page" as <h2> rather than "Page Contents" [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action07]

<LiamMcGee> +1 agree

<shawn> example of superhead: http://www.w3.org/WAI/WCAG20/glance/

<shawn> how business case is done: Social Factors in Developing a Web Accessibility Business Case for Your Organization

Shadi: done. Couple more comments from Michael. Michael proposes to use How PWD use the web. Quote stories of users and then after that in H1 is not so visible. To make smaller, my comment on that, it would be read off screen readers first. Skipped more easily smaller.
... not a heading?

Shawn: It needs to be part of the heading you need the context if you land on this page. You need that context from somewhere else. What about I think it is not clear, generally we have the right idea. If people go around a lot, we don't want them to re-read business case every time. Take out the word draft, stories about disability users use the web.

Shadi: most readers should pause there.

Jennifer: one thing is that the page titles stay what they are. Good to stay so you know where you are.

<shawn> [ shawn suggests making the subtitle a bit smaller]

Shadi: I think when the draft is removed a little easier to focus. I am not sufficient taking Michael's idea.

Shawn: there are concerns with doing that way.

Shadi: yes subtitle a little smaller is good. Let me note that.

Shawn: If you have fonts that are different so confusion about 'are they the same or not' is minimized.

<shadi> ACTION: keep "how people with disabilities use the web" after page title [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action08]

Shadi: Michael commented on the draft bracket on related resources, those links jump into the middle of another document. To clarify where they are going I put in brackets the section heading. Like in brackets hearing seeing. There are issues with this. Issues with both captions and transcripts jump to the same section. A confusing jump between captions and transcripts.
... Going to the stories of web users page like Ms. Martinez, third story. At the end of the story, something called related sections within this resource. Under that there three bullets. The second one is web browsing there are three items again, the first one reads hearing seeing in open brakcets and then in sign language.

Shawn: where do they actually go? The target?

Shadi: they both go to the same place in the Web Browsing section. To the top of the section. The reason why I didn't why I didnt' link into captions because it would really specific. There could be a second link to go to the top of that section.

<shadi> <a href="caption">caption</a> in <a href="section-top">hearing, feel, and seeing</a>

Liam: what is ... linking to the main section because they have no context?

Shadi: yes.

Shawn: I think it needs to be clearer though. When you click on this link you go to the section Hearing Reading Seeing. The part relevant here is the part about captions. What would the negative of having two links? Captions link in Hearing Feeling and Seeing link?

Shadi: that would be the thing to do. Objections.

Jennifer: An lot of links. Expand all those pages will have a lot of links.

Doyle: I agree

Shawn: I don't think you need to be for perceivable, and for hard of hearing, under accessible principles, the only page to add is the middle one is web browsing innovations.

Liam: even changing auditory dash hard of hearing. That way you have strong context and part of a larger section. Putting brackets is disambiguation and is not quite what we are trying to tell. them. In those cases you put auditory disabilities.

Shawn: It is how much you want to emphasize hard of hearing instead of auditory in general.

<shadi> ACTION: separate out link into section and sub-section [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action09]

Liam: yes.

Shawn: the next one, under web browsing navigation. Looking at the organization you might have Hearing Feeling and Seeing. Under that I don't know if that presents the information how we want it stressed.

Shadi: nest again?

Shawn: Just one idea, I am not saying this is the right thing to do.

Shadi: that is really the issue here. You might want to read more about screen reader. If you don't want to you don't want to link there, section first and then sub section. Nesting approach might work. I'll take a pass at that to see if it works out. From Jennifer. Expand I don't know what to do about that. Reading the story talks about screen readers or keyboard you want to read about that. The headings Hearing Feeling and Seeing you won't see
... Anyone want to add anythig to this page? let's go to Michael's last comment on accessibility standards. On the principles page. Introduced first the components of accessibility and the importance of standards. He proposes the more important H3 and the sub sections called WAI Guidelines used there. Support?

Shawn: I strongly support whatever the editor wants on this one.

<shadi> ACTION: add sub-section on "wai guidelines" in "accessibility standards" section [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action10]

<LiamMcGee> +1

Shadi: I will go along with that. Can people stay another ten minutes?

<shawn> link to http://www.uiaccess.com/accessucd/resources_videos.html ?

<shawn> could put after the list of pages

Shadi: last page, the comments on that to paraphrase to basically he is saying the resource used by teachers of design, the issue is they need more hand holding. go online they can use how to use the web in training videos. I think this could easily start growing. Developers would want to learn more not just teachers. An interim solution. Like online resources and have one or two, and other resources have more about this.

Shawn: first of all you don't have to put before the list pages, you can put after. I think we should consider this, who is the target audience, and most would get a lot out of videos and videos and other resources I think we should do.

Jennifer: I agree.

Shawn: we can discuss this some more Tuesday afternoon as part of our training discussion.

<shadi> ACTION: consider adding a small paragraphs to other resources on how people with disabilities use the web [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action11]

Shadi: to have specific resources exactly?

Shawn: do you want to call out to the list for specific resources?

Shadi: no, minimize efforts for this round.

<Zakim> shawn, you wanted to comment on suzette's comment and to request change to "Web browsing innovations" with next edit

Shadi: takes this to the comments, thank you all for the review and comments quite a step closer to the next stage.

Shawn: one more thing I request the title Web Browsing Innovations, be changed. I don't think of them as innovations.

Shadi: I am running out of ideas, I would appreciate suggestions?

<shadi> [[Ways of Browsing the Web]]

Shawn: how about web browsing? Or ways of browsing the web?

<shadi> [[How People Browse the Web]]

<shawn> browsing tools and strageties

Shawn: browsing tools and strategies?

Liam: that is right!

<shadi> [[Browsing Tools and Strategies]]

Liam: users strategies?

Jennifer: web browsing strategies.

<shadi> [[Web Browisng Strategies]]

<shawn> web browsing Approaches

Shadi: we talk more than about strategies. Web browsing approaches?

<shadi> [[Web Browisng Approaches]]

<LiamMcGee> [[what users do]]

Shawn: I like approaches better than methods.

<LiamMcGee> [[How users use]]

<LiamMcGee> [[How they do it]]

Shawn: other brainstorms on that? Gone.
... thanks everyone who filled out the survey. Note we are moving this forward. Try to schedule we want to have an ok for review. We skip number three.

Face-to-face preparation

Shawn: Welcome to join the face to face teleconference.
... Next the agenda is updated for the face to face. We will look at the latest web redesign someone could step up and review some of that information and introduce it?

Liam: I would be happy to do that.

Shawn: read through it good and introduce the topics and introduce ideas would be helpful.

Sylive: I am not sure what you mean?

Shawn: something about the agenda for the F2F.

Sylvie: an email to add suggestions for yesterday evening. Is the page the whole navigation?

Shawn: A list of all the pages we need in the site navigation. And it has a lot of new pages that have a new home, a question we can think about on the plane. Other ideas for pages to add? That was what that was for.

Sylvie: I counted 71 topics. I was surprised it was so larger a navigation.

Shawn: the site map has that many pages.

Sylvie: I thought the navigation bar?

Shawn: the site has all the pages, but the nav bar has the highest level. We will re-design. Thanks so I clarify what it is?

Sylvie: question about place? The conference center is big.

Shawn: I will ask and send you an email. At the end of this meeting.

Sylvie: ok.

Shawn: comments? Questions?

Jennfier: i am sorry I won't be there, I will look at over the minutes.

Ian: trying to have next week available poll.

Shawn: let's try next Tuesday to discuss, for Friday to have a meeting. Decide on Tuesday. Please keep updated availability survey. We use that a lot.
... Use the current site map Liam.

Liam: the draft site map is not taking the current stuff?

Shawn: all that is from five years ago. Something we looked at five years like a matrix we don't want to do that. Not go into so much detail.
... have a good trip. See you next week.

Summary of Action Items

[NEW] ACTION: add sub-section on "wai guidelines" in "accessibility standards" section [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action10]
[NEW] ACTION: change nested lists in related sections to bolded <p>'s as list intros [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action01]
[NEW] ACTION: change to "would worsen his RSI" [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action03]
[NEW] ACTION: consider adding a small paragraphs to other resources on how people with disabilities use the web [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action11]
[NEW] ACTION: keep "how people with disabilities use the web" after page title [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action08]
[NEW] ACTION: separate out link into section and sub-section [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action09]
[NEW] ACTION: soften down "CMS" by taking it out of the first sentence and putting it into a second one [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action02]
[NEW] ACTION: use "How do people who cannot move their arms use your website? What about people who cannot see well or at all? Or people who have difficulty hearing or understanding, or have other accessibility needs?" [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action06]
[NEW] ACTION: use "m-dashes" with "hairline spaces" [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action05]
[NEW] ACTION: use "On this page" as <h2> rather than "Page Contents" [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action07]
[NEW] ACTION: use "these stories are scenarios ..." to use stories and scenarios interchangeablly from the start [recorded in http://www.w3.org/2010/10/29-eo-minutes.html#action04]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/10/29 14:46:20 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

FAILED: s/not  abbreviation/without title attribute/
Succeeded: s/not abbreviation/without title attribute/
Succeeded: s/#2. use title attribute for first occurence in a section/#2. use title attribute ONLY for first occurence in a section/
Succeeded: s/Liams draft emails/Ian's draft emails/
Succeeded: s/ Shawn: gone Shadi?/ /
Succeeded: s/ just these people are these scenarios./ just these stories are scenarios..../
Succeeded: s/ I am not saying this is the right thing to do./ Just one idea, I am not saying this is the right thing to do./
Succeeded: s/ I think editors discretion is what I want here./ I strongly support whatever the editor wants on this one./
Found Scribe: Doyle
Found ScribeNick: doylesaylor
Default Present: doyle, Shawn, +1.207.330.aaaa, Shadi, Ian, Liam_McGee, +1.650.348.aabb, jennifer, Sylvie, suzette, LiamMcGee
Present: Doyle Shawn Ian Shadi Liam Jennifer Sylvie Suzette
Regrets: Yeliz Alan Emmanuelle Andrew
Got date from IRC log name: 29 Oct 2010
Guessing minutes URL: http://www.w3.org/2010/10/29-eo-minutes.html
People with action items: ... add are change consider keep scenarios separate soften stories these use

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]