Note: the agenda of the meeting for 23 and 24 of october 2008 can be found at: http://www.w3.org/WAI/EO/2008/10f2f
Each of the participants introduces himself.
SAZ: Outcome of literature review is involve users in evaluation
SAZ: Two things, 1 knock out evaluation, 2 look at involving older users
SA http://www.w3.org/WAI/EO/changelogs/cl-impl-users.html
SAZ: Today we want to go through requirements, purpose and objectives then look at the document itself to review structural changes.
SLH: Not just taking "evaluation" from document but making it broader and seeing what to add.
WL: Are we going to see what will appear where?
SAZ: let's start from top down. Signs and square brackets show what is to change.
SAZ: Let's look at purpose goals and objectives.
SAZ: First idea is to introduce web accessibility for users with disabilities and older users, this is the first objective.
WL: There is an implication that older users with disabilities are seen as lab animals rather than participating. Am I misreading?
SAZ: It is clearer in the second bullet. The intention is to involve people from the start. Any thoughts?
SL: Maybe it's too much wording? We usually use "design for all" more inclusive language. This can also include children.
SAZ: We all agree is it is design for all but the question we get is how do we involve different groups.
SAZ: Other inputs?
SK: The title is more neutral as it is involving users. The sub heading leaves me thinking: is this a WAI decision to only talk about People With Disabilities and older users. Does it ignore other vulnerable groups?
AA: we want to go from concept to ??
AA: The focus of WAI is disabilities, so we drafted as such to stay focused.
AA: we include all but focus on PWD
SLH: Agree, we need to focus however should we say "web design" (broader) period. not specifically accessibility
SAZ: Comments on the first sub bullet of the first bullet?
SLH: What is the web design life cycle?
AA: Concept to maintenance and all inbetween.
SLH: It's difficult to define a web design life cycle.
SAZ: The development process, keep it neutral.
SLH: Not sure we should introduce a process in this document
<andrew> ACTION: andrew - involving users - amend 1st bullet from 'designing for Web accessibility' to more simply 'web design' [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action01]
SL: There are a lot of problems with one user, don't have to always include experts and so on. We don't need to define the process but maybe talk about it at the start.
SAZ: Include some of the stages at least...
WL: This is a recipe for the design of that page...
SAZ: Should we introduce the process or not?
MS: No, but we should include examples.
SAZ: Want to talk about stages but not define the process.
SAZ: So we need examples, stages scenarios too?
<shawn> lots of nods for don't define the process up front, just mention the stages with examples when it comes up in the doc
All: Not scenarios.
<shawn> ACTION: andrew - involving users - amend 1st bullet from 'designing for Web accessibility' to more simply 'web design' -- also throughout, e.g., the title [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action02]
AA: We could have simple examples in the introduction.
AA: For example don't bring in users at the end but at the start.
SaZ: Test early on and often.
SAZ: So remove that first sub bullet?
AA: No, change it to say include users at all stages in the process.
AA: Introduce all users at all stages of the development process
MS: Important to clarify expectations and role of users in process of including them.
MS: Designers have wrong expectations.
SAZ: They expect users are experts?
<andrew> ACTION: Andrew - involving users - change sub bullet 1 to 'introduce the concept of including users at all stages of your design and development process (from the start to the end)' [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action03]
MS: Yes, often they expect users to bring solutions. This is wrong.
SAZ: Should we add as a sub bullet?
<annaz> First list what all the stages are and then decide to involve users in all those stages or not
SLH: This is heavily based on usability testing and we need to bring it up higher. It's not just user testing.
<andrew> ACTION: andrew - involving users - under the cautions bullet, mention that users aren't necesarily experts with solutions [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action04]
Maybe we mention it, link to it...
SLH: We need to emphasise we include people throughout.
SAZ: Do web developers have knowledge in usability testing? Where is the threshold of explaining.
SLH: Maybe we need to talk about that now.
SAZ: What is our expectation of the readers.
AA: Plus one to Shawn's suggestion. Most web developers don't have an idea so we need to introduce the idea
SAZ: Let's switch to the audience for a bit.
SAZ: Audience sub heading.
<shawn> ACTION: Andrew - involving users - consider (at some point) "usability testing" or "user testing" [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action05]
SAZ: We want to include people outside of Web accessibility.
AZ: What is the purpose of the document? We need to list requirements. What is the specific requirement?
SLH: Clarify what is the purpose of this document.
SAZ: Describes what the main document is.
SAZ: This is a document for us.
SD: This requirements document is to include older users. But not specified in the document.
SAZ: That is a point.
<andrew> ACTION: Andrew - involving users - make sure the requirements title and intro refers to this as an update/evolution of the existing 'involving users' [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action06]
SAZ: We need to clarify up front and what are the requirments. Not a search and replace of "PWD's" with "PWD's and older users".
SK: Age is not a disability.
WL: We all know we are getting old.
SLH: There is social and otherwise
SAZ: Let's look at the audience and who the document is for.
SAZ: Comments?
SL: I think usability professionals is important, we want them to land on this document.
SL: We should keep that group in mind.
AA: That is the point of the note.
AA: We could write for one group or another group.
SAZ: The take away is specifics.
SLH: This shouldn't say usability testing but usability professionals.
MS: You don't have to tell usability professionals about testing but remind them to include older users.
SL: We can write a document for both groups. It can catch both.
<Andrew> ACTION: Andrew - involving users reqs - change 'usability testing professionals' to 'usability professionals' in audience note [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action07]
SK: Web developers know about Web development, not accessibility.
SLH: Many usability proffessionals are scared of including people with disabilities.
SLH: Would rather have usability professionals testing than non usability professionals.
SD: Not sure if Web developers will include testers.
SD: Some know how to do user testing but not with people with disabilities or older people.
SL: In Sweden in the big companies usability staff are good but don't have the power to change things.
SAZ: What about developers who write bad alt text...over descriptive.
AZ: Need to explain what is Web accessibility development. Then you can see where to involve people.
AZ: Often people are coding, then a problem happens and then usability experts come in.
AZ: Need to explain here where usability experts should be involved.
AZ: You involve the usability expert who then involves the users.
SAZ: This is an important point. It was geared to testing and the evaluation suite.
SAZ: There are things for usability professionals, but also Web developers.
SLH: This is a draft and the title will change.
MS: We're talking about big companies and big money but usual projects are small.
AA: Yes, more smaller than bigger projects.
MS: Normal informal involvement of users with disabilities.
SD: As a small agency do you have the time to test with users?
MS: Not all projects do but we have a network of people who we can include in projects.
SL: The aim is to encourage people to at least try.
<shawn> ...even (just) my mother would be better than not my mother
SAZ: Is there more than one primary audience and who is the document for?
SLH: Let's define what we want and see if that works.
SAZ: Usability professionals is one audience, the other one?
AZ: techy web developers.
SAZ: what about evaluators?
SAZ: Usability should be secondary?
AA: Or two primary audiences?
SAZ: We have two audiences: web developers and evaluators. Who do we want to address primarily?
SLH: Both, but we can change that later.
SAZ: Usability professionals should be in the primary audience.
<andrew> ACTION: andrew - involving users reqs - audience: include usability professionals in primary audience and see if we can write for both (but be willing to relegate them if it doesn't work) [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action08]
SLH: We put usability professionals including practioners and educators.
<andrew> ACTION: andrew - involving users reqs - audience: include educators along with usability professionals [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action09]
SLH: Secondary audience, what do we keep and add?
MS: Decision makers and accessibility professionals.
SAZ: Why
MS: You need to convince decision makers
AA: For accessibility professionals it's a reminder.
SK: Have we included educators?
SK: They may not design but they communicate this so they should be secondary.
SLH: Maybe educators it's own secondary audiance.
SAZ: Secondary audience we have decision makers, educators and ??
<andrew> ACTION: andrew - involving users reqs - audience: separate educators as it's own secondary audience (as they are teaching/guideing not doing) [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action10]
SL: The decision maker may need another document.
SD: Don't exclude profesisonal evaluators as they may not think about older or disabled users.
MS: I include evaluators in this.
SLH: Splitting hairs, leave the audience as is
<andrew> ACTION: andrew - involving users reqs - audience: secondary audience - include accessibility professionals [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action11]
SAZ: Back to purpose goals and objectives, baring in mind the primary audience.
SAZ: How much explanation do we need especially as we have a group who knows about this and a group who probably don't. Do we explain Web design life cycle?
SLH: We should see when we get into the document.
SAZ: Encourage people to do what they can.
SAZ: You can do a lot yourself.
SL: Can also include usability professionals to include PWD's and older users.
SLH: This needs to be broader than usability testing
SAZ: Do we add another sub bullet?
SLH: Include people before testing.
SK: We could put it in an order.
SH: Many organisations don't do any usability testing. Better to do something than nothing.
SL: This won't scare usability professionals.
SAZ: Even web developers can do usability testing!
SLH: Doesn't have to be formal testing. Make it more positive and less specific.
<andrew> ACTION: andrew - involving users reqs - 'encourage' - change sub bullet to be more positive, and mention earlier involvement [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action12]
SAZ: Third bullet says "encourage inclusion in user testing". Want to drop "in user testing". Next we want to include encouragement.
<andrew> ACTION: andrew - involving users reqs - 'encourage 2' - drop "in user testing" [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action13]
AA: Encourage people to not just include people with disabilities but also older users. Just drop off "in user testing".
4th bullet: Address a few on the most common problems.
SL: Need to be more positive.
SAZ: Do we explicitly mention some of the problems and pitfalls?
SLH: i.e. here's what you do but be aware of this.
SLH: We need to watch scope.
SAZ: Maybe just a short example.
WL: Strike "the most serious common"
SLH: Biggest problem is size and scope.
SLH: Can only address most serious problems.
SAZ: We can't make this a book
SAZ: This is an internal document.
<andrew> ACTION: andrew - involving users reqs - 'cautions' bullet - add: try to indroduce them in a positive language; substract "most serious" [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action14]
SK: Should we set an objective that you should be able to read this document in a set time?
SLH: Good point. We set a size but not a time.
SK: Set an hour?
<andrew> ACTION: andrew - involving users reqs - consider adding "time of reading" to constrain the length, e.g 1 hour [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action15]
SAZ: Bullet "Not be a comprehensive resourse for usability testing", comments?
SAZ: Sub bullet...
MS: Agreed not to define it but to reference it.
SL: Remove bullet just leave as "It is not a comprehensive resource"
<andrew> ACTION: andrew - involving users reqs - ditch "more to encourage ..." [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action16]
<andrew> ACTION: andrew - involving users reqs - change "move resource from E to I ..." to a note [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action17]
SAZ: Looking at the current document at http://www.w3.org/WAI/eval/users
SAZ: Title is a placeholder.
SAZ: Starting with the introduction. We can edit the "evaluation" aspect.
SAZ: Any other changes needed?
SLH: Should we look at higher level rather than section by section?
SAZ: Let's look at overall structure.
AZ: Title says what should be in the document but is it tied to text.
SAZ: Would it work if we removed "evaluation" from the title.
AZ: is this a web development process?
AA: this is an existing document that we make broader.
SAZ: Do we want to talk about development of anything including software
SLH: is the guidance any different depending on web pages or authoring tools?
SAZ: What's the scope? We spoke about web content development
SAZ: Is it any different?
SLH: Let's wait and see. Leave in the requirements as a question mark.
SAZ: We need a working title.
SK: Involving users in web content accessibility...
SLH: Should this be broad i.e. involving users in web design.
SLH: Web development
SLH: So should we not focus on just accessible or overall development.
AZ: You have ARIA, WCAG, ATAG, all of these documents and guidlines we want to deliver to you.
SLH: When you develop something you want to involve users with disabilities, period.
SAZ: Trade off between providing something general (content tools etc) and giving specific information on what they can do and when.
SAZ: Can add a note to say you can apply this to any aspect but this is more about web development.
SLH: When we get into the document we may find that everything we say applies broadly
AA: But the title is what makes people pick it up.
AZ: The reason for clarifying the title is so that I can comment on the content.
<shawn> ACTION: andrew - involving users - requirements: consider whether this applies to web content developers only, or broader to include authoring tools, browsers, etc. (furhter discussions on the document may clarify this) [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action18]
SAZ: In the scope we have this as a one hour reading material. It is an overview not specific guidance.
AZ: Will we then have something specific as a seperate document?
SLH: Specifics not in scope of WAI's work.
AZ: Different companies have different processes.
MS: I want to include the word accessibility. This is our focus, we want to involve users in the process regarding accessibility.
WL: We're trying to get everybody to hire more "crips"
SAZ: It's about making the technical people understand what this is about and include people with disabilities.
SAZ: Let's go back to the direction of the document.
SAZ: There is a question beyong web development and accessibility.
SAZ: If we make it broader will it be less attractive to our primary audience.
SAZ: If we knock out WCAG from the first sentence will it still speak to web developers
SAZ: Do we knock off "web accessibility"?
SK: Need to define web accessibility. Removing so much from the sentence means that we loose meaning.
AZ: Need to knock off evaluation conformance,
SL: Usability and accessibility are two different things.
SAZ: Should we specify first who we are talking about?
SAZ: Let's skim the document.
SAZ: How does the document reflect against the requirements?
AZ: It's ok
SAZ: This document exists in the evaluation suite but we are re-purposing it.
AZ: Analysing accessibility should be higher in the document.
SLH: It's an overall "How do you analyse accessibility problems".
AZ: It's more like processing results.
SL: We should include "diverse users" in or near the introduction.
SAZ: It is more a caution.
SLH: This section is: when you are including people with disabilities make sure you include people with different disabilities.
SAZ: We want to pop this up more.
MS: We have to understand assistive technology in order to understand how people use it on the web.
SL: Also you can't develop just based on how one you see one screen reader work.
SAZ: Different audiences use the web differently.
SAZ: If you use different people you can catch issues and differences of how you use the web.
SAZ: Second paragraph in the introduction talks about benefits... we should broaden this. Should it be a seperate section?
SAZ: We should mention something beyond assistive technology.
SL: I like the word diversity as it's broader.
SAZ: The third paragraph in the introduction.
SAZ: "When Web developers, managers, and other project stakeholders see people with disabilities use their Web site" should this stay there or be moved to benefits?
SAZ: It is a selling point for managers.
<shawn> ACTION: andrew - involving users - consider adding a subsection on "Benefits" which would probably include the current 2nd, 3rd, 4th paragraphs [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action19]
SAZ: An issue with the document is it jumps into evaluating.
SAZ: Do we at some point want to mention some of the stages of evaluating.
SAZ: Does it need sub sections i.e in design, in development and so on.
SK: Ideally developers are starting a fresh but a majority of the time there is an existing site with a planned redevelopment. This is the real world.
SLH: Good to add a scenario. The most common is that people are redesigning...
MS: It's not just new sites but new features, new applications on the site.
SAZ: What changes with involving users if whether you are redisigning or starting from scratch.
MS: Not much, maybe order.
SLH: First step is lean basics of how people with disabilities use the web.
MS: Think about people with disabilities and older people in your target group.
SAZ: Brief introduction first, then benefits of including diverse users. What is the third step, learn the basics?
SAZ: We want to highlight redesign.
SAZ: Highlight what can be done at the start. Should examples be a section?
MS: Maybe, not sure where examples would go.
SL: Examples should be on the side as we are talking to different people on different levels.
MS: Examples are important
SAZ: Examples in the context of benefits?
AA: Or the context of where users should be involved?
SAZ: What are the 5 benefits of including diverse users?
SAZ: how to involve users - 5 things to say.
JK: To understand the results of the user.
JK: Need to raise the development question to attract colleagues to the document.
<shawn> ... not just people who already have an interest in accessibility, but broader audience
JK: Should weave accessibility problems to the document.
SAZ: Other aspect of analysing is learning.
<shawn> hs: important to have someone who can translate the user findings to the developer/designer
SD: I would say include users early, take needs into consideration as to what they want on the website as mostly the site is designed according to the decision maker.
SL: If we are talking to techies, we have to make them wake up early in the document and read on. Flag diversity and test with it. People who read this might not think about users at all.
SAZ: There are three things
SAZ: 1. Introduce the benefits,
SAZ: 2. Explain the diversity of users and situations. Not only blind users, not testing after the site is done.
SAZ: 3) Give them ideas about how to interpret and analyse the outputs.
WL: Teach you how to participate in the process of user centered design.
SAZ: Want to include some of the terminology from usability?
SLH: What's missing from the document?
SK: My last user testing I did highlighted the site lacked content and meaning but was accessible. Made me think how you need to communicate your message for the user. The document doesn't cover this.
SAZ: This goes into the early stages of the site, asking why you are making the site in the first place.
SL: Also is in the details of testing early
MA: You can test the navigation without the site....
SAZ: Part of also test as part of prototyping
SAZ: Is there information different to different stages
AA: Yes, you should be filtering issues out.
SAZ: What you are looking for is different at different stages.
AA: You can prevent problems arising...
SAZ: We should try to highlight some of the stages of development and what to look for in some of these stages.
SAZ: Anything else missing?
AZ: Check the requirements document.
WL: Missing brevity.
MS: potential problems and pitfalls but that is in the requirements document.
SAZ: and is referenced throughout.
SK: How about a section on creating opportunity for users with disabilities.
SK: Points when you can test out your ideas.
SAZ: Do we list stages?
AA: that is too specific.
SK: Got to create the early concept opportunity.
SAZ: Giving them nuggets.
SAZ: Other things missing?
JK: To include blind, dyslexic, older, younger examples of groups.
SAZ: Do we want to enumerate them, list them to break myth that it's just blind users.
SAZ: May be usability professionals who have seen it accesibility as a small thing rather than bread.
SAZ: Involving users as a whole benefits all users.
SLH: One proposal is that our terminology is diverse but we clearly say disabled and older users.
SAZ: Want also to point to how people with disabilities use the web.
SD: Regarding the tone, the document is for web professionals...maybe it should use the second person more.
MS: Minimise the notes
MS: The document shouldn't be too technical.
SL: Keep it as simple as possible for noon native English speakers.
SH: Is the section on notes more useful to non English speakers or should it be integrated in the text?
SL: Keep it simple and seperate.
SAZ: Back to Sylvie's point on first, second person. Preferences?
SLH: Prefer the active voice.
All: Agreed. Active voice.
SL: Will we discuss the detail for the document more?
SAZ: We can't do sentence by sentence. Want to seperate editorial comments, Andrew first must do a pass. So is there something that Andrew needs to know now.
Shadi: from the agenda, we covered this morning the users and looked at the requirements and other documents, and now switching to inaccessible web sites.
...Look at the document itself.
Shadi: coordinationstuff.
<shawn> http://www.w3.org/WAI/EO/changelogs/cl-responding.html
From the agenda it's linked in the agenda : requirement document for responding to organisations for inaccessible web sites.
Shadi: look at purpose, goals and objectives. Make sure we are on the same page.
...Rationale: proposal on how to approach that. Any thoughts? Everyone has done their homework? Any comments or thoughts on this?
Anna: who is the target audience for this?
Shadi: dealing in just a sec.
... primary audience: people to report web accessibility problems. Then
bullets on that.
... any comments on the audience.
Jack: question. Do we want to include in the
audience people that are reporting? are they going to know about the
material. The people that know W3C point people to this site?
... shawn is a typical user. Comes across inaccessible Web site. Does not
know anything about W3C, typical user.
We want to give her the materials the ways to report that. In addition to materials for this site, how do we need somebody like a somebody that is saying there is a great site to report to an inaccessible site owners. Do we want to be able to have to point her to the site?
Shadi: not directly people who report
problems, but people who give information to others to report problems.
... there are trainers, supporters of Web accessibility, two subbullets.
... wanting to report, or to use this information to spread it.
... Let's keep that in mind, people who don't report directly but who
advocate for Web accessibility. Use information to help you comunicate.
... We should keep that in mind to make sure we come back later? Would that
work Jack?
Jack: yes I think it would work.
<andrew> ACTION: andrew - responding reqs - audience: make sure people working with site users are included to refer this resource to them [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action20]
Shadi: other comments on the audience, who this is for?
Lisa: one question about secondary audience. Do you want to address authors and developers, so know what mechanism who can use to report that. Does that make sense?
<andrew> ACTION: andrew - responding reqs - audience: 2nd - developers and authors to provide appropriate resources for feedback?? [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action21]
Shadi: Yes. I think we should hold that as
well. If there is a good spot that fits nicely in, I think we should
certainly put that in. Andrew have you noted that?
... other thoughts and comments?
Shadi: any distinction between the organisation of the document?
Shadi: primary audience: people who want to
report on accessibility problems. Trainers, advocates, come across something
and want to let an organisation know that they have an issue. Go back to
purpose, goals and objectives. Rationale for doing this, and a proposal for
what to do.
... is there something missing?
Susanna: for us it's quite often frustrating users, calling us you should go to the Web site. People complain to the wrong service. Then do complain ..
Shadi: mabe it is for the approach area. You mentioned tone, do you want to use the active voice here again?
Michael: in my experience, accessibility inexperienced users, that is users that have no concrete idea about web accessibility usually tend to look for the problems on their site. They think there is missing competence for using web sites. They are usually not people who are complaining. The disability organisations are organising complaints. They are aware about inaccessible Web sites, about barriers, and know how to complain.
Shadi: so we don't need this document.
Susanna: who experiences this?
... totally disagree.
Michael: those you know very well are those who are complaining.
Susanna: I disagree as well with this.
Shadi: many other disability organisations. I also think that a lot of people who encounter problems don't voice their issues, ...
Susanna: in Scandinavia and in Europe as a whole, small disability community. Young people are not in those organisations. We have to be much more....
Andrew: most organisations work on principle: hundreds of complaints respond but not to one complaint.
William: a lawyer advocates or, order to deal with where there are going to complain instead of demonstrate to finding site to take care of themselves and show.....
Anna: if I scroll down, promoting advocating for web accessibility requirements I think that that should be the document where maybe this response should be folded into. Inspite of advocating for Web accessibility. I take this document as standalone if this document is on the site of a ... complain by filling out some form. W3C is standardisation body. I would like promoting people to complain of to find some case lawsuits.
Shadi: not willing to find case lawsuit. Beyond technical standards development. We hope that when somebody sends a complaint it will be taken seriously. We are promoting people to voice the barriers they are having.
Andrew: when I complain, make sure that the complaint is constructive and gives the organisation something concrete to act on
Shadi: someone purchases a product. But could not buy it because the paying form is not accessible. Very angry. Is this somehting
Henny: the best approach is to... and list the types of information the user should give: type of software using, version, ....
Shadi: encourage users or the audience to send
constructive responses or contact.
... anything else on overall goals, purpose, approach?
Shadi: do a live outline of the document. Transcribe it orally. There is a draft document "promoting and advocating for Web accessibility" part of the reading.
<shawn> previous draft document <http://www.w3.org/WAI/EO/Drafts/promote/promoting-draft.html>
Shadi: not necessarily bound to this.
... we will construct an outline of the document, and fill in the blanks. The
document starts with some introduction.
... discussion about selecting an approach. Is that still something
useful for this document, now we have a more focused approach?
Susanna: we may be very direct and say: "if you have problems with a web site we encourage you to contact"
William: if you are unable to contact do the step 3.
Shadi: if successful, go to...
... one thing we have to bear in mind as well, nobody has the time and
expertise to do this.
Michael: we should propose a minimum report including the URL, what kind of problem you have, and maybe what kind of disability you have. Have a more tecnical additional question which people might include, like screen reader, browser version.
Shadi: the page should certainly be in there, and the type of problems they had. The more information they can provide, the better.
Shawn: In 2002 I had a letter I used to send to
some people. It is on the Web. Maybe anybody can use it.
... if you use a screen reader, send that. If you use specific settings, send
that.
William: to the person you made contact with? In my experience the ability to make the contact is almost always the point.
Shadi: to summarise: the first step is to encourage the readers to make the contact with the owners of the Web site.
<shawn> OLD example of an email on inaccessible site <http://www.uiaccess.com/notice-1.html>
Shadi: the next thing is to tell them how to make contact. Which pages and what the problem was. And of course any other information, the more the betteer. What is after that?
Susanna: Where they could go to learn more.
Shadi: That's where the previous document is really interesting, how to make it better. Stuff about how they are aware about accessibility issues. This is getting a bit more specific, so it should be further down, but it is important.
Susanna: this should be a short help to get. If
you're interested you could read more.
... two different documents: because for the readers it is difficult to
report a problem.
Andrew: keep it simple ...
Michael: We should also tell the people whom to contact. Not enough to contact the webmaster but the higher the better, if you contact the management. If they can find out, we can tell them. We should insist on getting an answer. If it's just an e-mail it is so easily becoming a spam in the mailbox.
Jack: I think Michael is right. Some way to be able to get a response to be able to track the response.
Shadi: play detective and find who is the right
person. Where does this fill in to the document.
... is that further down?
William: you are looking for a response. People who are doing this will take this request to their lawyers...
Shadi: the first step is to make contact. Do you already mention they should find the highest responsible person. Try to look for the right people? Does it belong further down?
William: we got the who, we don't have the how.
Henny: try to get the feedback form.
Shadi: reminder: first thing to do is to encourage people to make contact with the organisation with inaccessible Web site. The other thing is what information they should convey in their response on the querry. The third, now we have asked for a response. Below we have contact. Preferably tell them how to find the right person, now to contact. What to respond and how to contact the organisation, would that be correct?
Johan: if the user experiences inaccessible web site, how should he look for the right way to contact? If the user is not able to navigate on the site, how should he find the contact?
Shadi: aim the highest.
Shawn: give some examples of people you try to
contact. Here are some places to try to contact, depending on the size of the
organisation.
... do a list of persons to contact, you don't have to just contact one
person.
... as W3C perspective, not recommend to contact the media at the first
step.
Shadi: who to contact, where does that belong?
Andrew: how to find the contact should be a separate thing.
Shadi: Where does this fit in into the whole document?
Andrew: contact page, as a last resort... telephone directory.
Michael: obligation (legal) in Austria to have legal information about Web site.
Suzette: could not trace in the UK. What is the European law, a directive, or country by country.
Michael: a directive is not a law. But there is a law in each country to apply a directive.
Shadi: what other oever 2 documents do we want?
Henny: have we talked about what to do how to follow up?
Shadi: there is: ask for response, which is a very small thing. Can you say more?
Henny: people need to know what to expect, just saying follow with an organisation.
Andrew: what do you do next?
Henny: organisation might contact you,...
Shadi: in that case send them pointers to standards.
Henny: you can get a response, "sorry it's not our problem".
Andrew: you might want to have further follow up.
Michael: should we provide some ideas whom to send carbon copy of this conversation, maybe some antidiscrimination organisation, disability organisations, they might help for the process. It depends on the organisation you are contacting. Person who might be responsible for discrimination in the public sector, you could contact this person in carbon copy.
Shadi: why not contacting the media?
Michael: might be an option.
Henny: at RNIB, we recommend people to e-mail the organisation and copy RNIB in.
Shadi: maybe under bullet: consider including others. People agree to that?
Henny: we should remind the individual to keep copies and keep a log of that contact.
Andrew: one thing that came earlier was a sample e-mail.
Suzette: I think sampling is a good idea. email is good.
Shadi: [goes through the headings of the former draft].
Andrew: does it matter if it's a bank or a tax office?
<shawn> Sylvie: say how you can explain the problem in a way that the web developer can understand
Andrew: final question: do we want to give additional references to pass along?
<shawn> http://www.w3.org/WAI/EO/2008/10f2f#Agenda
Shawn: for today I would like to start big pictures about WCAG 2.0.
Shawn: we have a list of several documents: overall WCAG document, document on WCAG 1.0, navigating WCAG 1.0 quick tips on accessible web sites, overview of WCAG 2.0, WCAG at a glance, quick tips for WCAG 1.0.
...Sylvie had mentionned the idea about having a simple document on the status. Resource suite on transitioning from WCAG 1.0 to 2.0. That included: subdocuments on how WCAG 1.0 and 2.0 compare, the benefits of transitioning from 1.0 to 2.0, how to transition web sites from 1 to 2, and transitioning policies from 1 to 2.
Shawn: give some high level on what you think
about those documents. What we should say about WCAG going.
... what do you want to send people to?
Anna: if I think of WCAG in multiple page version, there is a table of contents I can select click, can't we switch into this document which is structured in chapters and select single printable version, and read the whole. For me it's too many small pieces.
Shawn: what do you want to be at the top of that?
Suzette: the overview.
Shawn: what do you want to talk about in the overview? Transitioning? other aspects?
Anna: talk about why to transition.
Suzette: at the moment we need one of those, but in a couple of years we won't.
Shawn: how many people know WCAG 1?
Michael: we might consider to pick out five
situations: somebody like... a big picture of Web content accessiblity,
for this situation we have to list three documents maybe. I know about Web
content Accessibility, and I want to move forward to WCAG 2, and what should
I do in this situation.
... how to evaluate web content for accessibility?
... we have different points of entries for different situations for
different people. We also need a very good navigation structure to cover all
the rest.
Suzette: is there intended to have a document which is transitioning?
Shawn: suite document on that. Benefits of transitioning, transition policies...
Anna: if we can title that adopting WCAG 2. That could consist of starting from scratch of WCAG 2, and for those who know how to transition from 1 to 2.
Susanna: summary of the WCAG that is readable to normal people?
Shawn: spent a lot of time. WCAG 2 at a glance, did you look at that?
Susanna: no design, no picture?
Anna: is before and after demo going to be part of the suite?
Shawn: we are doing more video. One that just waiting for me to be finished.
Shadi: there will be a published report which will mention the implementations. But no link to the sites that implemented WCAG 2.
Shawn: before and after demo should be linked.
Michael: depends on the task force.
Anna: are you planning similar resources for other WAI guidelines?
Shawn: especially ATAG in January but not able to do it in the next couple of months.
Andrew: it will take a while for the transition to happen, and in some places WCAG 1 is referenced in policies just as WCAG.
Shawn: The highest level of WCAG ... You can
meet WCAG 1 and meet WCAG 2.
... any concerns with that approach of highest level page?