1. Introductions

All introduced themselves. Of special note is our host Industry Canada's
role in shaping the Canadian government policy.

MFL: Will be required of all Canadian government websites starting
in 2003. Requires Web Content Accessibility Guidelines (WCAG) P1 and P2.
Old sites may need to be retrofitted. Expect the disability community
will be ready to complain as of 2003-01-02.

FB: In the Industry Canada office, we use many software tools and
platforms, cannote and reject government sites that are inaccessible.

VS: Checking now for compliance, and can indicate site rejection.

Background -- WAI Education and Outreach Working Group

JB: The Web Accessibility Initiative (WAI) develops strategies and materials
to increase awareness among the Web community of the need for Web accessibility
and to educate the Web community regarding solutions to Web Accessibility.
Part of the effort is the promotion of WAI guidelines.

JB: At Linz, Austria: gave keynote address that was well-received. Also
WAI web content workshops were led by Sylvie DeChateau and Henk Snetsellar,
both introductory and more advanced. Wendy Chisholm also presented on evaluating
web sites.

KA: Uses the Accessible Web Design, using the Web designer's three-hour
training materials in her weekly Wednesday training sessions for State
of Connecticut web masters.

JB: Curriculum on Web Content Accessibility Guidelines, and Training Resources
for Web Accessibility have had good use.

Templates and Tutorials

JB: At the recent meeting Cannes, there was no agreement on what these
should include.

JB: Matt May has ideas. He did a site deliberately designed to fail many
accessibility guidelines. Wendy Chisholm gave a session using it.

MFL: There is a potential legal problem if take a real site as bad example.

JB: The British Royal National Institute for the Blind (RNIB) has done
this with Number 10 Downing Street. Got lots of press attention.

JB: A common question asked by reporters: "Give names of a few web sites
that are accessible."

JB: Review teams, using protocol recommended by WAI. Many types of organizations,
such as Braillenet, may want to do this.

JB: Jutta Treviranus, head of the University of Toronto Adaptive Technology
Resource Center, is chair of the WAI Authoring Tools working group, and
will be with us tomorrow.

MFL: Many kinds of review are useful: preliminary review and conformance
assessment.

Materials helpful to people with disabilities

JB: We have to start writing materials for people with disabilities to
help them use our materials, and use the access tools already available.
We may be able to adapt our materials, such as to include how to find accessibility
capabilities in existing browsers.

Agenda Review

JB: How People with Disabilities Use the Web -- Minor edits are
done, Major edit http://www.w3.org/...

JB: Terminology translation problem: "learning disabilities" has different
meanings in different counties.

JB: Example: Mr. Sands, a clerk with cognitive disabilities (example seems
unrealistic to several commentators.) Let's fix it, as only example holding
up the document.

JB: Matt May worked on the Webvan and NetGrocer websites.

MFL: Will recreate from memory the cognitive disability comments previously
sent to JB.

JB: ?would Mr. Sands have a computer at home?

MFL: His work is to re-stock shelves, based on recognized empty spaces,
and note the withdrawal from inventory.

SHe: It is important to have his interactive work.

ACA: Be more up-front about why he had trouble using web-site.

JB: Did text update directly on-screen, not minuted here.

HBi: [See it when posted by JB].

HBj: [Joined at 10:45 by phone after break]

SD: [Joined at 10:45 by phone.]

JB: completing on-screen editing of Mr. Sands.

JB: End editing How People with Disabilities Use the Web at 11:40.

JB: Will review change log and meeting notes to make sure they are incorporated.

JB: Next week the new draft of Web Content Authoring Guidelines
will be ready for public review.

MFL: Common Look and Feel, Canada has 1100 people who might review.

JB: As more people come into EO, more people do editing.

SHo: Offers to do some editing.

Review Teams and Gallery Framework

JB: Intertwined are documents on review teams and gallery framework.

JB: Have agreement in Europe for doing reviews. Also seek volunteer reviewers
and reviews of web sites. Need a framework for how review teams would work.
Create a WAI Review list.

JB: Not now expecting to do in-house review by W3C WAI staff, as if done
well would get too many requests. In another part of WAI we are trying to
improve the automated review with tools and process. Encourage techniques
document on web-sites. The evaluating web-sites document is there. The
Web Accessibility Report Tool (WART ) a checklist for doing a review. Manually
fill out form on evaluating a URL, identifying problems.

HBi: This may imply too much knowledge needed by the reviewer and accessibility
understanding by the webmaster.

JB: Develop description of review teams and encourage their formation.
How to Review Web Sites for Accessibility. Each team can have its own email
list. Periodically review team results by another team. Recommend site
for gallery (of accessible sites). WAI will not run the reviews.

JB: Europe has a number of efforts now under way with reviews as objective.

JB: One or two staff persons to be focal points. Person knowing assistive
technology has a role.

CL: Persons showing what is wrong.

NL: National Federation for the Blind wanted to participate. What is
needed to qualify who the evaluators are, and their skills. Who qualifies
for the job?

HBi: Who judges that someone is qualified?

JB: We'd need to explore what is sufficient qualification? For people
who are new, they'd need much training. Experienced evaluators might skip
much of this.

JB: WAI will need help with the gallery. Review teams help setting it
up.

NL: Both automatic tools and manual evaluation will be needed.

JB: What does this document address, vs. the Evaluating Websites for Accessibility
document.

SHe: The planning document is old.

JB: Didn't do whole description of the planning process.

SHo: Unclear how much WAI will contribute to the process? And what authority
will it have?

JB: W3C will not be hosting review teams. In particular, what is EO contributing
and what will they be getting out. Would like reviews in many languages.

KA: What is the liability of WAI or individuals for review/reviewer error?

JB: Conformance evaluation needs disclaimer, on all documents.

[Break for lunch.]

Review Teams and Gallery (continued)

[KA scribe]

JB: before lunch, went over review team site, came up with questions,
didn't look at the Gallery, how do review teams relate to the Gallery concept.

JB: the gallery concept, a collection of sites, live site, that meet a
certain level of web content accessibility guidelines. The gallery would have
examples of different kinds of sites, different levels of conformance, languages.
People have asked: prove that it can be done. We would be able to point to
the gallery and get a sampling, rotate sites, issues: how you maintain assurance
that the sites are still accessible, endorsements. Tie-in to review teams
- they would help us find and monitor these sites.

MFL: government of Canada is waiting for W3C to do this first.

JB: Matt May has ideas about review teams.

JB: before lunch, long list of questions about review teams:
Who qualifies to do reviews?
What does the audience for this document need?
What does WAI need?
Are there ways in which the review teams could be structured so they
could help each other?
What aspects of this process are handled in which document?
How much effort should EOWG put into this?
Issues of liability?
Compliance with your own country's policy?

SHo: Can all the skills be embodied in one person?
What are the skills?
And experience and knowledge?
How do you create a working group? (community)

SHe: We are taking on the responsibility of defining a working group -
group management, project management.

HBj: Among things we have to take into account - how do we get the eval
team, work with local group, different disabilities.

JB: Other issues we need to deal with include people who have tech knowledge,
have some exposure to accessibility, ending up with contradictory advice,
provide clear advice to people who don't have the background to know all
of that.

HBj: Danish disability organization - go to main office, we can assign
someone who knows about this matter.

JB: dig in and answer these questions, structure of this document: goal,
approach.

[JB is editing this document in place, text not minuted, some basis discussion
follows.]

JB: We want to establish the baseline or mechanism resource to enable
human review process.

SHe: Are we getting involved in other people's review team process? Practical
or blue-sky? Practical: I don't see how we can be involved at all. I'd
like to do more as a group. Blue-sky: I found a national center for disability
- Illinois - park or public area - these people will come and do an accessibility
review.

JB: WAI's European work - is contracting to do training of people who
do evaluation. Members of review teams get priority. The are obligated
to coordinate, They need to have involvement and resources.

MFL: Is the goal to provide guidance to organizations, methodology?

JB: We want people to do quality review of web sites.

CL: Who provides certification of groups or individuals doing certifications?

JB: When do you have to have a team?

HBj: Test with people with different disabilities, then you must have
a team.

SH: We should focus on the skills, experience, knowledge, 99% of the
cases, it will be a team, but doesn't have to be.

HBj: question of definition of team.

JB: Earlier we talked about solo reviewers. It wasn't whether or not it
was possible to do solo evaluations, but more: is that what we want to recommend?

CL: Not a relevant question - I can be a single consultant, up to me who
I want to hire, taking on certain responsibilities and then farming them out.

JB: A consultant may say "we have a process".

ACh: Skills are what count, not the person, skills needed all the same.

FB: we've done this, template sent through IM and QA - came back 5 times,
training would optimize the process.

JB: We shoud go ahead and write a doc "Review teams for WS accessibility."
Note: we are using the team loosely - to represent the different skills
that should be brought together, could very well be all in one person.

DS: The idea of using a person with a disability, it's true many people
don't understand, has to have a verified skill level.

JB: We need to clarify backgrounds of those roles.

CC: Currently is writing "how to plan a website", link roles and skills,
different definitions of the term "web developer" red flag on the word
team - what is team vs. a group?

JB: Team is a closely integrated group.

ACa: We can break it up: skills that are need, experience, and some other
category, sensivity?

VS: We have one person who reviews the sites, not trained, each time comes
back with different answers.

JB: Process can be intersection of bureaucracy and accessibility, EO can
help with "what is a good review? Skills, roles needed." Often reviewers are
doing their best but they're clueless, they would like something that's clear.

ACa: We need "criteria for effective review of web sites."

SHe: Where does evaluating web sites end and where does this document
begin?

SHo: to supply the gallery? Candidates? Take out the bit about WAI providing
coordination and oversight, the reason I would like to get more specific,
I'm not so certain it holds together without let's have a review process.

JB: Agreement for training - provide a certain amount of reviews, different
teams doing reviews on same sites, include quality checks.

VS: Reviewers need skills.

JB: title"criteria for effective review teams."

HBj: I agree with JB title - we have to be careful not to set up a paper
that ruins the work we've already done, compare to WCAG 2.0, people could
do reviews, we want to emphasize skills, should ATAG be mentioned in this
paper?

JB: This is an entirely different review process.

HBi: When something gets into a gallery, the owner would be notified,
this is going into the gallery with these comments,

JB: no site will go into the gallery without some negotiation with the
site owner.

ACa: We need to identify for the reviewer - job requirements - specific
sets of skills and knowledge.

NL: the word 'review' bothers me, rather use 'compliance audit, identifying
to what guidelines, W3C, 508, usability? This is what should be specified
in this document.

HBj: people with disabilities - usability testing.

NL: Subject is broader: usability not just accessibility.

JB: you do compliance audit, review is too vague? For others, the audit
is too strong

SD: don't use "you must do this, you must do that" review teams are for
conformance, not for preliminary review

JB: what do you think about the title "criteria for effective review teams"

SD: too directive? People should have 'guidance' or 'advice', but not
criteria

DS: I agree - it's a 'soft' document, important to have a way to understand
what skills are needed, you won't assume someone knows what they're doing
when they can't.

VS: cannot make it very direct, make it a balancing factor

ACA: not afraid to be direct, shouldn't be haphazard, recommended criteria

JB: suggested criteria, recommended criteria

JB: whatever we say, people are going to foul it up, two tiers for the
document

SH: for the types of skills you would need to bring to the review process

ACA: Skills, experience and sensitivities that one would need to bring
to a review process, demonstrated a technique for keyboard navigation.
It's easy for people to foul up. They think they're getting it right, but
they're not.

NL: I don't understand what teams are we talking about, inside review
teams or outside teams.

JB: both, use in a diversity of contexts

JB: Questions: do you have to have a team? Not sure, more like a team.

JB: leaning towards 'yes'.

SHe: encourage teams, but not rule out that someone with a complete set
of skills and experiences could do it themselves. We want people to realize
their limitations

JB: and people to have something to aim for.

MM: all of this will fall to the QA team, you need to have sensitivities
for this, "get sensitive", it's important to have the needs broken out
right away, bulleted out, if you don't have them, acquire them.

MFL: Sarah said: in our goal, you have the word considerations, be the
bracket, the things that alan said, will help focus on what those things
might be, we seem to be circularizing, no one's disagreeing with each other.

JB: do you have to have a team? We were leaning towards yes

SHo: with a caveat, encouraged but not mandatory HB: it help to have more
than one voice

JB: who could qualify for conducting the reviews?

JB: Are we advising or setting a baseline? We are advising [getting nods]

CC: advising on setting a baseline, creating a benchmark, we're waltzing
all the way around, some HTML knowledge, etc.

JB: what does the audience need - something to point to see the criteria
and skills, where to get training, what to looks for in [human] evaluation
resources.

JB: what does WAI need? I think WAI needs feedback on all sorts of things,
the eval web sites document, having teams use it in a structured way, on
sites that might be nominated into the gallery, WCAG 2.0, how different
evaluation tools work once they start implementing Evaluation and Repair
Language (EARL).

DS: if you have limited resources, what works for you can be quite different.

JB: what is handled within each document? Pretty fuzzy on that, hold
to eval web sites document, this document, whatever it's called, addresses
the people side of the review process.

SHo: looking over the eval doc, talking about usability testing, I have
the resources to set up a review team, click on this document. Could it
be a note?

JB: eval will eventually be a note, this will be a linked resource.

JB: this document will be a supporting doc for eval web sites.

JB: how much effort is WAI putting into this? WAI would provide some suggestions
on how to put together review teams, training to review teams, priority for
Europe, we might at some point, provide feedback to review teams, that's
it, no network of coordinated review teams, review list, maybe a list for
the gallery.

JB: we wrote this document, we update according to feedback, provide training
on evaluations, provide feedback on some evals, cross-review, ask for feedback
on gallery nominations,

MFL: fee for service?

[more introductions]

JB: contribute reviews in exchange for training?

ACh: Yes.

JB: this document is the planning of the approaches, coordinate review
teams, within the scope of the document, the approach, if we were to try
and answer the question, how much effort would WAI put in?

SHe: new to some of us.

HBi: would require resources.

JB: new position opening in Europe.

MFL: are we going to specify the definition of evaluating? Part of the
process and part of the feedback loop.

JB: we only deal with conformance, not preliminary review, everybody agree?

Concept of Gallery

JB: A gallery of websites is something, if were lucky, the review team
thing can help develop. There are several things about the concept that
terrify the group when we talk about it. We'd like to get candidates up
there, eval done, webmaster fired, new site is a disaster, phone call at
1 am, W3C is being sued,

JB: How to it with a live site? Matt, can you talk about how to do automated
monitoring?

MM: a way to make sure the site has maintained its accessibility, we would
give them a distinctive link, to the gallery, or to WAI, unique identifier,
this site is the one that was tested, when the site changes, don't use
that link any more, if a site is redone, the link disappears, the link disappears
from the gallery, they go out of the gallery, the site we have validated,
is the one that remains there.

SHe: any change to the site and I'm off the gallery?

MM: only wholesale changes to the site, the easy way to say this is that
the checking is done once.

NL: WAI for the people with disabilities, meta-tag to indicate the site
is in the gallery?

HBj: authoring tools, being in contact with the company that made the
authoring tools, conversation with web master. In Denmark. To point you
attention to a sign I ran into yesterday: www.a-sites.org NLB's online
gateway to accessible web sites.

SD: I don't trust webmasters, to use the link correctly.

HBj: is a spider or crawler possible to see if a site has changed?

MM: not really, a news home page "changes" every day, need a similarity
checker.

[break, end minutes by KA]

Agenda Item: Continuation of Gallery

[Scribing notes latter half of Monday afternoon by Francine Bordage]

JB: 2Q EOWG Deliverables - Review of the policies relating to Web Accessibility
last 15 mins of the day. Will not do the check edits. 10 Templates tutorials
30 minutes on clarity out of the Gallery Discussion Tutorials of template
development - end of February we had a discussion of having a gallery safely.
Candid sites that were perhaps a template of a web site that was accessible.
Take a lesson/tutorial on making navigation bars with CSS, coding examples,
etc. We should not be doing the tutorials but EOWG could do the templates.

Membership loves the activity - W3C is getting ready to broach the subject
of usability. DC - November sponsored conference. Tutorials could be done
by the UIG (Usability Interest Group)

MM: There is a lot of work being done in usability. There are people who
are producing usability information but its only a small pieces of reams of
information that is available for 40K. Getting it out from behind the curtain
and it hugely advantageous to the web. You will get to see interaction that
you wouldn't get to see on an open interest group list. This will be a high
traffic mailing list. There is strong deliverables that can come out of this.
There should be a charter for it. But there is still a need to have it in
addition to the consumer. Establish the producers of information, crating
the guidelines for usability. WAI will have hand in participating in this
initiative. If they are not chartered deliverables, we should be working
together on how to get this out. How to do this properly, things that are
widely usability but not accessibility. They share a common medium and others
that are accessibility for a broader range of usability issues. Once the
UIG gains attention, it will be s

KA: If access keys are not working there would a tutorial on how to make
them work?

MM: WAI and Usability ultimately this information would be part of this
interest group. There is disagreement on where the two merge or interact
with each other. They are attached to some degree and it is more advantageous
to the user to know that there is one place for them to go to get this type
of information.

JB: Wish list of tutorials we wished we had. Combination of description
and coding examples.

MM: If these things are created they will be the most cribbed pages on
the web. The templates that are part of the tutorials.

JB: We may want to determine what a template would be and what we want
to provide on these templates

KA: If you had these types of tutorials, you would not need the templates

JB: The template would be the results of the tutorials

VS: Our UI teams struggle with some of the guidelines and making them
accessible. For instance, accessible tables - problem with this type of
things.

JB: US Government did a conference on complex data tables. Guidelines
do not go far enough with complex data tables.

CL: Both can be accommodated if we have a good process.

JB: Hoping that by separating the

HB: Did you build templates for all the examples you did in the tutorial
you conducted?

CL: Each page should have a tutorial dedicated to each of them. If I were
to redesign it, I would do a tutorial with the template at the end.

JB: Templates for navigation, forms, etc.

KA: We have examples of bad code and good code to show the differences
between the two.

CL: There were indications to keep this at a minimum since Some places
where the bad code confuses people.

SHo: A Template would be something that you can copy and paste and a tutorial
can show or explain how to do something.

JB: Templates would be a type of grab and run. Tutorials are explain and
show. They will remain inter-related.

Even if this was an established group, we could not count on them until
we have firm up an understanding with the group.

JB: Discussion about how to come up with a gallery approach with some
safeguards. Look at what is in the document for comments.

MFL: How big did you want the gallery to be

Anyone who nominates sites, they would contribute review resources

MFL: Have you or WAI consulted any legal people in terms of this, do they
give you good vibes?

JB: General discussions and some of it was that we already have things
like this, such as conformance reviews of software, primarily collaborative
reviews with companies and then the list of disclaimers companies were
instant we put on the client side. We have to do things of the sort to get
past this.

ACH: Consideration of the purpose of the gallery, if the purpose is to
provide real examples perhaps one or two are sufficient

JB: People felt there should be a diversity of sites (4 or 6 primary types
of sites ), there would be different functions and then it was important to
have a diversity of languages, including a multilingual and bilingual sites.
There is an assumption that everyone should be able to see it and get the
idea, not true.

FB: In reference to using a Robot to check if pages or architecture of
a site has been changed, we at Industry shut down or block IPs if they
hit our sites with robots, therefore, it would not be possible were we are
concerned.

ACA: This could be a disaster, if it does work, it could be fantastic
resource. Too many things could go wrong, if there could be an arrangements
with Web masters, that they will continue or have a template that is accessible,
if they are the only templates they will use, it could give us a mechanism
of having more of an assurance that they will not be changing the sites
drastically. The other possibility, is that organizations would probably
strive to be recognized by being part of this gallery. Could set up static
sites and sponsor a static version of their sites and once verified they
have the right to update their site to ensure good content.

NL: Versioning of sites may assist in trying to ensure that you are aware
of changes to a site. We have created new designs

JB: Caching and freezing stuff will probably not work because of ongoing
changes to content. Propose to do a brainstorm session that would try to
create a most paranoid version of a gallery with the most extreme protections
imaginable. We may find that people are so eager to get into it, that we
would end up with something we are extremely pleased with

CC: Imagine how the University would get into the Gallery, I am the main
web master but there are several others, they do change periodically. I
think that best practices would be dealing with the organization and making
the organization responsible for adherence to the guidelines etc. The other
is when the news changes, the site changes, we have banner pages that how
would be handle continuous content changes. Front page, tier one and tier
2, would it be everything within my control and what happens to other contents
being fed by other departments or web masters.

DS: Optimistic we can have a gallery for living sites, it would have a
tremendous impact on other big enterprises, within a context of paranoia,
how do you resolve the issue of companies wanting to get into the gallery.

Gallery Fears

JB: If we develop the most cautious gallery, what would we include?

walk through certain levels of disclaimers before reaching to
the gallery, reader has to actively acknowledge the disclaimer, decide
way ahead of time in what order you would display the sites in the gallery
so there is no preference to any company because their names are alphabetically
first, disclaimers and associated priorities pre negotiated with organizations.

CC: Every site you would identify what it was about that site
that made it exemplary, which items made it on the list, what conformance
level and why it was placed in the gallery.

NL: This would give us different levels of conformance -

JB: What we wanted was AA, you would like the gallery framework
to say something about every site Say something of what is highlighted
in the site to have it in the gallery.

ACA: Every site would have to be reevaluated each time there
is any change made to the site.

VS: Set up and evaluation each day (3x).

Hourly checks! Take advantage of those automated tools.

Link to another organization that holds the responsibility.

Anybody who fulfils the same criteria as one already on the
site who submits a site for review, gets posted.

using the rotation concept with a history of previous to avoid
anti-competitive risk.

Require that sites also have pics or ncsa? Ratings that ensure
the rating of the content is palatable.

Competitive issue may not be addressed by the rotation of the
listed sites.

ACh: Can't handle the verification aspects, could we shift responsibility
to the site by linking to a page containing a statement from the site listing
their goals and policies and changes to the site, describe their participating
in the gallery and their commitment to maintaining their standards.

Human intervention - search engines and subject directory, for
this to work, we need a more subject directory type model. We need somebody
to monitor. Rigorous human checks. Do a comparative of the sites to review
if there have been major changes done to the site. You would not need to
review the site, just make sure that it hasn't changed.

The scope of the gallery site, if we were to do this a safe
way, you would have a gallery of home pages, rather than a gallery of
web sites. You could capture screen shots of the home page and be part
of the gallery. We could do a thumbnail of the home page and list a date
of when the site was reviewed. Return to the concept of cached pages.

HBi: Only list sites that have a real contact that you can submit
feedback.

KA: Confidentiality on the part of the reviewers - not allow
anyone to know who the reviewers are going to be. Lets say 3 companies
submit reviews at the same time and they are all into conformance at the
same time, how to decide which one goes first, second or third.

DS: Versioning control and verification so that you can't juggle
the sites to fool people into thinking that the site has not been changed.
Control of versions and see history of versioning. Providing standards.

NL: Scope of the project, how can you claim that they are accessible
because of the size of the site. No one can check entire sites that are
extremely large. How can we differentiate with those pages that are compliant
rather than claim an entire site is compliant. Narrow the scope, drastically
by if companies self-assess themselves, they need to really take responsibility
for stating that they are conformant.

KA: I would echo that I don't trust web masters in making only certain
pages accessible and leaving the remainder unaccessible.

DS: There would have to be a list of standards that are established to
state that a site is accessible and those would have to be met to ensure
that they can be posted on the gallery.

NL: If I go through the process of making my site accessible, I wouldn't
want anyone copying my site and using my development to copy into their
design.

CC: Some summary of each site and a disclaimer stating the reasons you
are pointing to a particular site and posting it in the gallery.

JB: Should we do a gallery that was small with tight control on what is
posted? or should we go beyond this.

CL: Easily start a gallery of predominately government sites. These can
safely be representative sites since government don't have a competitiveness
reason not to be posted.

MFL: After the gallery, negotiate with industry associations to do galleries,
bankers association, universities, perhaps give out an award for compliance,
etc.

SHe: Concerned about the time and effort spend on policing it.

ACh: It too complex to handle a document that can be delegated to one
person, perhaps we could outsource or have it sponsored. Otherwise, use
an independent site.

SHe: This could be very useful.

HBi: As an uncompensated individual, I would rather work on government
and non-profit sites of my own choosing rather than tackle industry. Four
or five years ago I did a Bobby analysis of all the SGML-Open (now OASIS)
member company home pages (about 40.) I reported those results, and repeated
the analysis six months later. A few sites improved, some were less accessible.
Discouraging. I was invited to make a presentation at their next meeting.

KA: Take provinces, cities, etc. Is it acceptable for portions of government
sections of other sites being posted - clearer about fragmented sites.
To ensure we are not unfair to industry or government.

DS: Adding a tremendous value to their site, this could be useful economic
measure of the web. How you measure a web sites to conformance to accessible
web sites. Indicator on the progress of web accessibility.

NL: Hugh task, the objective of the gallery should be clearly identified.
Will we be conducting compliance or are we creating a gallery of best practices.
This would eliminate competitiveness. Highlight specific practices rather
than entire sites. Large companies would be willing to pay money to be
part of this gallery.

CC: The probability of monthly changes, and review is highly unlikely.
Seems very unrealistic.

ACa: Possible keeping in mind "setting boundaries", it is not possible
to do it for a site unless it is extremely small. Demonstrate good practices
and compliance on only smaller levels, ex. 5 pages. Should be the organization
being featured take responsibility to the compliance of the selected pages.

VS: It could be possible, but the complexity of UI used in different sites,
what mechanisms will we be using to determine the conformance and compliance.

JB: Certain things should be supported on the site, can be able to do
what is necessary with the site using Adaptive technologies. Guidelines
can be used as a stand-alone evaluation tool.

Business Case for Web Accessibility

JB: overview page, background, 1.5 years ago EOWG wanted to work on guidance
for orgs to do internal convincing, internal planning for Web accessibility.
Envisioned doc that would be outline, business case, imp plan, sample modules
for different environments: industry, education, ngos, WD business. Never
able to collect modules. Carlos wrote module for corporate, people said, wouldn't
work for my company. Wanted resource docs, demographics, cost factors, supposed
to be appendices.

CV: [Carlos joins 9:10am]

JB: Making more progress writing appendices, gave up on modules, let's
have apps be key resources. Split into imp planning and business case planning.
Bus left except AA kept working on it, sent out for review as standalone,
people got confused, though entire bus case instead of one facet. A) Need
to address all concerns raised, b. not send out again until whole suite is
available. Look at skeleton. Outline at top level that expands, other resources.
Currently placeholder text. Needs cleanup. Intro, how to use it, discussion
of marketplace linked to demographics, auxiliary benefits, legal requirements.
Any org has diff processes; some might only ref legal reqs, others take social
resp position. Cost factors involved: do it early, less costly; retrofitting
higher costs. Considerations of different environment - modules that we never
got far on.

JB: Marketplace: Problems getting together demographics. Problems are
internationally there is inconsistent info on disabilities in different countries.
Simple discussion with some pointers to outside resources. Framework of how
to think about disability marketplace.

JB: Cost factors: Content in fairly good shape. Lists general factors.
Lists factors: soft factors (training, outsourcing), impact development process
(trigger processes), efficiencies (server and bandwidth efficiencies, increased
ability to index and search). Should this be here as well as in auxiliary
benefits? Lots of overlap.

JB: Policy requirements: Shell. Discussion of how various policies have
bearing on business case. How to be aware, how to incorporate.

HBi: would governments use this page to develop policies?

JB: No, that would be org policies in imp plan suite.

JB: Left suite in disarray because of imp plan suite work.

Aux benefits: Intent was to write down benefits to all (mobile phone users,
etc). Can look at clear navigation in matrix, look at description of benefit.
Powerful for drawing out relationships. Overall doc close to what bus case
should be, premise started with, besides benefit to PWD, look at all the
others who would be helped.

Questions for discussion Is the tone credible? Can we substantiate all
the statements? In what areas do we need substantiation? Should some sections
be moved to other documents? How do we reference external (non-W3C) materials?
What disclaimers do we need?

CC: Description of what bus case means?

JB: concept but no definition. Main concept is a convincing argument shows
rationale for why you'd so something, costs involved. Decided to differentiate
convincing material from imp material.

Gut-level comments about suite?

AA: need numbers, need to bite bullet with demographics.

JB: need to bring that along next?

AA: short basic doc, reference international docs. We can move forward
but don't let it lag.

MFL: In Canada only have 1991 census - troubling. 2001 census significant
information, not available until 2003.

JB: Deal with inconsistencies. Disclaimer that data is not current.

SHo: redundancy in suite and docs.

Cost benefits and aux benefits.

MFL: set of discrete docs or a document. Set requires redundancy (need
to be standalone).

JB: EOWG tradition: Take one doc and rip it apart. So don't be polite.
Overall suite is not fitting together well.

CC: Might have to write entire thing before you can cut down on redundancy.

JT: Good to view from reader's perspective. That dictates structure. Cut
and past applicable pieces.

JB: challenge from review: substantiate claims. Pointers to discussion,
not statistics that substantiate?

AA: Well-regarded resources. Some hard data.

VS: Design for usability, least common denominator. This doc addresses
these issues.

NL: Can be in both places.

JT: Easy to come up with a formulaic such as, this is what you need to
consider. How do I use the cost factors to create a cost benefit analysis?
What is the analysis I need to do, numbers I need to consider? How do I state
these elements in a cost benefit analysis? Not a good working structure.

LH: Lay out an example in comparison chart format? Working template with
fill-in-the-blank. Use existing model and build on it.

VS: what are we trying to achieve? Template or generic information which
they can cut and paste, but they would use it to build their own.

JB: Goal is to produce something we can write, people in diverse orgs
could take and what we wrote would make it easier for them to deliver what
they need. Thought sample modules would be grab-and-run, but couldn't come
up with them. Give recipe, deliver some ingredients, tell them where to find
things.

VS: template, ingredients, choose what they want and make their own.

JB: what MFL said about outline with verbiage is attractive. Cannot write
whole thing, can at least give a start.

KA: private orgs have own recipe, have to help them fill in info, not
give them structure that is not applicable.

JB: many different approaches to cost benefit analyses.

JT: People haven't thought of benefits and savings, listing components
gets people to consider them.

JB: In aux benefits should focus on tech efficiency and pointers to cost
benefits, etc., and vice versa. Not cross-referencing much now. Aim for that?

SHe: Main doc smaller. Pointers to more information.

JB: Know want to promote, meeting right away, need to grab-and-run. How
about a set of slides with overview?

All: YES.

JT: Case example also helps. Story of group or company.

JB: Wish list category.

AA: Original doc said,"this will happen", turned into "this may happen".

JB: CL, got at heart of reaction we got. First order outcome (audience
reach) versus second order outcome (increased market share). Talking about
bus case that's relevant to many difference contexts.

JB: Change title of section to "increase potential audience."

NL: improve customer experience.

FB: User experience.

KA: Doesn't see terms applying to government. Not going to increase number
of people we do business with.

MFL: well-designed site makes it available to more audience. Not improving
access to info of organization. More people can use Web site.

CL: target more existing constituents.

JB: no more detail about vocab. Gather filters. Entire doc needs to be
checked using first order, and second order.

KA: will check.

JB: terminology perspective.

FB, KA, NL, CC: will check.

FB: have increased audience because people come for training. Increasing
services.

JT: Looking at user perspectives. Look at business case from each perspective?

JB: Tried that.

DS: Gov doesn't look at audience. Not thinking like a business.

JB: Disagree with unilateral motivator proposition. Have seem a lot of
crossovers. Wanted kit that people can select from that works for any organization.
Also suggest that we move on to other questions. Substantiate?

JB: AA comment, like to pull idea: here are some of the subjects you would
want to talk about in a business case, here are considerations about setting
up a business case, in some setting legal requirements apply, but don't stop
there. Add in elements to take the BC further. Give advice about setting
up a business case.

JB: How to use kit. Second half of paragraph - cannot have stats without
substantiation.

CL: Taking out second part is valid.

MM: Not increasing market share, regaining. If site is inaccessible you
have already lost people.

AA: Stats are an aside, a furthermore. Useful to remind people. PWD will
benefit as well.

CC: Ties market share and disabilities together. Need to make this accessible
for PWD. Part of the market share is PWD, generally increase MS, but also
increase MS because site is accessible to PWD.

JB: Beyond acknowledging PWD access...

CL: At least a potential 20%.

KA: Don't they already know that? Isn't this about, okay, what else? This
is about auxiliary benefits.

JB: Are we consistent in saying, beyond disability impact here are some
additional considerations?

[Break]

Business Case for Authoring Tools

JB: WAI has variety of activities. Working groups. Also sponsorship, industry
and government. Work in certain areas. Aligns with work planned. In Europe
has deliverables with focuses that relate, with outside help. Carlos works
as subcontractor. Trying to promote implementation of ATAG for AT made or
used in Europe. Original plan not working well. Develop contacts is localization
departments. Localization processes of software companies is diversifying,
inconsistent, any degree of control over accessibility. MS access is in core
executable.

JB: Leveraging them through EC, EU member state, parliament, stronger
resolutions for WA. Most people using FrontPage are asking for more support.
Document that please. Very difficult to directly impact A feature adoption.
Have to do it quickly. Wrapping up end of Sept.

JB: Carlos wrote outline, now filled in as draft. Attempts to provide
comprehensive and concise reasons for why software developer should make products
that support ATAG. Goal, turn into final fast. Give to developers, see if
approach works, before project ends.

Redundancies, European focus?

CV: Should this be a suite? People working in companies, will this help
in developing a tool?

JT: EO perspective, sold people on accessible Web sites. Hard to sell
to developer without market demand. Selling needs to come from demand perspective.
Missing link, yes, people are paying attention, but in those docs that people
are paying attention add in, the best way to accomplish this is using an accessible
AT. Need to create demand.

NL: Demand is there. Big businesses would like compliant software. Need
enforcement of standards. How can we influence authoring tool development?
Extremely important. Good business case. Talking to developers, not effective,
each are approaching from different points of view.

JB: It would help corporate users if there were more demand and more requirements.
Slip between software developers and software users, it would help industry
if there were clearer guidance on what the software was doing. How about
commenting on 508.

MFL: CIO sent letters to software developers, thank yous in response.
If doc becomes reality, generate letters with business case.

JB: We have that. Questioning software vendors about software support.
Want to start making adjustment on WAI home page. Want home page to be customizable
by user type.

JT: Marketing analysis of WAI. Now people go to WCAG.

MM: Accessible tools make accessible content. Things that write accessible
content and things that read accessible content. Site maps? WCAG is one part.

JB: Find ways to suggest to Web developers how to communicate the demand
to software developers.

NL: Any representative of AT developers on ATAG? How can we influence
ATAG goal?

JB: Dynamics are tricky with developers. We have good participation. Help
develop guidelines. Some have policies not to make statements about implementation.
When ATAG went through, not much dialog or pressure. UAAG very different.
ATAG new dynamic will come into play. Don't think EO can add value into process,
spend time walking through document.

MFL: Is work on WCAG2 impacting ATAG revision?

JT: ATAG is dependant on WCAG. Create a tool which follows WCAG, our work
comes after. ATAG2 can't be released until WCAG2 comes out.

JB: Take template out?

CV: Yes, I'll take it out.

JB: Title?

MM: Business case for accessibility in authoring tools.

JB: No, accessibility to tool. Business case for accessibility support
in authoring tools.

JB: Things that might be best explained in business case resource suite.
Nice to point to from here. Point to entire list of policy references.

MFL: Document has primary rationale. Don't like to be location-centric.
Don't think it's a bad thing to have European references. Doesn't harm document.

JB: When we have more comprehensive things to point to, then we point
to them.

JB: Well into document, nothing convincing yet. How much do we rely on
people following links.

SHe: How about appendix at the bottom?

JR: No. This is point at reader saying, you, your tool, we're talking
to you.

MM: If you write a tool that allows other people to produce content, you're
writing an authoring tool.

JB: Hey you! function. For that do we need descriptions?

JR: Good to have examples.

MFL: Get rid of paragraph, just have list. We're doing business case for
people who create these things, they know what they are.

JB: Replace what is with section that says this document addresses...
and then a bulleted list. Each one links to def elsewhere in document.

KA: How about intro paragraph.

CV: Must reference WOMBAT.

KA: Likes "the term is applied to any software tool that can be used to
produce any type..."

JB: In introducing accessibility in a business case, take out first paragraph.
Work backwards and eliminate where possible.

JB: State of the art, remove first paragraph.

ACh: Change of "in the field of the tool" to "for the content produced
by the tool". If it's a HTML tool, it's the HTML spec, if it's the SMIL tool,
it's the SMIL spec.

JB: Take out first paragraph on almost every section and it would probably
be fine. CV, what's the most effective part of document? What are the strongest
statements that make the case?

MM: The creation of accessible content is contingent on adequate tools.
When tools exist, time is reduced. Therefore it's important for these tools
to be in everyday use.

JT: ATAG compliant tools reach authors who do not have knowledge or will
to create accessible content, cause them to create accessible content.

JR: The purpose of authoring tool is to enable, support and automate creation
of Web content, for authoring who do not want to do that by hand. So when
a tool follows guidelines it enables, supports, and automates creation of
accessible Web content...

LH: After JTs reaching authoring, there are other authors we may be required
to meet benchmarks, clearly there is a gap in AT development, opportunity
to fill that gap and develop a product that will meet that demand.

AA: There is an industry of people creating evaluation and repair tools,
incorporate some of this functionality into authoring tools and capture some
of that market.

JT: Reduce cost of training, evaluation and repair, by using accessible
AT.

CV: There is currently no support for ATAG in market, be the first!

WAI Site Redesign

Here are the parameters of the discussion. We look at the WAI home page
once a year. Where people go on the site for the right information. The
original home page was absolutely horrible in design. Two years ago we spent
4 months and then said lets do this for now, and then what we want down
the road. This was the first redesign. The linearization is nice. We
did that because a year and half ago. The positioning was still poorly supported
by some browsers. We talked a lot about how to organize information. We
already had the WAI resources, and site map. It is something that is an
additional support for finding things. The W3C site index in addition to...
Everybody in W3C was happy for WAI to go first.

The resource index is one of the best ways of finding documents in the
WAI. There are a few known problems with this page. Some of the known problems
are some very awkward redundancies in the nav bar. ...These little red
triangles, there are several problems we started using as twisties. If
you take this off this would look boring, but they don't work as twisties.
There are some redundancies around the word resource. The relationship
nav bar and what is behind it. This one goes to all the subheads on the
page. Within some of the subheads you only have one link. A lot of people
say why not take it straight from the word here and the policy references
and others say the behavior is not consistent. Some people want the brief
info before they land on the document.

What I really came to the page is such and such. For example to jump
from working group to working group. We see participation, and there is
none intuitive leap. Not easy to scan visually. Or you can say about, ...
doesn't work let's go back.

KA there is also two one on the nav, and one in the corner.

JB: We provide a very unfriendly context. What we want to do with the
re-org of this page. Get it better. A better set of sub pages. Some next
level where we wanted to start to make a transition. Works better for different
kinds of audiences. Easier to find things. To produce a customizable page.
A policy which you could tweak, more role informed. We are beginning to
think about things better organized about the roles we have. But with all
the things that EO has on its plate my guess is it would be an error to go
to that right now. We need to work on the page in an incremental way.

The other piece on that others observed was that we are going about this
in a very amateur way. We aren't equipped to really make this great. Proceed
on a somewhat incremental basis. So Matt came along as the team contact.
So I was thinking it would be valuable to look at the page to see what kind
of ideas there were about it. Are there some things for working group info,
to be fixed simply?

MFL different types of groups.

JB: relatively design issues. Third is ...third is what is our future
wish list. One of the other things that is a little problematic on a practical
basis. The group has tortured itself to come up with different nav bar designs
for this. It would delay the suite release by four months. The EO is producing
more and more to the resource suite. On many of the documents a resource
nav bar. Whatever we do on the home page is consistent with the home page.
Coding these separately on every page is nuts. To use a separate style
sheet on every page is also unfeasible. Is an inconsistent as we possibly
be. Matt and I brainstormed.

KA this is just a suggestion, before a major reorg or redesign, to identify
who is coming and organize for that audience.

Vs you mean?

KA someone just getting started, or from a software company. Completely.

MFL I think of Vidya and how she found the site.

SH it would be useful to know how far this discussion can this go? What
kind of effort can we put into this?

JB: lets talk about we are in the third quarter of the calendar year.
Knowing what is on the plate for this group minor content reorg and design
tweaks, like a better nav bar, and not take on the taxonomy, and I am not
inviting a major reorg. If the whole working group feels that way I will
go along with. Think about some minor content improvement, or some minor
design things to try. I want to build a wish list for the future. We would
know what steps we might want to do at that point.

SH you are thinking about the whole architecture.

JB: not right now but eventually yeah. Actually the EOWG can point to
that. Is it too hard to have an incremental discussion?

NL I absolutely agree with Sarah. The first question is that from the
WAI point of view. To tell you the truth is very inaccessible site.

JB: W3C has had lots of comment that it needs to hire web designers and
so forth. I am one of the people saying that the most. We basically are
having a hiring freeze. However what I have been trying to do is figure
within WAI in the next half year or so, in terms of making more accessible.
Try to spread accessibility amongst various sites. The thing is that we
can't hire a bunch of designers.

NL it is important to have a plan in place. Maybe then go to corporate
world and get some help. Go to HP or Wells Fargo who have a lot of participants
who can contribute to that. I can't find any information. First templates,
examples of information. Because your site is a good example.

MM the word structure means something to mean to me and something to others.
The over all structure is the best I have ever encountered. The over all
URLs will never change. Cool URL's never change. But the basis in looking
at information architecture and the taxonomy, on the whole including the
WAI is the difficult in working with is going to be easy because of the great
site.

JB: one of the things I will mention not as an excuse that there is attitude
of sort of colloquialism. A lot of government is making a transition to
a professional. There is sort of a break through to agree and obey. One
thing that frustrates me so much, all the working groups, are chaired by volunteer
resources. Don't have even an organization. They maintain their own web
area, and sometimes they are a showcase, a technology. Try to get the CSS
to march in line with a standard format they will chew you up. I have been
trying to do for a few years, but the Implementation org suite doesn't address
that.

NL you create the compliance programs.

JB: in any case the attitudinal isn't addressed in the implementation
plan. We are beginning such and such metadata. Your working group constituency.
In any case that is part of the context. In terms of the strategy that
we spread from WAI, I am getting a resounding yes. Lets ...

MM this will tie into the next session. How to do templates and tutorials.
A lot of accessibility people way to stretch WAI to come up successfully
a lot of sand box to work with here. This is getting a little out of the
scope of WAI. Here is how to do this. This became a viral thing.

JB: Harvey?

HB take each title in W3C.

JB: no like propagation. Here is what I think for God's get some consistent
navigation, like a nav lock with a link to a WAI site map. To be replaced
later with a better taxonomy. And then try to see if we can get that on
all our pages. Look you are breaking the consistency.

KA why would you need in the WAI site, I would search the WAI site.

JB: the translation is also something within this very working group.
People want that on every page.

NL so on every web site, very easy to fix that. You will have search.
Search W3C very easy to do that. Somebody needs to take as a task. Not
difficult. In terms of investing to create the information architecture.
From the context of roles.

SHO I have a hard time with the whole conversation because I want to do
right, and I don't think we can, the compromises makes me very uneasy. I
would love to see a really well organized User Design, spend a lot of time
on documents that are kick ass. Shouldn't we do this, and we can't find
stuff.

JB: do you think we should stop work on other documents?

Sho maybe. I wonder about this group doing that. I don't think this
belongs in this group anyway.

MA we have been looking at for five or six years. Unless we look at from
a blank slate. Will impose problems into the document. Throw out all the
old ideas and they come right back. Several sets of eyes that are just coming
is a good start.

JB: I had invited Sarah and Alan to say.

ACH I don't have much to have add. I have coped with it, and I know where
there and to find. I haven't thought about correcting it.

NL I will just repeat what I said before. This is where we need to be
in the future. Then to look at our resources. Whatever we have. Then to
start doing that. We have a wealth of information. Not accessible, or
not usable.

MFL I will offer a suggestion. There are fully four or six information
schools and librarian information management users. Someone who studies,
maybe to consider talking to the dean of the school who would come up with
students who have a fresh pair of eyes. A different viewpoint.

JB: I think whatever suggestions people make how to integrate them with
a very complex organization like W3C.

MFL we let a contract to a school. They came up with the most incredible
proposal. We didn't work with them much. They came up with a great document.
Cost 4500 dollars. We didn't expect to get something particularly useful,
but we did. As Alan says we cope. Someone could do this as fist term graduate
project.

KA I just have a couple of thoughts. I agree with Sarah. I don't think
incremental changes will help, and could make it worse. I think MFL idea
and the librarians had great ideas. Maybe there are librarians in W3C that
could participate.

MM I wanted to take a stab at the concepts I had about this page. WAI
assumes a sort of investment. I think structurally I wanted to have that
stuff right here. I would probably tag that. The user space right at the
top is not conducive to scanning. It is not until you get here you first
see this. Under the testing of things the info is in the deadest part of
the page. This stuff tends to get lost. There are things to do about this.
What I want to see bump up the title a little further. What are doing,
a quote, and then go here. Items with primacy with developers. Anything
relevant to that. Break it down into the behaviors. The first step after
you do that after the taxonomy. Create a space to what they are looking for,
which we already know. Rather than GL or AU we don't want the guideline producers
as the home page of the given topic. One of the biggest issues. Behavior
based home site is one of the biggest problems.

FS doing a survey would be good. Gather the information. It would be
quick and dirty way of gathering information.

KA what would do with that information?

SHE people have there is whole field who figure that out. This all established.
How much we can afford to do.

JB: it would nice if we will to understand what we want to do, and why,
be in enough communication to keep this go in the wrong direction. Some
individual to be aware and on top of it. We do need as a group to figure
out not to do the magic.

SHE if you take this on as a task, get someone who knows how to do this.

JB: could you do a presentation?

MM,

DS

MM going back to what was said, analyzing to say, we know the users we
work with. We generally have a dialog. I don't know of any thing that would
invalidate what is said. The behaviors are at least as relevant. You've
got users who are writing content, and government basic to all of these
roles, and then it becomes what are the behaviors...

JB: I want to disagree who the users are. You and I would give very different
replies. Wendy would think about very finite audiences. We don't have well
articulated audiences.

MM I think it would be interesting.

JB: we have one concrete is that - that it would be very good to have
a presentation, user interface design process. So the second thing is the
site is so bad. We should stop all our work. I wanted to check on the prioritization.

KA I don't know if I would agree with Natasha. I just think the information
is findable, I don't think we should make incremental design changes. If
we do and they are, that people would be disappointed if is not done through
the whole site.

JB: be very careful about incremental.

MFL I am cognizant of Alan's statement that he copes. Those coping skills
will be badly damaged.

HB awhile when the google site was broken. I rely upon Google as my primary.

CC I think there is a way to do parallel processing. I think with the
addition with Matt and Shawn and compile something to bring to the group.
I think the incremental thing, if you go with that sort of direction, you
would get stuck in moving forward. I would love to jump in, and use what
is already existing.

JB: let's keep going around. An initial step would be presentation, starting
a plan, a little clean up. Cleaning up some of the mess. Standardize on
that.

SHE I would vote, in terms of priority, the concurrent activity to go
forward with a redesign. I would actually vote against doing clean up at
this point. Start the process of the redesign based upon what we found so
far, best to do clean up now, or interim steps. My vote would be start this
plan toward this user centered design process.

JB: how does that fit into user interface.

VS I would agree with Shawn. I am not going to work. I am involved in
the redesign; I am not saying it is not usable. This goes on and on. Right
now there is a deadline. We need to go ahead. Plan for redesign. I don't
see that as an overlap.

MM another analogy. When you are at the beach. When you stick your head
in the water. Consider that is when you have incremental design and you
have to redo this all the time. If you are going to do a design. Have a
breakwater. Once someone has lost that site, then they are lost. It is not
just one person.

LH I agree with Shawn, I think the search functionality, I would add a
WAI search, as well as a W3C search, that at least my only short term action.

CL I am married to an information professional. I know that process works.

MFL I like what Shawn said. We need someone trained in information.
I agree with Laurie about the WAI search, which is missing. I have always
wondered why the EO is linked.

JB: the guidelines are not targeted.

FS I think of... you would waste a lot of time, fixing one and breaking
three.

JB: Matt is saying a different thing. Documents not having any headers.

FS make clear what is a mandate of the group. You guys make the decision
for going ahead. Only mandate that this group should have.