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: EOWG has wide international participation.
JB: Minute-taking volunteers:
Mon AM: HB; Mon PM: KA; Tue AM: SHo; Tue PM: DS.
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.
JB: Evaluating Web Sites for Accessibility CL has provided insights.
JB: Evaluation and Repair tools, there are several in common use.
JB: Alternative web browsers are available.
JB : Translations, quick tips. More coming. On volunteer basis. Seeking some Arabic translations.
JB: Jim Allen is the WAI calendar maintainer. He also has materials that he uses in Texas.
JB: The Policy links are now outdated, how should we manage updates?
JB: References on Web Accessibility projects, to developers, researchers.
See page for links:
JB: Major work has been the Implementation Plan, which is effectively done.
JB: Hoping to have Policies Relating to Web Accessibility updates done, not quite. (JB editor)
JB: Planning Web Accessibility Training (JB editor)
JB: Getting Started, see change log.
JB: WAI Flyer
JB: WAI Resources
JB: Quick Tips
KA: Reports delay in ordering Quick Tips cards,
JB: Josh needs to order another 250K English cards. Non-English language cards are ordered in batches of 5000, some are being reprinted.
JB: How People with Disabilities Use the Web. Many want this, particularly to reference. Needs editor.
JB: Business Case Resource Suite (Andrew Arch, editor)
JB: Implementation plan is more urgent.
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.
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.
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.
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: Need to update reviewer volunteer lists.
JB: Review of Web Site Accessibility -- Planning who will use this document?
SHe: What are the needs?
JB: A number of responses from Europe, sought thoughts.
SD: Requests about interpreting WCAG. Didn't express what they actually wanted.
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.]
[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.
JB: EOWG does weird things sometimes, how to structure document, skills, working together, etc.
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
JB: reality check, we don't know, we're guessing, we don't have the answer yet, suggest now, recommend later
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?
NL: granular
JB: conformance,
JB: how to structure the document?
SHo: let's not talk about, it's too specific
JB: let's see what we can capture, skills, experience, roles, sensitivity, disabilities, definition of review team, knowledge of conformance standards, understanding of usability, awareness of strengths and weaknesses of automated eval tools, other assistive technologies, keyboard navigations, substitutions allowed, measuring tools, benchmark training requirements, objectives, recommending reading, conflict resolution.
JB: Going, going, gone.
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]
[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)
UIG conduct information sessions to discuss issues - WG has a schedule of deliverables.
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.
JB: If we develop the most cautious gallery, what would we include?
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.
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.
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.
HBi: Redundancies with inconsistencies.
SHo: Our audience might not be tolerant of redundancies.
DS: For example, executive making presentation, grabbing things hastily, presentation is inconsistent and repetitive. Affect on credibility.
MFL: concise doc. One doc. Aux benefits references from bus case doc. Best argument or "We don't have PWD" - disputes that claim. For bus case, 1. Aux bens offshoot.
JB: 1 doc, narrative or outline?
MFL: Outline, brief narrative, and resource links.
JT: Approach is integrated in imp plan? Would that have implications for bus case. Once bus case is accepted, then go into bus case?
JB: haven't done that exercise, except for cost factors. Could try a backwards exercise.
JB: May be able to go over docs, cannot answer question about where things belong until more is in place.
SHe: cost factors, know important to point out advantages. Money you can make is the benefit. Marketplace is also auxiliary benefits.
JB: IPS, sections complemented each other. Saying the same thing different ways.
CL: Suite has legal and other docs, do into as planned, and add "And here are aux benefits".
JB: Biggest source of overlap is aux benefits.
AA: Social responsibility and legal didn't fit. Drop them into overarching doc, makes sense.
NL: Present to management cost benefit analysis. Need to talk about cost incurred and how they outweigh each other.
JB: Cost hits, cost benefits on cost factors doc.
CC: Like CL idea, hate to lose composite. Reference that summary doc exists from others.
LH: Appendix?
JB: original concept was limited, device independence, greater usability. No, it goes on. Rooted in overall goal. Let's walk through aux benefits.
AA: Aux benefits. Sections: increase market share, improved efficiency, reducing liability, social responsibility, tables of benefits (market share and efficiency). Linearized table by checkpoint approach and benefit approach. Put together draft doc of how we might provide external resources.
MM: W3C tends to reference own material. External refs maintenance issue. Put in sep doc. Put extract? Cache pages? Approach taken: why included in list and URL.
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".
CL: Intro, "market share and audience reach" statement. Should promote audience reach and consider market share auxiliary benefit. Will send suggested rewrites to the list.
FB: Business bent, what about non-profits?
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?
AA: supports JB comment.
VS: problem. Clients know it costs more, b/c takes more time. Major roadblock, org is willing to find, clients impatient about time.
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: Though, write a business case, why it's important for software companies to follow ATAG. Requirement for implementation was lighter then, backtracking. Helping ATAG.
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.
JR: Tools are safe as long as none break away and begin to implement.
JT: Tools that were going to release that were bought out.
SHe: How about implementation plan for AT?
KA: Why aren't major companies addressing this now? Going to lose market share.
MFL: Web developers are doing accessible work without accessible tools.
JT: Converted market is Web developers who want to create accessible Web sites. Need doc.
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.
JR: Add link to business case suite?
JB: Possible link to WCAG business case?
JT: Don't see argument, good tools make good content. Here's how.
JB: Look at phrasing in intro - Indirect statements, need something direct.
JT: Audience implementer or advocates?
JB: Different kinds of people within software company, diversity of people inside developer.
CC: Might be something in revised 508 legislation that addresses ATAG compliance.
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!
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.
SHE that is what you do in a plan, check in points.
Last revised August 23, 2002 by Judy Brewer