EOWG -- 26 Nov 2010

<scribe> scribe: Sharron

WAI website navigation/information architecture/site map short-term tweak

<shawn> http://www.w3.org/WAI/redesign/2011/sitemap2010.html

Shawn: Follow first link in agenda list, review tweak to WAI site map
... since last week, changes are to first two sections. Getting Started has two sections now. Some of the ideas are listed as braistorms.
... Shadi, do you want to bring up items for discussion?

Shadi: I am not happy with "Broad Benefits..." but can't suggest anything better.
... otherwise I am happy with how it is coming along

Jennifer: I thought it was looking pretty good. Saw some fixes needed for little things. Will try to mention them as we talk, but will send in eamil if not.
... For example in the part about Presentations, I have some improvements to send.

Shawn: Great, if we accept this, we will looking at those kind of improvements next week.
... Let's talk about Broad Benefits section. One of our issues is to let people find some of our resources, especially the newer ones. Many do not even know we have them.

<shawn> broader context of accessiility, accessibility and inclusion, shared experiences, broader benefits of accessibility, how accessibility relates to other stuff

Shawn: what kind of wording would encourage people to find reosurces listed here; Older people, Business Case, etc

<shawn> Accessibility and ...

Liam: Accessibility And...

Shawn: Other brainstorms?

<shawn> Accessibility is Good For . .

Liam: Accessibility is good for...

Shadi: Accessibility for you...

<LiamM> Reasons to be cheerful

Sandi: How to convince your CEO...very different tone. Must convince decision makers. A way of understanding and also convincing
... would a list be useful of all different aspects

Shawn: Need a few words for navigation, a summary that would lead

Jennifer: Accessibility Benefits

Sandi: ...for all types of organizations

Shawn: Accessibility Benefits for ALL

Sandi: for organizations?

Shawn: Well, some have benefits for individuals.
... we need not to rename documents today but how to make a navigation section title that will include these.

Jennifer: ...for Everyone?

Liam: Accessibility reach

Sandi: Why Accessibility matters

Shadi: I hate to bring this up, but Business Case is very different from other docs in this section.

Shawn: Second and third, especially the fourth, have multiple aspects

Liam: Accessibility Overlaps? Is that the idea?

Shawn: Shadi do you have a specific thought about a different grouping?

Shadi: I don't know where to put the Biz Case. It is slightly different. not talking about only the synergies, it is more for advocates than for developers or planeers, researchers.

Shawn: What would you label the others if the Biz case was not part of it?

Ian: Acc resources, Ac Explained?

<shawn> Accessibility leads to...

Liam: Acc in relation to other stuff. Where accessiiblity leads you in other disciplines
... I agree with Shadi. Why do accessibility? It good for all these things - mobile, older, biz case, etc Social factors are included within the specific docs.
... mobile stuff is developer focussed. Older not so much.

Shawn: Not all of it, but some. That's part of the challenge.

Liam: Yes, we should not be organizing user anyway but by topic.

Shawn: Alright, let's let this sit a bit.

Shadi: Wild idea. How about swapping How PWD Use with the BIZ CASE.

Shawn: We did have it that way last week...comments?

<shawn> http://www.w3.org/WAI/redesign/2011/sitemap2010b.html

Shawn: This has Biz Case in Getting Started section, etc

Shadi: Maybe leave "For people who use the web"...in Getting Started.

Shawn: For discussion, straw proposal is Getting Started includes How, Basics, third untitled section, ...

Liam: Except Mobile and Older give info on how to make this work on your site. It has Guideline content not found in the others.

Shawn: We want to find a primary home for them but, it's the web - we will point to them from elsewhere. Our central qwuestion now is how to get them there?

Liam: Older and Mibile could go in Guidelines and Techniques?

Ian: Makes sense to me

Shawn: One issue is that first two levels of the doc are not and where will people look for thm? Consider length and complexity of sections. In card sort, we thought they should be pointed to from Guidelines, but people would not look for them there. Also want it to be easily avaialbe to those who don't look from Guidelines persepective.

Liam: Take out sections of Mobile and Older that are specific to Guidelines and put them in that technical section.

Shadi: I kind of agree with you, but am hesitant about making it unecessarily complex.
... Shawn you used the word Inclusive Design.

Shawn: Yes, it was suggested but there is a distinction.

Liam: Is there a reason to always include accessibility - we are in the WAI after all.
... inclusive design as a subsection of accessibility

Shawn: and we can expand the actual title and use the truncated version in the nav.
... more brainstorms?
... Let's pretend we have upper level category that includes Usabiliy, Mobile, Older ,,what would title be.

<shawn> shadi: Inclusive Web Design

Liam: design for all

Sandi: I will go for Inclusive Design, that's what I advocate

Shadi: It fits in with other sections

Liam: agree, nice progrssion. Or if at other end could be Beyond Accessibility

Sandi: Beyond Conformance?

Shawn: Where are documents that talk about Involving Users?...under Implementation right now.
... good brainstorms?
... so how about that reorg? Biz Case into Getting Started, swap as Shadi suggested?

Sharron: I'm comfortable with it.

Sandi: Getting Started is Why rather than How - makes sense.

Ian: I think they belong in separate section as they are in current web site.
... in translations?
... currently we have a sepaarte area and they make more sense there.

Shawn: If we have the 4 documents - Biz Case, FAQs, Intro, Essential Componenets etc

<shawn> 1. Introduction to Web Accessibility

<shawn> 2. Essential Components of Web Accessibility

<shawn> 3. Business Case

<shawn> 4. Web Accessibility FAQ [future]

Shawn: how would we title that section?

Sandi: The h2s should be less disjointed and more consistant
... think of someone who is just browsing

Shawn: For people who are writing policy, more users than implementers, may be more or less interested in accessibility

Sandi: why is oredered this way?

Shawn: We want to highlight the newer resources

Shadi: I like that it is the first link. I can easily skip it if I am a developer. If one of my customers looks for resources, I can easily send them there.
... it is important intro information.

Shawn: I have had developers who really like the Complaining doc becasue it helps them get specific info.
... a few more brainstorms about what to call the section

<shadi> http://www.w3.org/WAI/redesign/2011/gettingstarted2010.html

Sandi: Better Web Browsing and Contacting docs are really for everyone.
... don't have answers for the moment.
... first thing is people centric and next is from a certain persepctive.

Shawn: How about Policy and Planning resources
... many are out of date. But we expect to update them this year.
... Let's talk for a minute about hypothetically if they were updated, would that change our organization?
... push them up? It would impact the number we have on the top level. Reshuffle?

Liam: How out of date are they?
... it shows people what WAIs priorities are as well as pointint to info.

Jennifer: If it were pushed up, we would change the name "Policy and Planning"?

Shawn: That is the question.

Jennifer: I would like to see it stay at the second level but be mentioned at the top level. I just don't think that legislation really convinces people to do accessibility. Maybe it works, but...

Sandi: It doesn't work. I work for government and can tell you that. Making people care for other reasons is more effective.

Jennifer: I want to see a compromise position. Keep policy in the title of a top level, but linked from within.

Liam: In the UK, the legislation and government guidance actually is making local government agencies aware and submitting to inspection. It does work.

Shadi: Whether we like it or not, there is a driver in legislative action.
... another thing is not only policy documents need updating but also evaluation and implementation.

<Zakim> shawn, you wanted to comment on WAi priorities and to say Planning Accessibility -> Implementation and Policy Resources

Shadi: as we consider the need to edit resources, also consider that.

Shawn: Mention that WAI has a very delicate relationship to policies. Our work related to policies must be careful. Many things that WAI does not do related to policies. Recognizing that policies are important.
... had talked about doing something like Implementation and Policy Resources rather than Planning

Liam: Just Implementation and Policy

Sharron: I have always liked Planning in the highest level

Shawn: Opened the possibility of making the interim changes next week, understanding that there is no such thing as perfect. But hoping to do this as an interim imporvement while we plan the longer term update.

<shadi> http://www.w3.org/WAI/EO/Drafts/access-use/accessibility-n-usability.html

Web Accessibility and Usability Working Together

<shawn> http://www.w3.org/WAI/EO/Drafts/access-use/accessibility-n-usability.html

Shadi: Primarily the intro section has been changed from the discussion of complementary goals, so the reedit changed the approach.
... what do people of it (all read the section)

Ian: I made comments in the survey

<shadi> - Paragraph 2: 'and other web tools to make them accessible to people with disabilities, inclusive, and usable for everyone', 'to people with disabilities' seems unnecessary, does 'accessible, inclusive, and usable for everyone' keep the meaning? I think we've already discussed this but it still doesn't read well to me.

Shadi: so the suggestion is to remove "people with disabilities" from second paragraph.

Shawn: My only concern is that we have not yet defined accessiiblity as related to PWD yet.

Sandi: I am trying to write a docuemnt where we can define these things. Usability is specific to tasks, whereas accessibility is much more descriptive in tems of conformance, etc.
... where the crossover and the differences are.

Shawn: leave PWD in the sentence or not?

Sandi: They need to be absolutely clearly defined. If you say that there is no need to differentiate, you will have the whole world of both come down on the doc.
... trying to mitigate the potential damage.

Shawn: Let's talk about that point. Those who remember previous iterations may remember that we had clear defintions from both.

<shawn> encourage those working in usability, digital inclusion, etc. to coordinate with existing WAI guidelines, WAI, and the accessibility field

<shawn> clarify WAI's position that optimum accessibility is achieved with both standards and real people

Shawn: Universal agreed that there are no clear definitions today. A majority of the community has not agreed, especially where the line is between them. Decided that our purpose was not to make that defintion. So we stated our purpose very clearly
... and made it clear that our goal was NOT to be the document that does define this demarcation.

<shawn> http://www.w3.org/WAI/EO/changelogs/cl-accessibility-n-usability.html

Shadi: I basically agree with you. Not sure I understand the problem and in particular why the usability community might be displeased. None of the comments we have received so far indicate a need to differentiate.

<shadi> Sharron: at first Ian's suggestion to remove "people with disabilities" makes sense

Sharron: I agree with Ian

Shawn: Any objections to taking "people with disabilities..." out of that part?

<shadi> ACTION: accept Ian's suggestion to remove "people with disabilities" from paragraph 2 of the introduction [recorded in http://www.w3.org/2010/11/26-eo-minutes.html#action01]

Shawn: Shadi, given that has been removed and in light of reviewers comments, do we need to have more discussion about the definititons?

Ian: do we want to explicitly state that?
... that it is not our purpose?

Shadi: several comments have been incorporated or addressed. I don't recall much discussion of our need to define.

Sandi: Usability is task oriented, but not always. We test both and I support the purpose of this doc, but must also recognize the difference.
... if the purpose of the document are to bring the two comunities together, the commonalities and differences must be clearly articulated and in the doc it is not.

Shadi: Can you be more specific?

Sandi: Generally from my point of view the teo disiplines need to be more clearly defined.

<Zakim> shawn, you wanted to say "This document encourages increased communication and coordination..." -> "The purpose of this document encourages increased communication and

Shawn: As Ian said, we should perhaps state - This document does not define...
... not sure we want to go that far, but perhaps could qualify.

Jennifer: In the original language that defined what we the goals of this document, maybe some of the language can be more explicity included.

Sandi: I agree that if we set this out explicitly and manage expectation as Jennifer said, we will create a much more open document that people will feel that they can participate in.

<shawn> ACTION: consider : "This document encourages increased communication and coordination..." -> "The purpose of this document is to encourage increased communication and coordination..." and/or more clearly stating the goals in the intro. (the "main goals" we have in the changelog, like Jennifer said) [recorded in http://www.w3.org/2010/11/26-eo-minutes.html#action02]

Jennifer: The fact that the goal is to "encourage" communication will help focus people's thinking about the purpose.

Shadi: OK, next section that changed was under Understanding Accessibility ... readers were confused by the jumping ahead.

<shawn> changed: http://www.w3.org/WAI/EO/Drafts/access-use/accessibility-n-usability.html#accessibility - the first paragraph is the same; the rest changed. (note: will put the links back in)

Shadi: there are links that will be added back in to the Older, etc

Shawn: comments?

Sharron: Does everyone know who "power-users" are?

Liam: Can't recall who this is written for, but it would make sense to developers.

Shadi: Power users are not the first group I would think of - rather mobile users, kiosks,

Shawn: There was a comment that said why keyboard use is good usability. But the long reason may take too many words, and we may not want to add that complexity.
... can return to the original.

Ian: Not comfortable with last sentence...

<shawn> Websites, tools, and other products designed to meet accessibility requirements are more usable for everyone.

Jennifer: Is a simple solution to say "more often'?

Ian: Yes, that is what I was thinking.
... When things are made accessible for a specific group, it is often not accessible to others.
... whether desinged to meet accessibility requirements or not, may still not be usable.

<shawn> Shawn: but we're talking about meeting accessibility requirements for all...

Shadi: I'm wondering if we move the entire sentence rather than putting in another qualifier.
... I would argue that I have yet to see a website that is less usable becasue it was designed to be accessible.

<shawn> Designing websites, web tools, and other products to meet accessibility requirements makes them more usable for everyone.

Ian: I would agree, but it is a different thing.

Liam: I'd rather be stronger than more precise and wekaer.

<shawn> Websites, web tools, and other products that meet accessibility requirements are more usable for everyone.

Liam: the thing that can challenge the truth of the statement is "designed to.."

Sharron: agree

Ian: yes, I am happy with that

Jennifer: I like the strngth of it, but for those who do things with hidden CSS and so forth, complex wrong-headed things that DON't make things more usable, do we just ignore it?
... it just bothers me.

Liam: what about "that are highly accessible"?

<shawn> Products that meet accessibility requirements well are more usable for everyone.

Shadi: One thing we've particularly tried to do in this section is move away from Guidelines. Much of that went into the Uable Accessibility.

<shawn> Websites, web tools, and other products that meet accessibility goals are more usable for everyone.

Jennifer: I am willing to let it go.

Shawn: No, this is a good point, we should resolve.

Shadi: The point that Jennifer makes - that people think they meet requirements and actually haven't - that we address that point in the next section, so is that OK?

Sandi: here is an illustration - what Ian said about an image and the alt text says their name. If the task is to find a photo, it succeeds. but if the alt text is not correct, the task fails.

Shawn: Looking at time, we must move on.
... Pull out the idea of accessibility goals...

<sylvie> not too long

Liam: Think we should publish and if people are excited, all the better
... with a willingness to respond to commnets

Sandi: Building websites with accessibility in mind makes them inherantly more usable for otheres.

<shawn> Websites, web tools, and other products that meet accessibility goals are more usable for everyone.

Jennifer: what about that meet requirements effectively

<shawn> ... that meet accessibility effectively well are more usable for everyone.

Shadi: properly

<shawn> Sharron: ...that effectively meet accessibility requirements...

Shadi: effectively speaks to developers ore?

Ian: only for some types of developer

shawn: goals?

Ian: like goals and effectvely
... improve the current sentence.

Shawn: Next part of Ian's comments...

Jennifer: Does linking to things like ISOP docs add credibiltiy for usabiloty people?

<shawn> ACTION: Shawn look at definitive overview of ISO 9241 to link to [recorded in http://www.w3.org/2010/11/26-eo-minutes.html#action03]

Ian: Don't know, but top search results are Wikipedia and then Swiss docs.

Shawn: 9241 defintive overview - will research. If we don't have it, will be less credible.
... propose we leave it in and link to a definitive overview.

Jennifer: it would also promore accessibility people to be thinking about it too.

Ian: yes, agree if there is a good doc to link to.

Shawn: other things, Shadi?

Shadi: No other changes were small. Highlighted sentences that people responded positively too. List of situations encouraging cooperation, etc. slight updates editorial changes

Shawn: Can we consider the comments that we receive, Jennifer you have referenced some of them. Are you comfortable with how we have addressed those comments.

Jennifer: As comfortable as I can be with the lack of knowledge of the field that I have.

Sharron: Yes

Jennifer: Hopefully the same people who commented will help promote it. Seemed they appreciated and thought it was worthwhile.

Ian: comfortable.

Shawn: Shadi and I will address the open issues - then publish next week as a draft?

Jennifer: Yes

Ian: agree with Liam's position

Shadi: we have tested the waters, and though it is not a guarantee and Sandi has warned us about what the reaction COULD be, I think it useful to put it out there and work on a final version.

Sharron: agree

Shawn: Thanks for your extra time and input of perspectives today. have a great weekend.

- DRAFT -

EOWG

26 Nov 2010

Attendees

Contents

WAI website navigation/information architecture/site map short-term tweak

Web Accessibility and Usability Working Together

Summary of Action Items

Scribe.perl diagnostic output