on this page: morning: morning attendees - Business Case Resource Suite | afternoon: afternoon attendees - economic factors - social factors - technical factors - policy factors - planing for WCAG2.0 - QA - I18N
Related information:
JB: Review the agenda. A lot has happened in the last few days. Thanks to Andrew, Alistair, and Miguel for their work on the Business Case Resource Suite. About two years ago, we started to write a generic business case. We want to have a customized suite that we be able to be used by a variety of organizations.
The structure is similar to the Implementation Planning Resource Suite. It has an overview page and four subpages.
AA: The economic factors has materials from auxiliary benefits and cost documents. We pulled these together. Miguel added some additional items regarding return on investment. In benefits: audience expansion, semantic Web integration, search engine effectiveness, and technical benefits. In costs: initial investment, training, technical assistance, software and assistive technologies, developer time, quality assurance and testing. In impact on Web site development process: consistent site appearance, new Web site technology, accessibility testing, changes in Web site update, train developer. Impact on Web site functioning should be considered.
JB: We were trying to divide up the information a little differently.
AA: Social factors broke up into: people with disabilities, employees, older people, low literacy, other language, bandwidth, and legacy technologies. I’m not sure that we have captured all the groups.
AG: Three technical benefits: reduce site maintenance, reduce server loading, enabling repurposing of content. It can allow authoring of content that are aligned with guidelines.
JB: We should start our discussion on the overall framework. Editing will fix language/grammar inconsistencies. We had meant it to be a business case for Web accessibility, generally.
DS: Nice structure.
BM: I’m impressed with what has been done.
CL: I like the social factors.
JB: This is Alistair’s reorganization.
HB: The word “policy” does not suggest that you would find legal requirements.
JB: We should talk about the use of the word “policy.”
SH: We should think about the audience for this business case and how it will be used. Mention other guidelines, where appropriate.
LS: If an organization decides to implement Web accessibility, it is important to front load material.
AA: We are putting together arguments as to why people should develop Web accessibility. They are interested in why and audience. They are not interested in developing authoring tools or user agents. The emphasis is appropriate. We should cover the choice of the tool. Carlos is looking at business case for authoring tools.
JB: We can link all over the place. We have a document “Selecting and using authoring tools.” We should say the right things and not ignore other guidelines that are relevant. The primary focus remains on business case for accessibility.
MK: Do we want to state this?
CC: This would be part of defining scope.
JB: This goes in changelog, Shawn.
MK: Should we say that there is another business case for authoring tools.
AG: There is a definite case for just looking at Web accessibility. These are the benefits that are being passed on to users.
JB: MK, you are saying that it should be precise. Lisa said that there is less separation.
MK: If we have separate business case for tools, where should it go?
JB: There are different options. We could link to it or stick it into the navigation.
MK: There should be another title.
JB: Have a separate section—business case for separate guidelines.
Shawn, please add changelog: experiment with links to other sections or just add another section.
AG: Make sure that both dovetail nicely—no competition between documents.
JB: Can you please add to changelog?
LC: “Business case” may not include government, non-profit, educational organizations.
CC: I don’t understand the title “business case.”
LN: It’s a polite way of saying some hard-nosed. We are saying that this is financial case.
Economic is a nice way of saying the money case.
JB: You have to look at various financial issues. Most of these cross-cut the other areas. Example: technical picks up economic. It’s not the right emphasis, is this right?
LN: Legal is bundled into policy. Economic cuts across all of these.
JB: We need to revisit policy and economic terms.
LN: Started with revisiting the word “business.”
JB: Let me do a devil’s advocate. Any project needs to make a case. We would still think in terms of business practices.
CC: Could use “proposal” “white paper.” The function is—the word is not.
LN: Customizing “the case.”
Matt: Making the case for Web accessibility.
JB: Do people like it? Does this translate?
HB: Building a case?
DB: Why? For what? What reasons? Rationale?
CL: We spent some time on “customizing.”
JB: Since we picked “customizing” I’m not sure that it works well.
CL: Can omit “business” part.
DB: I agree. If we translate, we have to completely rethink concept and terms. It’s a big job to translate a document like this.
CC: Constructing?
AA: Business case works well.
LN: Business case is what business manager wants to hear.
CC: Functionality is correct.
JB: I propose we call this “Building the Case for Web Accessibility.” We don’t use “making” because it’s idiomatic. “Making the case” may cause people to think that this is the case.
AC: Resources for the
DS: Justifying the case.
JB: I am concerned that “justifying” is used in a defensive way.
CL: I am happy to loose “business case.” Alternate terms can go into metadata.
CC: Here we are giving people way to build; not justify. What about resources for?
“Resources for Building a Case for Web Accessiblity.”
AC: This changes the emphasis.
LS: Seems subtle
JB: Are additional words necessary?
AC: People think that these are complete documents; there is a misunderstanding about the documents.
AG: Would people expect links, if use the term “resources.”
CL: Second paragraph says this is a resource suite.
Matt: Headlines have to be to the point. Adding “resources” splits hairs. Put the purpose in an abstract. How to sell Web accessibility.
AA: Could just be talking points.
LS: That would put me off. It is not professional. It looks as if I can review this.
JB: Building the case for Web accessibility. Keep “business case suite,” add metadata. Can we live with this?
JB: No one said “no.” We have one other term to discuss. The word “policy”is considered to be umbrella for legal, directives, guidelines, governmental or official documents. Should we say legal and policy factors?
Consensus: yes
JB: What kinds of things should go into business case?
LS: You should know all the holes in the argument. What is not true? Person might loose the argument because didn’t have all the information. Strongest point is that there is market share.
JB: Are the terms qualified? Extent to which we make the business. Let’s jump into the introduction.
LC: Suggest that people with disabilities are included, not excluded.
JB: I switched because there is a barrier. If use included, this give people a choice.
CC: If leave it in this format, invert paragraphs. Web is the core information.
LS: There is a social issue, economic issue.
JB: Shawn, can you try inverting the paragraphs in the introduction?
AC: Second paragraph, there is clarification needed. “clearer understanding” Do we mean that organizations don’t understand?
MK: don’t start with “but”
CC: change “some” to “many.”
MK: Businesses do business cases for many things.
LN: Many organizations require a clear understanding. Remove “er” from “clear.”
JB: The second section is about different environments. I’m not sure how to great legacy equipment and low bandwidth. This varies around the world. Is this a good set of samples? Are there comments?
LN: Regarding education, may refer to only compulsory education.
AG: There is legislation in UK regarding accessibility to persons with disabilities.
DB: Accessibility would facilitate participation in France.
JB: Can add how it would facilitate greater inclusion.
CC: We have more faculty and staff who need accessibility.
AA: inclusion
HBj: In Denmark, there is total integration.
EV: Students are included.
CL: included
DB: segregated
HB: Some states have bills to make materials accessible.
JB: Now, move to Assesmbling a Business Case. What should we say? This is where we explain that this is the construction set.
AG: Need to gather statistics. Need SWOT. This is one section of the process. Other people have to write other sections. This is not company specific.
DS: Create a team.
JB: Look at the requirements for your system. Look at policy, economic, social, and technical factors.
NL: I put together implications of not putting into place accessibility. I put together risks. I am putting together return on investment. This is hard.
EV: We did an impact analysis for two banks in the Netherlands. What are the products now? What is end product? What is there now? What should be changed? How much does it cost?
JB: We need to say: this isn’t everything there are many other pieces. You may need to draw on implementation plan. You may need to put something together that doesn’t include all of this.
AA: might be formal or informal
AG: What is the value of this section? We are going to add material that we can’t write for every situation.
JB: It would be helpful for people who advocate. This gives them an orientation to what should be included. When people have looked at our suite, they would ask how we would use this.
KB: Could we put in sample cases?
JB: We had this but we took it off deliverables list.
AA: I agree with Alistair. Are we doing business analysis 101?
JB: We may want to remind people that this is basic project management.
CC: How expansive and how detailed should this be? We want to give generic overview.
JB: We can make it as detailed as we want. It is impossible to provide steps. Can provide hints.
AG: Could we put something in the introduction to document? Having at the bottom takes away the value.
HBj: What is difference between the sections of the document?
JB: Should we remove this?
DS: I would like to see it here. It would be typical in a large organization.
JB: Even in a business environment, would still want to know how to put it together.
DS: I might have insights; but this is useful.
JB: About third of people here have a business background. How many people who are Web accessibility proponents have a business background.
SH: We should avoid giving people a short course in writing business case.
JB: With the implementation suite, this is how it intersects with project management.
LN: Alistair said that it changes flow of document. May be speaking down. How to use what we offer. How to use these materials.
JB: Replace the subheading.
AG: Higher up in the document.
LN: I’m not sure where.
JB: We get ourselves in awkward situation of context, e.g., business environments, cultures. Have introduction, how to use, different environments.
NL: Have some questions e.g., what is audience, policies in my country, type of environment.
EV: We use the documents all the time.
JB: We should wrap up this section.
LC: If we have used format before, this could be useful.
JB: Policy factors. This is the least developed section. Let’s move to economic factors.
Is economic the right word? Look at the auxiliary benefits section.
HBj: Should we keep table?
JB: It would be a shame to loose all this detail.
NL: Can put a link there?
JB: May need to be reorganized because themes have changed.
AA: Seems to be agreement that we need to expand.
LC: Employee benefits and expansion of talent.
JB: Should we write a nested outline?
LC: Retention is more than a social benefit.
AG: User experience is a benefit. Made site more usable. Enhanced user experience.
CL: Was team trying to reduce cross fertilization between groups. Are we making a shorter document? Some of the repetition may have been removed.
JB: We tried not to talk about things at length in different places. But we can link.
There is a difference between short little links and stuff has gone missing.
JB: On changelog, we need to check to see if stuff isn’t missing. Agree add user experience.
CC: How does this relate to economics?
AG: People will stay on site and gain users.
JB: Should we expand to different audiences with nesting?
Group: Yes
JB: Semantic Web
MK: This is a benefit. What kind of metadata?
JB: We are not rewriting guidelines. Semantic Web integration may be going too far.
MK: We already do that.
NL: Semantic Web is confusing.
JB: How about: Help set the foundation for Semantic Web. Change “Semantic Web Integration” to help set the “Foundation for Semantic Web Integration.”
CC: This could be an economic benefit. Don’t have to redo work in multiple ways.
JB: Clarify the economic benefit of Semantic Web.
LN: Put interoperability as an economic benefit. One way is through the semantic Web.
DS: That is a frequently made argument in business settings.
AG: Benefits and costs. Most people might think that this is cost/benefit analysis. If so, it doesn’t go far enough. Maybe title of sections should be changed. Document focuses on technical benefits. Might be too technical in UK.
MK: Multiple channel publishing.
JB: Multipurposing of content.
CC: costs/benefits go across many organizations
JB: considerations
AG: Want to say how much money comes from a market. There’s trillions of pounds (dollars) available.
SH: In the U.S., it’s very small. Marketing people in the States won’t do it. The number isn’t large.
AG: We sell it that there area xxx people disabled and they have lots of money.
SH: This is different in different areas.
AG: Depends on how define people with disabilities.
EV: We are trying to redefine and make it broader. Elderly.
JB: Can we agree on principle for this document? We need multiple arguments for making the case for Web accessibility.
EV: Make a list of arguments.
DS: We need sources for statistics.
AG: We’ve got it for the UK.
JB: Some of this is controversial. The disabled community is very impoverished. No consistency from one country to the next.
AA: We are missing the breakdown of audiences e.g., elderly.
MK: Benefits don’t always happen for all. Are these benefits? Do you get all?
AA: Factors that may apply. No one gets all benefits.
HBj: Haven’t we got some of these in auxiliary benefits?
draft: http://www.w3.org/WAI/EO/Drafts/bcase/econ.html
AA: Seach engine effectiveness? We had based it on metadata.
AC: You can buy placement on alta vista or google; will not be one that sells.
SLH: Yes, alt-text is used.
JB: Should we footnote some of the techniques for achieving.
DS: Important info may be footnoted.
SLH: Ask and answer questions, in footnotes without cluttering the main read. Keep the main document concise. Can either use footnotes or link to other places.
CL: Statements unelaborated may be available.
AA: We already have some in the auxiliary benefits doc.
JB: We have a fair amount of content, and several editors working to include this.
SLH: Keep the main document concise, keep supporting information separate, ok at the end of a page.
AA: Website initial investment, and impact on website development process
SLH: Not all the issues apply; long list of possible costs, concerned as intimidating.
BM: Glad to have the list; issues for consideration.
AA: These are Potential Cost Considerations pick and choose – argue
for just cost.
SLH: People read outline, will miss lead-in qualifying.
DB: investment considerations.
AG: Marketing is a concern.
JB: We’re analyzing this in technical way, worrying the public relations issues. Need to start with the right information; let a marketer polish it.
CC: By previously listing the benefits, we’ve already addressed this.
JB: Need more finished, tied up in bows, concern for how people are reading it.
NL: Need QA as ongoing cost.
JB: Trained corp of QA
HB: Developer time is ongoing, some on retrofitting.
NL: Contingencies, may remove – ideas can be redistributed.
AA: Training costs into initial investment.
HB: Also ongoing cost.
JB: Suggest Investments and Return on Investments. Better to lead with return on investment before identifying those costs.
NL: Costs – initial, and ongoing.
JB: Task for NL: Write a sample.
JB: Investment considerations, not absolute, also applies to return on investments.
JB: Proposing overlap of investment and return thereon; so need a strong introduction.
SLH: Intro with bulleted list on return on investment.
JB: Rename order: investment and return on investment.
BM: Economic Benefits
AG: Lead with Benefits, not costs.
CC: Communication theory: To get effect, lead with benefits.
JB: Investment and Return on Investment – overly business-world.
JB: Brand enhancement, and image enhancement for business.
CC: Brand important for education too.
SLH: Lead with economic benefits, then potential investments and costs.
CC: In education, investment is time, grad students, etc, not budget.
EV: Do hear investment in government.
draft: http://www.w3.org/WAI/EO/Drafts/bcase/soc.html
JB: Need to include guidelines other than AT.
CC: ?legacy technology? Whatever’s laying around.
CL: Older technology. ?like older people?
CC: Link to WCAG – are we trying to convince people to use accessible approaches, or just WCAG;
CL: Link to “how people with disabilities use the web.”
JB: Are other guidelines relevant?
JB: Try generalizing section; to include UA and AT.
AA: Thrust is Access to the web for persons with disabilities.
AG: As a social benefit, people are demanding that we make web accessible. Technology allows much more inclusive use, engendered by web content being accessible. That is the social underpinning.
AA: In economic benefits.
JB: Once prior to windows, there were more people finding content accessible.
DS: Once the large mainframe programming staff. Only one person was able to transition. Command line system is more accessible.
JB: IBM Screenreader II fifteen years ago.
HBj: Access to internet more common to all; people with disabilities using it much more. E-inclusion, e-government, etc. necessary to permit participation in society. Web access is a requirement.
JB: Concern about brevity of Access for People with Disabilities.
CL: Genesis for this was Auxiliary Benefits.
JB: Now breaking it out, when put out as a stand-alone.
JB: Demographics page originally intended to be significant. We tried and gave up on it.
JB: Add in the social importance of web access.
LC: Include how wide-spread it is.
Access for Employees with Disabilities
LC: Fix first sentence – low literacy.
LC: Facilities for recruiting and retaining.
HBj: Why refer here to XML accessibility guidelines, but not more generally.
AA: Member of public unaware of XML, never see it.
SLH: Is it more general; accessibility of whatever markup. Too “guideline-centric”
LC: One bullet, talk about guidelines, another about affect on people.
SLH: Could bold the people-centric issues.
AG: Some legal requirements to make workplace accessible—add to policy page.
AA: Some employees won’t adopt technology.
JB: Some disabilities need qualification about applicability of WCAG.
HBj: Public concern – public need issue for internal consumption.
CC: Public material is just as important as what is internal-only. Can access the private through the public route.
LC: Asistive technology needs to be coupled to its accessible content.
MRK: Few Finnish companies generate internal-only information.
EV: Now can upload word or HTML pages and augment them.
CL: Inconsistent section, as state solution first; possibly problem,
benefit, and then solution.
JB: Changes, avoid deterioration.
CC: “most recent group of adopters” make “latest”
SLH: Sentence isn’t needed; omit.
CC: There is an increase in the number of older people who use the web.
DS: “Increasingly older.”
JB: Cognitive or neurological – see how persons with disabilities use the web.
HBj: Don’t categorize as disabilities.
JB: Changes in
HB: In most countries people are living longer, so are more susceptible to
deterioration of senses.
AG: headings, substitute “by” in place of “for”.
CC: First two issues: clear navigation and content, aren’t so restrictive.
CL: This section has different style, rather than referring to guidelines. Likes this style, though other approach is OK too. This section has explicit suggestions.
SLH: Basic info at start of section, then details to follow, linked to
it.
JB: Same points are made.
AG: Title “of” should be “with” as it implies non-native language
CL: Government of Canada has inline markup of English and French.
SLH: Check with I18N for wording.
LN: This content in its native language, how express in other language?
JB: OK, refer to connection rate.
draft: http://www.w3.org/WAI/EO/Drafts/bcase/tech.html
JB: Intro, highlights authoring tools
Reduces Site Maintenance
AG: Combined many bullets into paragraphs.
JB: Some detail is repeated, could be made footnote.
AG: Would need to write new paragraph, point to common.
BM: Could bold the paragraph headings,
MRK: Some semantic web as a technical benefit and future-proofing.
BC: No device-independence mention.
JB: Make content work for more devices, rather than repurposing of content.
NL: Access for PDAs is good objective to be supported.
JB: Navigation there is important.
AG: There is more assistive technology available now, so design with accessibility in mind, so it can be exploited.
JB: So why do those businesses care? Interoperability is subset of WCAG, XMLAG, and UAAG.
HBj: PDA access may get different delivered data, with content separated from presentation.
AA: WCAG add symantics to structure to simplify delivery to PDA.
SLH: Three years ago, following WCAG site design, today works with PDAs.
AA: Stylesheets used badly can make content less accessible.
DS: What is the cost of that extra work?
draft: http://www.w3.org/WAI/EO/Drafts/bcase/pol.html
JB: Some introduction, make distinction: law and policy.
AA: Concern for name “corporation” “business” “private sector” – use business.
AA: Associations differ from businesses/educational institutions. Usually not-for-profit.
JB: “Peak Body”
BM: “Trade/professional associations”
CL: Just “associations”
SLH: Only reason we need to separate is if some differences exist, or so people can identify with class. Non-governmental associations.
JB: associations by itself is too broad.
NL: association does not include standards.
SLH: Short term “associations” then first sentence expands meaning.
JB: Reorder: move business after intro.
LC: Non-governmental – charity – association of persons with disabilities
JB: In US, non-profit, NGO is a more general term, though US probably got it from UK.
HBj: NGOs having own meetings.
AC: NGOs are appropriate.
BM: NGO is an unfamiliar term.
SLH: Explain in first sentence how inclusive NGO is.
LN: Include NGO with business.
JB: Only two countries require accessibility beyond government/education: AU and US. For purposes of the policy document we could collapse. For business organization, different from NGO.
AA: Profit motive may change from NGO.
AG: Legally different setup business and NGO.
JB: Covered by same laws – GBA applies to businesses.
SLH: Propose after rework, review. We may need to break it out in a different way.
HBj: Had “Considerations for different environments page” had governmental, educational, non-governmental, and web design.
JB: Guess this will take another three months.
LC: Work on education section.
JB: Questions – to the list.
AA: Revising technical, economic, and social pages.
JB: To do overview and policy page.
JB: Address one page per phone meeting.
JB: WCAG1.0 updates – sometime WCAG2.0 jeopardy for 2003.
JB: Hard to get all comments incorporated into EO documents. SH will
be working to move these along.
Implementation Planning Suite has work needed by JB.
HB: Quick Tips will need update Now in some 30 languages. Will need retranslating.
JB: Any chance that WCAG WG could do that?
CL: Curriculum: some claim that WCAG2.0 will not need any. May need alternative way to deliver information, rather than slides.
JB: Selecting and Using Authoring Tools for Web Accessibility
MM: ATWG, ATAG2.0 doesn’t want to be tied to success of WCAG 2.0,
so references are self-contained for compliance; decoupled from the WCAG, so
WCAG1.0 as policy would be still OK. Future-proofing with WCAG2.0
– once available.
There may be authoring tools compliant with WCAG 2.0. If there isn’t
any compliant with WCAG2.0, than cannot get through CR.
Not setting any requirement for complete implementation. Subsets for partial
conformance can be identified.[There is currently no authoring tool that
conforms to WCAG 1.0.]
JB: We need feedback.
JB: Re: Assessing websites for conformance change criteria from WCAG 1.0 to WCAG 2.0.
JB: Re: Review Teams -- minor changes
JB: Re: Evaluation Tools; Whole thing would need frequent evaluation, quarterly, as tools catch up.
JB: How People with Disabilities Use the Web - Makes general references to guidelines.
HBj: Old specs become “deprecated”.
MRK: User needs old link. With software referencing prior version, (BOBBY, etc.) link to a correspondence table.
AA: People using old guidelines and policies will not automatically upgrade to new versions.
JB: Could there be separate reference sections with multiple specs.
JB: Analogous to references from guidelines to corresponding techniques. – many links
BC: List already is explicit to versions. Needn’t replace refs to WCAG1.0; but just add new references to WCAG 2.0.
JB: A major effort to do this well.
BC: WCAG2.0 has a continually updated mapping from WCAG1.0, maintained as an appendix to their working draft.
JB: Gallery revisiting. Will need a section for 1.0 and can start to reevaluate for 2.0.
MRK: Wonder how much change, if have 1.0 AA approval, no assurance that it
will have appropriate corresponding
Accessibility.
MM: Machine testing conformance – testable. Nothing substantial that could break.
HB: Do not expect all to be working at date of Recommendation.
MM: List of what needs to be fixed.
JB: Will need some coordination with QA;
JB: Expect complete conformance by entire sites – to some level of conformance – before moving WCAG 2.0 to Recommendation, so there would be some conforming site(s) that could go into the gallery.
MM: UAAG, so few in the pool of implementations. In contrast WCAG 2.0 should have working implementations existing. Everyone is an implementor!
JB: Working drafts, last call WD, Candidate Recommendation, Proposed Recommendation (W3C organizations review), Recommendation.
NL: Once a recommendation is out, site could move into gallery.
JB: Can’t get out of CR unless there are sites that conform.
JB: during CR, may want to test sites to both WCAG 1.0 and WCAG
2.0.
Dom's presentation
DOM:Group doing development of QA guidelines.
DOM: Have developed seven documents: introduction, operational guidelines,
specification guidelines, test guidelines,
.(3 more.)
DOM: Working on all WAI activities developing recommendations. See:http://www.w3.org/QA/TheMatrix -
wherein the spec, its status, validator availability, and test suites are
identified, and links to related information and a conformance section. Does
include WAI WG. UAAG is one to which it applied. It has no validator, but has
test suite. AT has neither. WCAG 1.0 has validator, no test suite.
W3C Internationalization Activity
RI: Richard Ishida, chair of the Guidelines, Education, and Outreach (GEO) task force.
RI: Also have task forces for web services, and core task forces. (and
four other members of that group)
Interest is what has worked for WAI/EO. Their page is:
http://www.w3.org/international/geo/plan/geo-scoping.html
JB: showed the WAI document page, and quickly navigated through the resource page: http://www.w3.org/WAI/Resources/
HB: you can feel free to adopt our outline!
JB: FAQ have been useful.
JB: A common group problem has been scope expansion. We have trouble finishing documents.
JB: Training curriculum is one important one.
CL: How people with disabilities use the web: Address why to do web accessibility.
MRK: The examples are memorable.
JB: Business case for translations should be important.
JB: EO attracts more participants than the other WAI groups. Recommend a dedicated
HB: Concern for translations. Martin Durst coordinates that.
RI: Doing first techniques. Building a repository of techniques, analogous to WCAG 1.0 techniques.
RI: Have some standard topics that can be linked, [HB: as if entity references.]
Are including browser-support for features. May have tables of topics/conformances.]
SLH: How handle speakers in other languages.
RI: How work together with WAI/EO. Would like to have some unified guidelines.
JB: Have been encouraging this. A year ago they weren’t ready. Now they are. Within W3C a horizontal coordination across many activities: inclouding I18N, WAI, etc. Could use I18N materials as part of WAI presentations.
HB: As review WAI materials, note where I18N would be appropriately injected.