See also: IRC log
<scribe> scribe: Sharron
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
... 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
... 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: 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
... 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
... it is important intro information.
Shawn: I have had developers who
really like the Complaining doc becasue it helps them get
... a few more brainstorms about what to call the section
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
... 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
... 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
... 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: 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.
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
... 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
... 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
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
... 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
... 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
... 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.."
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
... 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.
<shawn> Sharron: ...that effectively meet accessibility requirements...
Shadi: effectively speaks to developers ore?
Ian: only for some types of developer
Ian: like goals and
... 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
... 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.
Jennifer: Hopefully the same people who commented will help promote it. Seemed they appreciated and thought it was worthwhile.
Shawn: Shadi and I will address the open issues - then publish next week as a draft?
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.
Shawn: Thanks for your extra time and input of perspectives today. have a great weekend.
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) Succeeded: s/Maybe leave How PWD./Maybe leave "For people who use the web"./ Succeeded: s/can we explicitly state that?/do we want to explicitly state that?/ Succeeded: s/ Liam: Last sentence is too defensive, not comfortable with that./ Ian: Not comfortable with last sentence.../ Found Scribe: Sharron Inferring ScribeNick: Sharron WARNING: No "Present: ... " found! Possibly Present: IPcaller Ian IanPouncey Jennifer Liam LiamM Liam_McGee P5 Sandi Shadi Sharron Shawn Sylvie aaaa aacc changed communication coordination document encourage encourages eo increased is joined of purpose say this to You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Got date from IRC log name: 26 Nov 2010 Guessing minutes URL: http://www.w3.org/2010/11/26-eo-minutes.html People with action items: 9241 accept at consider definitive ian iso look of overview s shawn suggestion[End of scribe.perl diagnostic output]