> EOWG Home Page > Building the Case

Change Log: Developing a Web Accessibility Business Case for Your Organization

NOTE: The most recent changelog for this documents is at www.w3.org/WAI/EO/changelogs/cl-bcase-update

This page records old change requests and changes made to the draft WAI resource suite Presenting the Case for Web Accessibility. Please send additions or corrections to wai-eo-editors@w3.org.

Last updated on $Date: 2010/09/23 16:50:22 $ by $Author: shawn $

NOTE: Change log for "Implementation Plan for Web Accessibility" has moved to http://www.w3.org/WAI/EO/Drafts/impl/changelog and changes to "Evaluating Web Sites for Accessibility" are also now in that log. The most recent changelog for this documents is at www.w3.org/WAI/EO/changelogs/cl-bcase-update

on this page: about "business case" resource suite | Review Notes | changes by date | wishlist

Changelog

Changes from Version 1.0 to Version 1.1, January 2008

• Added paragraph at the end:
  Web Content Accessibility and Mobile Web: Making a Web Site Accessible Both for People with Disabilities and for Mobile Devices introduces how Web sites can more efficiently be designed to be accessible from a mobile device and also accessible for people with disabilities when developers understand the significant overlap between the two design goals and guidelines.

About "business case" resource suite

Audience

• Primary audience for this document is people who are trying to "sell" accessibility to their organization, or get "buy-in" from an organization to start a Web accessibility initiative, adopt a Web accessibility policy, etc.
• Secondary audiences include reporters, trainers, ...
• All types of organizations, including commercial/industry, government, education, non-profit, etc.
• Direct audience for this document could be varied, such as technical Web developer, business analyst, outside accessibility advocate, etc.
• The indirect audience is the people reading the organization's customized "business case" which is often managers and others who are responsible for allocating time and money resources to Web projects.

Approach

Since each organization has different motivations, we cannot write one master business case that will apply to everyone. Instead, this resource suite is like a cafeteria where people can take what best applies to them and create their own customized business case. As such, the content will include:

• Direction on what might be relevant to a particular reader's organization (e.g., if your organization XYZ, then ABC).
• Text that readers can cut and paste to use directly or with some customization for their own "business case".

We will avoid overlap in information between this resource suite and other WAI resources as well as between pages of this resource suite. This is a bit tricky because several aspects of Web accessibility have benefits in more than one area. For those cases, we will cover it in one page and link to that page from the others, rather than repeating the information.

Review Notes as of 9 August 2005

Overview, Social Factors, Legal and Policy Factors, Financial Factors, Technical Factors

status:

• all comments incorporated
• submitted for final EOWG review

[DONE] 20 August 2005

• all pages: minor copyedits recorded at @@[judy's at eo-editors@@

[DONE] 15 August 2005

• all pages: in nav, changed "Business Case" to "Business Case: Overview" (per Call for Review comments)
• Social Factors: fixed typo ("The United Nations "Human Functioning and Disability" page includes links to data for different contrives." to ... countries)
• Overview page: fixed spelling typo Enviroments > Environments

[DONE] 12 August 2005

• Overview & Social Factors: added aging as described in e-mail to EOWG list
• Overview & Social Factors: changed title "...Speakers of Other Languages" to "People Not Fluent in the Language" (in the text it is written out: "people who are not fluent in the language of the Web site")

[DONE] 11 August 2005

• all pages: typo corrections and minor copyedits, from thread starting at http://lists.w3.org/Archives/Public/w3c-wai-eo/2005JulSep/0072.html
• Technical Factors page, Be Prepared for Advanced Web Technologies, first bullet: to "Allow content re-use by using metadata and representing it using resource description framework (RDF)." added ", such as is described in &quot;<a href="/RDF/FAQ.html#What">What is RDF?</a>&quot;" so it now reads:
  "Allow content re-use by using metadata and representing it using resource description framework (RDF), such as is described in "What is RDF?". "

[DONE] 8-9 August 2005

• all pages: put in new design format, minor edits.
• Social Factors page: content edits to "Web Accessibility is a Social Issue" section
• Technical Factors page: deleted the following:
  Location: Section "Reduce Site Development and Maintenance Time", 5th/last bullet.
  Previous wording: "Reduce time and money spent in employee recruiting, training, and development by using technologies that many developers already know. (WCAG 1.0 Checkpoint 11.1, 3.2)"
  FYI: 3.2 is "Create documents that validate to published formal grammars." and 11.1 is "Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported."
  Rational: Web site developers don't necessarily knew W3C technologies more than many of the proprietary alternatives. For instance, it's more likely that they've been trained in Flash than in SVG. While it might be true, for example, to say that more Web site developers know HTML than Flash - this point is not strong/important enough to leave in.
• sub-pages changed titles to:
  "Technical Factors in Developing a Web Accessibility Business Case for Your Organization"
  (from: "Developing a Web Accessibility Business Case for Your Organization: Technical Factors")

[DONE] Additional changes made 12 April - 12 May 2004

• [DONE] Identifying [xyz] Factors for a Specific Organization in EACH page: streamline so mostly just includes the explanation of question, to provide conceptual support, but not get bogged down. as appropriate change order to de-emphasize links to lower sections. - consise & simple! OR the sentence itself is self contained (but then not need explanation) - but icky uaag & atag faq
  • Legal and Policy: significant re-org & tweaking. moved stuff from under questions to new sections: "Determining Applicable Policies" & "Understanding Risks for Non-Compliance" & "Considerations for the Future" & "Considerations Beyond Requirements"
  • Financial: added section, "Decreasing costs" - from sentences previously under "Cost Considerations"
  • Technical: added section, "Have High Quality Web Sites"
  • Social: added subheading. "Barriers to Web Use" and added examples in first paragraph under "Barriers to Web Use"
• [DONE] added acknowledgements
• [DONE] integrated reviwers' comments, recorded in http://lists.w3.org/Archives/Public/wai-eo-editors/2004Apr/
• [DONE] Tech: changed "by defining presentation through a style sheet and using proper HTML markup for structure" to " by defining presentation through a style sheet and using proper markup for structure" since it can be HTML or XHTML or XML
• [DONE] Overview, Introduction: edited first sentence and last paragraph
• [DONE] change "Legal & Policy " to "Legal and Policy"
• [DONE, added short concluding paragraph to each] 3. Social/Technical/Financial/Legal -- with the exception of the Legal page, I find the sudden end of each document after its last bullet to be very abrupt and - from a narrative standpoint - unsatisfying. Does anyone else think that a short paragraph of summation, or a sentence conveying "Well... now you have the w-factor building blocks for your business case. If you haven't already done so, visit our x-factor, y-factor and z-factor pages for more great stuff." would be of use? [from chuck]
• [DONE, changed it all to Web sites since that is the focus of this document. added sentence to wishlist: "Accessible Web authoring tools, browers, and other Web tools also have a role in Web accessibility." to link to components when it is done]
  term "Web product" [from Doyle]
  On the Social Factors page in the paragraph titled; 'Role of Organizations' Web Sites', I saw the use of the word, 'product', four times. I believe that the word Assets better suits the usage to which Products in the first two instances appears. In the third instance of the word Products I found the word, Resources, appropriate. And I would leave the fourth product alone.
  That paragraph would then read: "When an organization's Web ASSETS (Web site, authoring tool, etc.) are not accessible, they further exclude people with disabilities from society. When an organization's Web ASSETS are accessible, they empower people with disabilities to participate in society. Providing accessible Web RESOURCES can directly increase Web product usage,.."
• [DONE, removed "production and distribution" left "translating" since have "-ing" in others] financial:
  current: "Decreases cost of alternative format materials production and distribution" & "Decreases cost of translating"
  what about: "Decreases Costs of Translations" [from libby] "Decreases costs for producing and distributing alternative format materials"
• [DONE] Technical: added the following explanations:
  • Reduce site-wide presentation change time and effort by defining presentation through a style sheet and using proper markup (HTML, XHTML, etc.) for structure. (WCAG 1.0 Checkpoint 3.1, 3.3, 3.5, 3.6, 3.7, 5.4)
    Presentation includes design and style such as font size, font face, and background color. If the presentation is defined in an external style sheet, it can be changed throughout the site by making the change to that one style sheet. However, if the presentation was improperly defined throughout the HTML, the presentation markup would have to be changed in every instance on every Web page.
  • Reduce redesign and translation time and skills needed by using standard markup language and style sheets to style and format text, instead of using bitmap images of text or math. (WCAG 1.0 Checkpoint 3.1)
    Site designers often use bitmap images for stylized text. In such cases, to change or translate text content or style, each image has to be manipulated. If instead the text was not in an image and the style was provided in a style sheet, then the text can be changed or translated without touching the image, and likewise the style can be changed in the style sheet.
• [DONE] Technical: cleaned up the @@s
• [DONE] Financial: cleaned up the @@s
• [DONE, added reference at end] referencing WCAG Checkpoints (and w3c technologies in technical). - link all (too distracting), link just the number (not sufficinet?), reference at end...
• [DONE] added a subheading "Overlap with Digital Divide Issues" and a paragraph at the endof that section to tie it in

[DONE] Changes from 2 April 2004

• [DONE] remove references page
• [DONE] change title to Developing a Web Accessibility Business Case for Your Organization: ...

[DONE] Overview

• [DONE] Developing a customized Business Case
  • [DONE] fix awkward wording ... quality phrase awkward ... perhaps conformance to technical standards...
  • [DONE] Consider Sailesh's comment about "interest" and "emphasis " "Some organizations might be more interested in the economic factors, others in the legal factors, and others the social impact of Web accessibility"
• [DONE] Example Emphasis for Different Environments
  • [DONE] Web development: clarify first point: "skill necessary to understand & implement accessible Web sites" competive advantage
• [DONE] move table of contents to separate page

[DONE] Additional changes made 1 April 2004

• [DONE] Overview: major revision to the entire page. revised version: http://www.w3.org/WAI/EO/Drafts/bcase/Overview.html, previous version: http://www.w3.org/WAI/EO/Drafts/bcase/Overview-old.html
• [DONE] throughout: removed the "references" link that I put in a few weeks ago

Changes requested 26 January 2004

• [DONE] Identifying [xyz] Factors for a Specific Organization in EACH page: streamline so mostly just includes the explanation of question, to provide conceptual support, but not get bogged down. as appropriate change order to de-emphasize links to lower sections.
• [DONE, send msg to Eo-Editors] add Stds Harm discussion to "developing a policy" suit
• [DONE] editors discretion to examine discussion of CSR in Social so more on action, not on appearance - and also not financial factors
• [DONE] slh to redraft "addressing multiple Stds" in legal to remove 'opinions' - use jb's notes
• [DONE] ideas for heading change: identifying, question to ask...
• [DONE] remove "related resources" section - see how it looks
• [DONE] edits from Judy listed at http://lists.w3.org/Archives/Public/wai-eo-editors/2004Mar/0029.html

[DONE] Review Notes from 15 March

[DONE] Social Factors

1. [DONE] General question on Checkpoint listings: Are the ones that are listed good ones to list? Should others be listed? For example, in "Access for People with Low Bandwidth Connections to the Internet and Older Technologies" section should there be any for image maps?
2. [DONE] Not list all screen reader related checkpoints: In the "Web Accessibility Benefits People with and without Disabilities" section we list the relevant WCAG 1.0 checkpoints. The last paragraph under, "Access for People with Low Literacy and Speakers of Other Languages" says something like, "In addition, accessible sites can be read and navigated by screen readers (for people who are blind) and people who cannot read can benefit from listening to sites." [might have been edited since] Because the list of relevant WCAG checkpoints is so very long (WCAG 1.0 Checkpoint 1.1, 1.2, 1.3, 1.4, 1.5, 2.1, 3.1, 3.5, 3.6, 3.7, 4.1, 4.2, 4.3, 5.1, 5.2, 5.3, 5.4, 5.5, 5.6, 6.1, ... and several more), editor suggests not listing them here. Thoughts?
3. [DONE] Not list checkpoints that have "until user agents" clause that many in WCAG WG consider deprecated: In the "Access for People with Low Bandwidth Connections to the Internet and Older Technologies" section, only list those checkpoints which are still valid with modern browsers as well, not the checkpoints that have "until user agent" clause and are considered deprecated by many. Thoughts?

[DONE] Legal and Policy Factors

1. [DONE] Repetition between main sections:
   The "Considerations for Different Types of Organizations" section seems too repetitive with the questions in the first section.
   1. Should the information be separated differently between the sections? Should more or less be repeated in both sections?
   2. Should the first question "Is Web accessibility required for this type of organization?" include all the information from the bottom section ("Considerations for Different Types of Organizations") (and the question "Are there other Web accessibility policies the organization should comply with?" -- note that the total would be much shorter becase there is a lot of repetition between the first question and the bottom section, as well as within the subsections at the bottom.
   3. Or is it OK as is?
2. [DONE] Do any government policies require non-government sites be accessible?
   Is this statement true: "Some government policies require industry and non-governmental organization (NGO) Web sites to be accessible. "
3. [DONE] Please review carefully the new section:
   Addressing Multiple Standards or Guidelines

[DONE] Additional changes made 13-24 March 2004

• [DONE] copyedits & WCAG 1.0 Checkpoint references from Andrew & Henk and others, sent to wai-eo-editors and archived at http://lists.w3.org/Archives/Public/wai-eo-editors/

[DONE] Changes requested 1 March 2004

[DONE] All pages

• [DONE] consistent page format of intro; customizing for a specific organization; sample text; additional resources

[DONE] Overview

• [DONE] add "abstract" before intro & fill w/ last two paragraphs of intro text
• [DONE] SLH: add an overall, detailed contents list
• [DONE, did not integrate full list because to be inclusive would be too long, did add a few examples] consider integrating overall WHY:
  • its best practices --- [technical]
  • because its international [technical]
  • because we don't want to be behind our competitors [financial including corporation]
  • because of the broad international involvement & consensus building
  • reference the standards harmonization document [Legal and Policy ]

[DONE] Social page

• [DONE] try adding these questions:
  • Is this organization interested in enhancing its image with regard to social responsibility?
  • Does the organization already have a corporate social responsibility statement or program?
  • Which avenues of maximizing the benefits of Web accessibility as CSR are most relevant to the organization?
  • Is your organization obligated by some CSR policy?
• [deferred to "myths"] have a section that lists the common challenging questions, e.g.:
  • Why address Web accessibility if it only affects a small number of people?
  • But our audience doesn't include people with disabilities. (Handicapped people don't come here anyway!)

[DONE] Financial page

• [DONE] try adding these questions
  • How much will it cost to make my Web site accessible?
  • What is the return on investment if we make it accessible?
  • What are the advantages of up-front accessible design vs retrofitting?
  • What would be the costs if you get sued for non-compliance?
  • How can I minimize the cost of making my site accessible?

[DONE] Technical page

• [DONE] see if want to add something about quality
• try adding these questions:
  • would your management like to improve its...?
  • would these issues resonate with your management...? [improving quality]
  • are you interested in future-compatibility of your technology?
  • see where to add consistency, corporate image, quality, etc.

[DONE] Legal and Policy page

• [DONE] try adding these questions:
  • are there any possibilities under development?
  • are you looking at other markets where this might be an issue?
  • are there professional, trade association, or standards organizations standards

Changes requested 6 February 2004

• [done] judy: For general discussion of demographics in "Presenting the Case...", explain difficulty of obtaining consistent disability demographics internationally across different regions, then provide links to examples of specific kinds of regional research, including Microsoft's Forrester report (check intended persistence of this link)

[done slh] Changes requested 30 January 2004

Social Factors page: http://www.w3.org/WAI/EO/Drafts/bcase/soc.html

• [DONE] try to smooth out this sentence "Many people with disabilities are impacted by several aspects of the digital divide related to Web use."
• [DONE] if leave the sentence in, change it to: In addition, since the benefits of accessible design also extend to other groups affected by these and other limiting situations, Web accessibility also supports improved access and social inclusion for many other groups, including:
• [DONE] consider changing: "While the main focus of Web accessibility is people with disabilities, accessibility also benefits people without disabilities, including those in groups disadvantaged by the digital divide." with to "While the main focus of Web accessibility is people with disabilities, accessibility also benefits people without disabilities whether or not they are affected ?? impacted ?? by the digital divide." make sure here or elsewhere covers situational limitations
• [DONE] continue to look carefully at how we are using the term digital divide. also, read the link harvey sent. (note: jon, helle, natasha (last week) said that 'digital divide' works very well in their countries and those they know of)
• [DONE] judy: take a stab at integrating some ideas from sailesh's 22 Jan email, subject: "Social Factors page", archived at: http://lists.w3.org/Archives/Public/w3c-wai-eo/2004JanMar/0033.html
• [DONE] incorporate ideas from sailesh's 23 Jan email, subject: "Re: bcase-social factors for 23 January 2004 teleconference", archived at: http://lists.w3.org/Archives/Public/w3c-wai-eo/2004JanMar/0040.html, ...
• [DONE] look at how financial factors refers to CSR and social factors
• [DONE] incorporate new category: # New users / Casual users (don't understand things like new/multiple windows and non-underlined [unclear] links). add temporary disabilities, probably with PWDs, but maybe a separate category. (charmane draftedl)
• [DONE] charmane's edits archived at http://lists.w3.org/Archives/Public/w3c-wai-eo/2004JanMar/0056.html

[DONE] Changes requested 9 January 2004

Social Factors page: http://www.w3.org/WAI/EO/Drafts/bcase/soc.html

• [DONE] Change "Web Accessibility is a Requirement for Equal Opportunity" to "Web Accessibility is Essential for Equal Opportunity"
• [DONE] Under "Barriers to Web Use" trim down or maybe totally out P1 & P2 (except maybe leave link to How PWD Use Web) - make sure adequately covered on overview page. [decided not appropriate for overview page] possibly tweak P3 & P4 down a bit [deleted" While international guidelines define Web accessibility for Web content (that is, what is on a Web page), Web "user agents" (including Web browsers, multimedia players, and software that people with disabilities use to access the Web), and authoring tools (software used to develop Web pages) [x - links to guidelines info], the guidelines are not well implemented. " & "How People with Disability Use the Web illustrates some of the requirements of people with disabilities when using Web sites and Web-based applications, and includes scenarios of people with disabilities using accessibility features of Web sites and Web-based applications with some types of assistive technologies and adaptive strategies used by some people with disabilities when accessing the Web."]
• [DONE] Look at whether to leave link to How PWD Use Web here or on intro
• [DONE] CSR more directly addresses audience, do same thing in previous section, e.g., does your country do digital divide? Think about if there are any questions about the organization type and how that would impact how they incorporate social factors into business case. (but becareful not to overlap too much with introduction) [this is actually integrated into the CSR section, "Does the organization already have a corporate social responsibility statement or program?... If no,...]
• [DONE] For "other groups" section, do something in between March 2003 with detailed examples and the previous version's small bulleted list
• [DONE] Intro, last P: "In presenting a case for Web accessibility for a specific organization, the following social factors can be customized based on how they apply to the organization's situation." social factors can't be customized - maybe the following SF can be applied according to the organization's situation. [changed to: In developing a case for Web accessibility for a specific organization, the following social factors can be presented based on how they apply to the organization's situation.]
• [DONE] Intro: tweak examples, add: 1. org made goal to demonstrate social leadership, then the others...
• [DONE] "The Web is an opportunity for unprecedented access to information for people with disabilities." maybe weave barriers IF can do it briefly - mention functional problem (maybe w/o disability), e.g., lifting journal, hearing... this is a side point to this section which is an initial statement of need... [add, ", including getting to the library, physically getting the resource, and reading the resource" - but don't really like it]
• [DONE] "Additionally, providing Web information that is accessible to people with all different types of disabilities is much easier and less expensive then developing and distributing multiple alternative formats (such as large print, Braille, audio)." maybe don't need here 'cause financial factor -- maybe the point is it's more practical... Therefore, people with disabilities, as well as organizations, can have more effective and efficient communications and interactions through accessible Web sites - in some cases where there was essentially no access before. "digital media is eminently suitable for accessibility".
• [DONE] fix wordo: "it becomes exponentially users for many people"
• [DONE] "Web Accessibility is a Social Issue" is statement of need. maybe third paragraph integrate with first paragraph. maybe emphasis employment/job notion. "People with disabilities can actively participate and provide content for the Web." - maybe add discussion forums & stuff. when move to the top, don't lose it, make sure it still has emphasis
• [DONE] Scope section: maybe move "Millions of people have disabilities that impact their Web use." to the beginning of that section. make the list non-bulletted & move with/after pwd. (be careful to keep the focus on the social factors aspect, and not the additional benefits)
• [DONE] change "myriad" to "many"
• [DONE] Change "media" to "medium"
• [DONE] format: not so long stretches of bolding [removed bolding from "Barriers to Web Use" section. [left bolding of first sentence of paragraphs in "Web Accessibility is Essential for Equal Opportunity" sectoin. OK?]

all pages

• [DONE] look at actively helping people build a business case, e.g., what questions you should ask (and how their answers impact what they do)

[DONE] Changes made 7 January 2004

Social Factors page: http://www.w3.org/WAI/EO/Drafts/bcase/soc.html

• [DONE] significantly rewriting to try to focus on business case aspects of social factors

[DONE] Changes from 7 November 2003 discussion

http://www.w3.org/WAI/EO/Drafts/bcase/econ.html

• [DONE 18 Nov slh] change heading "audience reach" to just "audience"...
• [DONE 18 Nov slh] change "building the case..." to "presenting the case..."
• [DONE 2 Dec slh] in intro section: edit "An organization's efforts to make its Web site accessible can impact profitability and return on investment." - make broader statement of benefit. maybe change "profitability" to "cost efficiencies", & put after "return on investment"
• [DONE 2 Dec slh] in intro section: consider changing different, different, different
• [DONE 2 Dec slh] in intro section: look at munging the redundancy in first two paragraphs
• [DONE 2 Dec slh] in intro section: "for example, costs are often lower when building or redesigning a new site rather than when fixing an existing site" clarify difference between redesigning & fixing. [took out redesigning] also, clarify comparison statement & claim. [don't know what this is :-(]
• [DONE 2 Dec slh] reexamine heading levels, can make flatter? try changing the H4s to paragraphs like below [changed "Increases Audience Reach" & "Increases Effectiveness" into <p> sentences. left "Quantifying Benefits" <h4> since it's a separate thing]
• [DONE 2 Dec slh] "Many of the aspects of Web accessibility discussed in Technical Factors provide direct cost savings" make it clearer that they should go to the Technical Factors page to get supporting info [added "which are": Many of the aspects of Web accessibility which are discussed in Technical Factors... to be more explicit seemed awkward and really interrupted the flow]
• [DONE 2 Dec slh] "Many of the aspects of Web accessibility discussed in Technical Factors provide direct cost savings" add "can" in this sentence and maybe qualify can in list items, too
• [DONE 2 Dec slh] qualifiers - not just 'can' - what about "Decreases human resource costs for maintaining the site by reducing site maintenance in the longer term" [changed to "when accessibility reduces site maintenance long term" (tried "when site maintenance is reduced" but that's passive, like '"when you reduce site maintenance" but don't think we want to use "you"), etc.]
• [DONE 2 Dec slh] try changing "human resources" to "personel"

[DONE] Changes from 24 October 2003 discussion

http://www.w3.org/WAI/EO/Drafts/bcase/econ.html

• [DONE, slh, 5 Nov] incorporate introductory text from Sailesh's draft - make claer this page not all factors, just financial impacts of other factors
• [cancelled, per 5 March meeting] sailesh & natasha: add section on stastics & measurement. see Sailesh's draft. frame for organizations interested in doing statistical measures, here are some things for you to consider
• [DONE, slh, 5 Nov] make easier to scan. perhaps bring bolded text forward as paragraph intros, section headers, DT in Dl list. make text stand-alone, e.g., increase the findability, increase the usability bold.
• [DONE, slh, 5 Nov] take "Presenting the Case for Web Accessibility:" out of links to other pages in the suite.
• [DONE, slh, 5 Nov] Put Increased Site Use before Direct Cost Savings.
• [DONE, slh, 5 Nov] Maybe note that faster loading pages increases usability.
• [DONE, slh, 5 Nov] Try to break " Increased Site Use" into two sections: 1. Increased Audience Reach (& say "market share" in text maybe), 2. Increased Effectiveness or Effective Usage or some such. Examine for redundancy & add more explicit tie-in to usability w/o tying everything to usability.
• [DONE, slh, 5 Nov] Changes based on feedback sent to EOWG list (archived)

[DONE] Changes from 24 September 2003 discussion

http://www.w3.org/WAI/EO/Drafts/bcase/econ.html

• [DONE, slh] Major rewrite of main text & some minor clean up, summarized below
• [DONE, slh] Changed order of items in the navigation section to social, technical, economic, policy
• [DONE, slh] Changed <H1> and <title> to Presenting the Case for Web Accessibility: Financial Factors
• [DONE, slh] Reorganized "Investment Considerations" from main bullets "initial investment, impact on Web site development process, impact on Web site functioning" & rewrote content
• [DONE, slh] Changed "Economic Benefits" to "Financial Benefits" and reorganized & rewrote content underneath new headings "Increased Site Use" and "Direct Cost Savings"
• [DONE, slh] Highlighted in econ-old.html some info not incorporated

[DONE] Changes from 19 September 2003 discussion

http://www.w3.org/WAI/EO/Drafts/bcase/Overview.html

• [DONE, slh, 24-sept] Compile Building Blocks for Business Case section: new first sentence, "Once the interests of the organization have been identfied, this resources can be used to compile a [@@ suitable? appropriate? nothing?] business case..." [editor note: tried to minimize passive voice, and match style of intro sentence in previous section, and meet main point of this edit request, which was to tie in better with previous section. Original sentence: "Compile information from the pages of this resource suite that meets the organization's interests:" First sentence of previous section is imperative voice: "Start by..." So revised this sentence to: "Based on the key interests and motivations of the organization, complie the relevant information from the pages of this resource suite:"]
• [DONE, slh, 24-sept] Fourth group in Sample Outlines of Business Cases for Different Environments section: reformat so there is not 3 levels of bullets
• [DONE, slh, 24-sept] Change "elements" to "buidling blocks" & "oulines" to "sample outlines"
• [DONE, slh, march] Find a better way to represent or lead into the other pages of the suite (here & throughout suite)
• [DONE, slh, 24-sept] Take "business case" out of headings "Compile Building Blocks for Business Case" and "Sample Outlines of Business Cases for Different Environments"
• [DONE, slh, 24-sept] In the bullets under "Sample Outlines of Business Cases for Different Environments" consider changing "business case" - maybe change the intro sentence to "Making a case for:" and then start the bullets with the entity
• [DONE, slh, 24-sept] Clean up related documents resource link titles
• [DONE, slh, 22-sept] Change order of items in the navigation section to social, technical, economic, policy
• [DONE, slh, 22-sept] Change the first line in the suite nav "Presenting the Case: Overview"

Throughout entire suite

• [DONE, slh, 25-sept] Change order of items in the navigation section to social, technical, economic, policy
• [DONE, slh, 22-sept] Change the first line in the suite nav "Presenting the Case: Overview"
• [DONE, slh, 22-sept] Change H1 & title to "Presenting the Case for Web Accessibility: XYZ"
• [DONE, slh, march] Consider options for referencing the other pages in the suite
• [on-going] Use of "business case" - try not in headings, with discretion throughout text

[DONE] Changes made 18 September 2003

http://www.w3.org/WAI/EO/Drafts/bcase/Overview.html

• Reviewed "Overview" and "Entire Suite" change requests dated 3 March 2003
• Reviewed "Overview" and "Entire Suite" change requests dated 28 March 2003
• [DONE] Changed title from "Building the Case for Web Accessibility" to "Presenting the Case for Web Accessibility: Overview"
• [DONE] Removed "the information in this suite may be used... in keeping with..." for now, since it contradicts the status note above.
• [DONE] Shortened and simplified the introduction -- by making more concise, and by breaking out some new section-headers.
• [DONE] Broke up many of the big chunks of text into short lists of examples.
• [DONE] Added a related resources section.
• [DONE] Integrated material from "How to use this resource" into whole page.
• [DONE] Changed note about business case for authoring tool accessibility into resource listing.
• [DONE] Changed "Considerations for Different Environments" to "Sample Outlines for ..."
• [DONE] Broke down sample outlines into sample outlines.
• [DONE] Added in a reference to the implementation plan, for accompanying information.

Changes from 1 August 2003 discussion

http://www.w3.org/WAI/EO/Drafts/bcase/soc.html#intro

• add transition at beginning of paragraph that introduces digital divide. perhaps something that discusses the relationship between social responsibility and digital divide. perhaps idea that social responsibility is more corporate [?] and digital divide is more ICT... &/or that this is a hot topic / developing trend
• move most of it out of "Introduction" and into "Social Responsibility and the Digital Divide" and something like "?Overlapping Impacts...?"
• make one sentence into two sentences: "For instance, in many countries people with disabilities have among the lowest rates of employment of any sector in society. Consequently may have less access to high bandwidth connections, newer technologies, or computer literacy training; or less ability to buy the latest upgrades of assistive technologies that might give them increased ability to use the Web."
• perhaps address the technical barriers and social barriers - perhaps link to How People with Disabilities Use the Web to help combat the social prejudices and stereotypes related to social factors ?
• perhaps re-structure the document around the issues of social factors and access to technology, that organizations might be interested in for their case (not structured around the specific groups)

Changes from 16 July 2003 discussion

On Social Factors page, based on http://www.w3.org/WAI/EO/Drafts/bcase/soc-new.html

section: Introduction (changes made in document at: http://www.w3.org/WAI/EO/Drafts/bcase/soc.html)

• @@ [done?] added in concept of digital divide, tangible, leadership
• [done] paragraph starting with "Many organizations...": fewer words, bullet the items
• [done] two paragraphs start out with "This document..." - munge them
• [removed] change "wish" to "want" (slh suggestion not verbalized in mtg)
• [term clarified initially & then "social factors" generally used] get away from just "social responsibility" (william's & doyle's comments on broader "social factors") - maybe document/page title is social factors and social responsibility is just one point
• [done] add/move umbrella info at/to the beginning. (e.g., "In many countries, use of the Web already pervades many areas of daily life, including access to government information and services, educational opportunity, commerce, and entertainment." which is under PWDs section, applies across all sections and therefore should be up at the top level) 
• [done] perhaps better definition of "social responsibility" (Natasha shared http://www.hp.com/e-inclusion/en/index.html)
• [clarified, and added variants] Pierre on translation: "social responsibility" not translate, perhaps "citizen..." (jb: civic participation)
• link to How People with Disabilites Use the Web
• refilter for read and write ability (PWDs not just receive content, but develop content) - promoting interactivity, not just passive reading
• perhaps add idea of "leadership"
• separate internal from external, public vs. employee. also make sure to cover the idea that many people in your potential audience could have disabilities - public, employees, vendors, collaborating organization...
• perhaps add "digital divide" term
• "make it tangible" (perhaps ask Michael for specifics)
• In umbrella, mention overlap with economic, auxillary benefits is beyond PWDs. 
• Perhaps explain in PWD section why there is not a segment giving specific disabilities and statistics.

section: Access for People with Disabilities

• number of people: need to add temporary disablities, family members, etc....

Other areas

• technical factors - need to look at translatability...

Change requests from 16 May 2003

• overall level: 
  • check H2 capitalization; set a policy
    
• legal and policy factors:
  
  • "Some governments may not have laws specific to Web accessibility. Nevertheless, they may have applicable regulations, directives, or other requirements  based on laws and policies such as anti-discrimination legislation or information technology policy." change to "Some governments have laws specific to Web accessibility. Other governments have applicable regulations, directives, or other requirements based on laws and policies such as anti-discrimination legislation or information technology policy." -- editor should also try to get this into more of an and/or mode.
  • Try a version keeping the bold on the questions, but running the detail into the same bullets as the questions.
  • Add "rather" before "than" in last question.
  • "educational institutions and organizations," "and publishers"
  • fix jigteam link on "technical resources"
  • current --> currently
    
  • change "Resources related to building a case for Web accessibility" to "Other topics within this suite"
• technical factors:
  • [done aa] fix div at top
  • [done aa] align the document title
  • [done aa] status section needs note class
  • [done aa] correct the in-page navigation
  • [done aa} replace the intro w/ a parallel into to legal/policy
  • [done aa] generalize in the subsections within body of document and put the additional detail at the bottom (help to reduce redundancy between subsections)
  • [done aa] [CC, HS] try re-writing "reduce site maintenance" with 1/2 as many words and with more direct statement of technical benefit and less detail on the statement of the checkpoint -- [CLT, CC, HS, AA, BM will debate]
• economic & social:
  • previous change requests as noted
  • also the consistency change requests from the technical factors document
• overall comments:
  • still discuss qu of bottom nav for suite and/or related resources
    

Additional changes 15 May 2003

• [jb] shortened intro to policy question section
• [jb] copy-edited "considerations for different types of organizations" section for conciseness and clarity.
  

Change requests from 2 May 2003

On Legal and Policy page http://www.w3.org/WAI/EO/Drafts/bcase/pol.html

• [done/jb -- incorporated re-edited version of charmane's comments] CHARMANE: in questions section, sentence still need to be crisper
• [done/jb] in questions/Policy section, first sub bullet - clean up "at at" (notes in minutes)
• [done/jb] update the in-page navigation to match the new headings (questions -> policies). consider other options for separating the sections in the in-page nav. remove H3s in in-page nav
• [done/jb] change "Considerations for Specific Envrionments" section heading to "Considerations for Different Types of Organizations"
• [done/jb] EOWG: relook at Additional Resources - maybe change "Additional Resources" heading to "Relate Resources" "Other Resources" "Finding related infomration" "How to find related information" ? perhaps also include search engine tips - in thsi section at the end of the page, or at the end of each organzation section ?

Additional changes 1 May 2003

• [done] incorporate Libby's edits sent to wai-eo-editors list http://lists.w3.org/Archives/Public/wai-eo-editors/2003Apr/0009.html
  • [done] add "and organizations" after "educational institutions" (2 places in document)
  • [done] change "distance learning" to "online learning"
• [done] change "and refers to government requirements" to "and refers to government or other official requirements"
• [done] marked up the page nav bar a bit differently
• [done] added in an experimental "additional resources" link farm at bottom of page
  

Change requests from 25 April 2003

On Legal and Policy page http://www.w3.org/WAI/EO/Drafts/bcase/pol.html

• [done] change title to "building..."
  
• [done] generally, make sentences more concise and crisper - look at William's suggestions attached to http://lists.w3.org/Archives/Public/w3c-wai-eo/2003AprJun/0036.html
• [done] look for ways to reduce the bulletiness of the list (i.e., in reply to Chuck's comment that the sub-bullets break the flow of the main bullets). look at bolding in William's attachment to http://lists.w3.org/Archives/Public/w3c-wai-eo/2003AprJun/0036.html
• [done] remove "[@@ more specifics?]" at end of bottom sections
• [done] Chuck's edits sent to wai-eo-editors list http://lists.w3.org/Archives/Public/wai-eo-editors/2003Apr/0006.html
  • [done] fix typo "the requirement are" -- cannot find; must have overwritten it already
  • [done] fix typo "all sectors or society" -- 
• [done] clarify the title of the question section, should be something more like: are there any policies that apply to your organization

Throughout entire suite

• [DONE, slh] when appropriate, clean up consistency in titles and such, see Sailesh's e-mail at http://lists.w3.org/Archives/Public/w3c-wai-eo/2003AprJun/0029.html
• consider using the intro approach from Legal and Policy page as intro in other pages/sections
• check that msgs sent to EO and EO-Editors lists are addressed

Change requests from 28 March 2003

Throughout entire suite

• [DONE, slh] fix [business] case throughout, including all page headings, suite navigation title, title of pages
• change marketing tone, e.g., take out qualifiers, adverbs

On Overview page http://www.w3.org/WAI/EO/Drafts/bcase/

• change "- assembling a business case" to match the subheading in doc body 
• move "how to use this resourse suite" up to after intro, move some info from intro into that section
• consider limiting the intro to just what this document is

On Benefits page http://www.w3.org/WAI/EO/Drafts/bcase/econ.html#benefits

• [rewritten] look at reorganizaing paragraph starting: "In order to assess audience growth it is imperative to have auditable “current” traffic statistics..." lower
• [rewritten] under "Audience expansion - many aspects of Web accessibility are about increasing the general usability of a Web site such as: " move "Improving the access for all people is likely to have an impact on the way a Web site attracts visitors. " to the first item under bullet
• consider design to add more whitespace (possibly inpage style to add space before &/or after list items)
• [rewritten] [clarification 20030411 -- editor's discretion -- try to keep something on this, but make it less absolute] "Employee retention - accomodating employees with disabilities is cheaper than replacing them - consider " - sometimes not, sometimes, yes
• [rewritten] clean up wording so that it doesn't look like we're going to have examples

Change requests from 3 March 2003

On Overview page http://www.w3.org/WAI/EO/Drafts/bcase/

• In introduction, scope section, clarify that this is about accessibility of Web sites - mention other UAAG, ATAG, "Selecting and Using Authoring Tools for Web Accessibility" and AT Business Case [that Carlos is working on]
  
• Experiment with different ways of including different links to the AT Business Case, perhaps including another section in the overview page
• Look at other AT Business Case to see how it fits in, and they fit together
• [DONE] Change title to "Building the Case for Web Accessibility" and in the overview page make sure to use the term "business case"
• Add all the other terms in meta data keywords: business case, how to sell Web accessibility, convincing, etc....
• [DONE] Change suite navigation from "Business Case Suite" to "Business Case resource suite"

Introduction section

• DONE first paragraph:
  try flipping wording, inverting to lead with the Web being a core technology. jb, "see if can also build in the serving part of the business case there"
• DONE second paragraph:
  remove the "but" and consider changing "clearer" to "clear" and "some" to "many"

Considerations for Different Environments section

• add "would facilitate inclusion of more" idea
• DONE add faculity & staff (in addition to students)

Assembling a Business Case section:

• Change section title to "How to use these materials in a business case" [DONE slh suggests considering "How to use this resource suite"]
• add idea that this could be part of a large doc, or you can use just a small part of it; that it could be formal or informal; that you might want ot gather a team to work on development of a business case
• perhaps add a list of questions to ask
  

In entire suite

• Throughout all pages, look for appropriate places to link to other documents -  UAAG, ATAG, "Selecting and Using Authoring Tools for Web Accessibility" and AT Business Case
• DONE Change from "Policy Factors" to "Legal and Policy Factors" in suite navigation
• Check to see what's missing in the new draft, that is, what info we had before in Aux Benefits that is not in latest draft
• Keep the main page information as concise as feasible, move details that explain separately - start with it at the bottom section of each page (like footnotes), possibly will go on separate page
  

On Policy page http://www.w3.org/WAI/EO/Drafts/bcase/pol.html

• Consider if we need to have all these separate sections... are there different policy considerations?
  

• Change title from "Policy Factors" to "Legal and Policy Factors"
• Add obligations (under the law) to make workplace accessible
• Change "Corporations" to "Businesses"
• Change "industry/ professional associations" to "associations" - include industry, professional, academic, trade, etc. in first sentence text
• Rearrange list, perhaps: government, business, education, ngo, associations [check with jb]
• In first paragraph under NGO, explain that NGO includes not-for-profit and non-profit

  
  

On Economic page http://www.w3.org/WAI/EO/Drafts/bcase/econ.html

• DONE Consider if employee retention for employees with disabilities, especially employee without disability gets temporary or permanent disability
• DONE Change "semantic Web integration" to something like "helps set the foundation for advanced Web development"
• DONE Clarify the economic benefit of "semantic Web integration" - some possible terms: ...interoperability... multipurposing of content...syndication....
• DONE Bold the phrases - e.g., under "initial investment," the phrases at the beginning of the bullets before the dash - to facilitate skimming
• DONE Change from "Costs" to "Potential Investment Considerations"
• DONE Consider marketing perspective - is cost list too overwhelming over benefits list?
• DONE Look at reorganizing - e.g., developer time and a few others should go in other section
• DONE Remove contingency and misc. item - add those considerations elsewhere they belong
  
• DONE Munge Benefits section & ROI section into one, with heading to "Economic Benefits" (and leave it as first section)
• DONE Include "ROI" "return on investment" etc. in intro paragraph text & matadata
• Move train co... [@@ Andrew took written notes, didn't get details in chagne log]

On Social page http://www.w3.org/WAI/EO/Drafts/bcase/soc.html

• DONE In in-page nav:
  To "employees" add "with disabilities"
  To "bandwidth" add "low bandwidth"
  others?
  
• DONE Change "legacy technology" to "older technology"
• DONE Change from being guideline-centeric to more people-centric throughout, e.g., under PWD section, reorder wording and <strong> the phrases about the people - order: problem/need, benefit, then solution is to adopt the guidelines (like in access for Older People)... at Low Literacy section, we go into the specifics of the guidelines... consider more consistent/parrallel structure... consider putting the the basic intro (e.g., the list of the items) at the top, and then put the details at the bottom.... also might be able to eliminate some redudancy
• DONE Consider changing "Access for..." to Access by..."
  

Access for People with Disabilites section

• DONE Try generalizing this section a little more so it's not dependent on WCAG
  
• Consider linking to How PWDs Use the Web
• DONE Consider beefing up Access for People with Disabilities section - about don't exclude 'cause Web is key role in participation in life... and there are also advocates that might pursue... [jb had ideas for this section]

Access for Employee with Disabilites section

• DONE [mentioned in Economic doc instead] Add idea of retaining (limiting attrition) & recruiting employees!
• Consider if we need to mention AT here
  

Access for Older People section

• DONE Think about an intro sentence that is not questionable about if it is true universally - e.g., Increasingly more older people are using the Internet... in some cases, faster growing # of aging
• DONE Think about rewording to not use the term "disability": Sometimes when people are aging... people get changes in XYZ... and that is actually a very important group not to use disability with!
• DONE Delete the word "deterioration"

• Make list inclusive, e.g., add hearing
• Use "cognitive or neurological"
• DONE Delete the first sentence
• DONE Remove "Unfortunately"
• DONE Point to How PWD Use the Web for details

Access for... Language section

• Add primary language markup
• Consider non-native... and alternative to "speakers"
• Action item: check with internationalization gurus on how to word this
  

On Technical page http://www.w3.org/WAI/EO/Drafts/bcase/tech.html

• Generalize in the subsections at the top and put the additional detail at the bottom - help to reduce redundancy between subsections
• DONE Consider if need to break up bullets, separate points into multiple bullets, or separate sub-points with line breaks within a bullet
• DONE Consider adding emphasis with STRONG for key intro phrases throughout
• DONE Change "repurposing of content" to something like "work for different devices" that's more lay-person's terms rather than jargon

Change requests from 1 November 2002

• Comments on http://www.w3.org/WAI/EO/Drafts/bcase/
  • change title to "Customizing a Business Case for Web Accessibility"
  • do four main sub-pages:
  1. policy (Legal and Policy requirements in different settings)
  2. economic (cost factors including expense & revenue, clearly include market share considerations but linked to detail in social factors sections)
  3. social (social factors, including demographics, literacy)
  4. technological (page transmission, device independence)
• save all the content but eliminate redundancies by cross-linking
  
• eventually build a multiple-choice business case template
• people also willing to help: AA, AG, BM, JB
  

Change requests from 9 August 2002

• Comments on July 29, 2002 draft of auxiliary benefits document
  • Change header from "increase market share and audience outreach" to "expand audience" but then include reference to market share in the narrative;
  • Use the term "resource suite" instead of "suite.
  • Change "size and breadth of audience" to "size and diversity of audience."
• Comments on top level of suite
  • Put a definition of business case in top level of suite.
  • Explain what is meant by resource suite up front in the document.
  • Complete the resource suite before checking the document again for translatability.
  • Continue to use business concepts in the document, but explain them as you go.
    

Change requests from 24 March 2002

• Comments on whole suite
  • marketplace: add caution about assumptions checking, and link to caution in scope section in policy document
  • repackage content according to ...? ] four motivators// don't split original document until testing draft re-organization
  • give people hints for different context? or very short business scenarios? use some little scenarios for business cases -- business case examples that highlight the un-obvious//scenarios
  • roll the increase marketshare into demographics
  • roll the legal into policy
  • set up the cost factors so that it more logically links to the organization of the rest of the suite
  • sections:
    1. overview (outline/how to)
    2. marketplace (disab demog & other marketplace)
    3. auxiliary benefits (whatever's left, eg. efficiency)
    4. legal considerations (requirements/liability)
    5. social responsibility (image)
    6. scenarios (short)
    7. cost and value of implementation (how to roll together)
  • scenarios:
    1. university, i18n [bh]
    2. government, transitioning physical access mandate to e-government [mu]
    3. abstract from example from paper [hbj]
    4. tesco example [bh]
    5. online shopping, broader family [lc]
    6. Web design business [jb]
    7. library, ellen? [hb]

Change requests from 1 March, 2002

• Comments on marketplace considerations -- demographics
  • explain where one might find the data? (maybe skip piece on how to find on a country by country, or point to WHO?)
  • explain how might interpret the data? (emphasize the non-reliability of the statistics, but provide links to some reliable statistics)
  • explain that the methodologies may have been inconsistent; provide the information that in some countries you are not allowed to count people according to their disability [e.g. provide some cultural context to explain why surveys produce different results and/or no results]
  • don't go too deeply into the statistics
  • consider getting stats from sweden or some other country where there is precision, iceland
  • look at aggregate references e.g. in eEurope Plan
  • pose questions on surveys
  • considering using WHO averages
  • linking into social /gov't plans for egov access
  • address other relevant market sectors, e.g. illiteracy and etc.

Change requests from 2 November 2001

• Comments on business benefits
  • make sure all points are bullet proof (NL, LC, HB, CL, CV)
  • link to substantiation where possible (LC, AA)
  • note in document that it is not an exhaustive list
  • name, in the introduction, the other resources that will be part of the business case resource suite (AA)
  • get moving on the demographics piece:: JB will start with a fill-in-the-blanks piece; EOWG will help fill in the blanks.
  • do a first pass through the document again before doing any survey (JB follow up again w/ KB)
  • if we do encourage the survey, have it reviewed for methodology (CV, later)
  • once we think that the next draft is ready for feedback, do the survey ourselves
  • try trimming the document -- jb send to gv (AA + JB)
  • try adding an exec summary -- that prioritizes (AA)

Change requests from 12 October 2001

• Comments on latest draft of corporate implementation plan for Web accessibility
  • DONE change "company" references to company/organization
  • DONE move "#8 clarify approach" up to #3 company policy
  • NOT change title to "Web Accessibility: Outline for Implementation Plan"
  • DONE make wording more generic under commitment and sponsorship
  • DONE remove medium & large for commitment
  • NOT special-case the Web design business & sw design business under management commitment
  • DONE extend project manager concept to include more informal "point person" (responsible person)
  • CHANGED note: potentially assign to person responsible for usability
  • DONE on policy section #3, draw from other existing material
  • DONE eval -- point to existing descriptions of prelim eval steps;
  • DONE communication plan -- should mention examples of who communicates what, and that it should be two-way feedback
  • DONE? technical issues -- integrate this with organization policy page but more detail on specific propriety formats
  • integrate all the rest with previous documents, except help desk is new
  • add in more about feedback

Change requests from 5 October 2001

• Comments on supposedly "done" draft of business benefits
  • still some missing titles on checkpoint links in linear version of table (HB & KA will send details)
  • change skip table link to link to lineared version
  • add link to linearized version after benefits matric in TOC
  • check space between links
  • check relative vs absolute size & positioning & add inline comment to explain usage
• Comments on Evaluating Web Sites for Accessibility
  • DONE add "...and changed pages" after ongoing monitoring in conf eval"
  • [UNDONE - unable to clarify] run at least HTML validation service or HTML Tide (clarify coverage of XHTML)
  • DONE add WAI nav bar to upper right of eval page
  • evaluate the page
  • in the review request, mention:
    1. ask people comment on how info is displayed
    2. and on any redundancies at given levels
    3. and invite translations.

Change requests from 5 September 2001

• Comments on new outline for corporate implementation plan <http://lists.w3.org/Archives/Public/w3c-wai-eo/2001JulSep/0170.html>
  • compare with umbrella page for implementation plan <http://www.w3.org/WAI/EO/Drafts/bcase/ip > [comments that follow are recommended changes to the implementation plan umbrella page itself]
  • make clear statement that the document assumes a management commitment up front
  • do a quick assessment of current situation
  • key questions -- questions may include
  • if uncertain, link to "preliminary review" procedure, however a full conformance assessment is _not_ necessary at this stage
  • general answers may already be very obvious... and otherwise can be obtained very quickly
  • emphasize the role of the access champion at the highest management level, and do a repeated message later.
  • clarify the importance of appointing an overall coordinator
  • reduce some of the detail in carlos' xyz implementation plan
  • write something more general about scope of responsibilities of team, that shows the skills that are needed
  • develop or identify training materials
  • [on natasha's draft] shift technical policy questions up above training
  • [on natasha's draft] flag certain items as appropriate for large organizations; use some style to do that.
  • [on natasha's draft] split training item into two
  • [on natasha's draft] develop a self-monitoring tool -- clarify, and merge with reporting & tracking
  • [on natasha's draft] remove mention of phase 1
  • [on natasha's draft] establish policies for procurement
  • For #5: Add "for medium & large orgs, a team may be required"
  • For major milestones, also, clarify, some points may apply only to larger organizations.

Change requests from 24 August 2001

• Web design implementation plan
  • emphasize the need for designers & developers to be able to sell the concept externally
  • emphasize training developers to a high level of competence, and then confidence in talking to customers about it
  • add talking points about business benefits & cost re-assurance appropriate to the circumstance
  • emphasize design choices that can help preclude later retrofitting
• Corporate implementation plan
  • integrate general advice, then sample implementation models, one for centralized, one for decentralized

Change requests from 17 August 2001

• For "Evaluating Web Sites for Accessibility "
  • CLARIFY run at least HTML validation service or HTML Tide (clarify coverage of XHTML)
  • DONE change to: "make sure that the information is presented in an appropriate sequence relative to the visual presentation on the gui site"
  • DONE add context: "evaluate w/ users as well as technical eval because; picking up problems in how the technical solutions are being applied" talk about: conformance to the letter and conformance to the intent. must apply common sense!! must put yourself in the shoes of the users. have a set of standards for testing the site before you launch them.
  • DONE add: look for people with different levels of familiarity with the site (note, familiarity will change over time)
  • DONE explain: JAWS is the only screen reader translated into Danish and therefore...

Change requests from 10 August

• For "Evaluating Web Sites for Accessibility "
  • DONE retrofitting
  • DONE suggest that they build this into their existing review
  • REDUNDANT (already in ongoing monitoring) add validation to summary steps on conformance
  • DONE disclose accessibility problems in legacy sites
  • DONE editing about qualifications of the reviewer: does not need to know markup; does need to download & run a few things & be familiar w/ how to adjust some things on their browser; conf eval: familiar w/ multiple markup langs, site prep/design/
  • DONE make reference to ongoing suite that this is part of... in note.
  • DONE clean up "determine what WCAG 1.0 conformance level for an existing Web site;"
  • DONE clarify that 3.2.2 is to use accessibility evaluation tool
  • DONE also clarify in preliminary review accessibility evaluation
  • DONE and clarify that 3.2.1 is to validate the markup itself
  • DONE address validation in the summary section of preliminary review, (minority objection) preliminary review should include validation
  • DONE flip the checklist checking to 3.3.1 position not 3.3.3
  • DONE summarize instead of prepare a detailed report
  • WAS ALREADY spell out GUI (graphical user interface)
  • DONE clean up wording on versions and platforms -- 3.3.1 select at least three different configurations from among the following variables: different graphical user interface browsers (for ex IE, netsc, op), in different versions (latest, older), running on different platforms (Windows, Linux, Mac).
  • DONE move questions about site into usability section
  • DONE split up the usability section
  • DONE potentially including evaluation for each page type and a representative URL
  • DONE to maximize likelihood... instead of provide assurance
  • DONE clear statement
  • DONE add validation to ongoing monitoring

Change notes/requests from 3 August

• Evaluation of Web Sites (per discussion from 3 August)
  • DONE off-set NOTE text or integrate it better
  • DONE add a recommended follow up to prelim review
  • DONE reinforce summary section for conformance eval
  • DONE add: processes for evaluating all new types of pages before they are added to the site
  • DONE add: these measures supplement what you are already doing for content management and quality assurance.
  • DONE fix: The first review downloading software and/or familiarizing oneself with some online tools

• Evaluation of Web Sites (per comments from 1 August and comments received)
  1. OK stripped suite nav header in prep for standalone review
  2. OK multiple edits to clarify 'conformance to wcag 1.0' instead of just 'eval of accessibility'
  3. OK cleaned up goals language in intro and changed to "help ensure"
  4. OK replaced 'eval tools' for 'accessibility checkers'
  5. OK changed 'shut your eyes' in prelim review
  6. OK added brief summary and disclosure step in prelim review
  7. OK added line about screen resolution
  8. OK added 'tabbing to form controls'
  9. OK clarified page selection, including those generated by databases, and 'contact us' pages
  10. OK removed spell & grammar checking from conformance eval
  11. OK added CLAD test under manual eval
  12. OK changed 'captions' to 'text equivalents'
  13. OK added multiple platforms into wcag 1.0 conformance
  14. PARTIAL removed 'see' in images turned off

Change requests from 1 August discussion

• Evaluation of Web Sites
  • DONE set screen resolution to 640x480 and observe whether or not this forces into horizontal scrolling
  • DONE listen to it with your eyes shut, then open them and confirm whether you got all the info
  • DONE add an expanded "page selection" option as alternative to entire Web site, to give more explanation about sampling pages:
    • different sections of the site
    • with each different look and feel
    • and created with each different tool or page author,
    • or under different guidelines
    • by outside consultants
    • what about all index pages
  • DONE recommend disclosing definition of page selection in conformance claim statement
  • DONE remove "include Bobby" from #3.2.
  • DONE add a section requiring people to broadly fix whatever representative problems they find on the sample pages

Change requests from 27 July discussion

• Business Benefits Appendix
  • identify and eliminate the printing bug in Opera
  • change wording in socially responsible section so not just an image of soc resp but recommending the real thing
  • add doyle's email about clear content
  • clarify semantic Web support
  • clarify in introduction that these benefits are above and beyond the straight benefits to PWD
  • add in something to soc resp section on demographics also in market share intro
  • reword semantic Web section to clarify why this increases market share
  • clear & understandable as possible -- wordsmith
  • reconsider placement as appendix or not
  • shrink words in intro
  • re-org the first & second bullet set under section two
  • programmers are cheaper than lawyers -- integrate concept but change language
  • reflect social responsibility and market share in benefits matrix somehow
  • try removing some of the nested lists
  • figure out the bug in the table summary
• Evaluating Web Sites
  • DONE drop the "appendix" at the top
  • DONE restructure toc to add a special consideration
  • DONE make the introduction of prelim review less negative: explain "can be useful to identify the scope of problems on a Web site, keeping in mind that it is an imprecise indicator..."
  • DONE eliminate common questions section in preliminary review
  • DONE put away your mouse and tab through the links -- change tabbing trick to "can you even get to them" and that it's clear what it goes to
  • DONE add "including the entry page ("splash screen," "welcome page" etc)
  • DONE fix punctuation after HPR, split up order
  • DONE the same, change to equivalent
  • DONE and add for example before bobby, wave, a-prompt
  • DONE flip order to list wave before bobby
  • DONE under evaluation, add a comment about exclusion of area of the site// justification/ notification/ clarification/ disclosure
  • DONE add as informational note: some of these tools can be used to sweep the entire site: add HTML Tidy for sweeping whole site, and sweep with downloaded bobby as well, WAVE, and sweep the site with one of the following.

Change requests from 20 July discussion

• Evaluate effort/feasibility of split w/out proceding yet
• Evaluate evolving benefits piece as standalone document for now
• Focus more effort onto completing all pieces involved in implementation plan side of the suite (regardless of split or not)
• Comments on latest draft of evaluating Web sites appendix
  • [NOT DONE; REDISCUSS] expand section on having pwd w/in an organization doing the reviews, including making sure they get adequate training, recognition, and time
  • [OKAY JULY 27] PARTIALLY [Made the disclaimers much stronger, but skipped this] add another disclaimer reminding people that they won't even get an indicate of valid HTML, but try to turn it into a motivator
  • DONE okay to leave out plug ins from simple review
  • DONE take section on goals and expectations and integrate it into introduction so that point simple & comprehensive is immediately clear
  • DONE explore a way to incorporate Gregory's comment about _maintaining_ a given conformance level, via discussion in ongoing monitoring and linking to organizational policy
  • DONE separate some of the items, e.g. check the tabbing the order -- or combine all the browser tricks into one, with individually numbered sub-bullets for the tabbing etc
  • DONE make the simple review work for people with disabilities as well by providing alternatives
  • DONE add a strong caution about the simple review leaving out key perspective of users with disabilities, and should be seen as a preparatory step only, and reinforce that proper review should involve pw a variety of disabilities.
  • DONE change name of simple review to preliminary review, emphasize that this is what you do before you bring people in
  • DONE run a Web checker such as [name them and explain a bit how to get them and use them]
  • DONE add in the country-specific checks depending on situation

Change requests from 13 July 2001 discussion

• discussion of latest aux ben draft
  • replace wrangles slang -- reduce legal liability, vulnerability, exposure, etc
  • add audience to market share
  • get the jargon out without diluting the message
  • split up intro and maybe make it wordier
  • take auxiliary out of title
  • reminder: this should end up being usable as a standalone document also
• discussion of first draft of review appendix
  • [ADDED a placeholder] expand section on coordinating w/ pwd on site review, adding cautions and tips about the issues
  • [ADDED a placeholder in ONGOING SECTION] also tips on evaluating sites that are static
  • [ADDED a placeholder in ONGOING SECTION] follow up _on_ non-conformant sites
  • [ADDED a placeholder] comment on pros/cons of putting together a lab
  • [REDISCUSS] mention hiring people with disabilities
  • [REDISCUSS] add to 5 with plugs-in turned off
  • PARTIALLY add something encouraging about customizing your protocol
  • DONE add semi before automated. Recommend more than one. And link other. Only the first step etc.
  • DONE careful of non-exclusive use; NOTE and then YOU MUST DO OTHER
  • DONE move up the design stage stuff in the intro
  • DONE reminder that initial developers are often outside folks, and much easier to deal with them then
  • DONE add a little section called "tips on evaluating a site DURING the development process"
  • DONE (add feedback loop on site for more comments from general)

Change requests from 11 July 2001 discussion

• discussion of materials posted from Diana Pursells
  • make it optional to come in sideways; not all people will want both steps
  • lay out the step options without assuming different orders
  • make sure not to mix implementation plan steps with initial business case convincing
  • make two primary exits from top page, one to business case stuff & one to implementation plan stuff
  • strip out as much information as possible, but leave a little substance ("meat") for orientation
  • have the modules be the continuous capture, with a printing emphasis
  • explore some possibility of phases in implementation plan w/out getting into too much detail
  • choose your organizational type instead of business
  • be conscious about how much we're re-using stuff, go ahead re-use it, within the context of the modules, and with appropriate variability for different contexts.

Change requests from 6 July 2001 discussion

• Discussing feedback on auxiliary benefits appendix
  • add in the social aspect and avoidance of legal wrangling...
  • avoid legal wrangles: it's the law & there are policies of organizations, and programmers and cheaper than lawyers
  • being a good citizen: temporarily acting altruistically and inclusively & improving your public & being attractive to PWD

Change requests from 29 June 2001 discussion

• Discussing feedback from 22 June face-to-face meeting
  • consider developing separate document discussing how to generate media interest in topic of Web accesibility, AND
  • add a component into bplan implementation modules about publicizing organizational commitment to Web accessibility (and then William will get feedback from media talk list)
  • look somewhere tho not nec in this document for place to address advocacy
  • look for place on agenda to address inreach more often
• Policy Appendix
  • [DONE] keep the two examples at the beginning; helps to understand the rest of the document.
  • [DONE] keep playing with better nav options at top of page
  • [DONE 20020607] #2 Reference: add a point addressing issue of version: consider specifying 1.0 or not specifying a version w/ ability to roll forward
  • [DONE 20020607] #3 Conformance: roll together the second two points about authoring tools
  • [DONE 20020607] #3 Conformance: review language in authoring tool /subcontract section for sensitivity
  • #4 Try to incorporate some discussion about third-party feedback into one or more of business case modules, along with seeking increased media attention to organization's leadership
  • #4 Try to get W3C /TR/ pubrules to Double A.
  • [DONE 20020607] #5 Milestones add "but with a fixed deadline"
  • [DONE 20020607] #5 Milestones: remove sales, service etc & use fill in the blank
  • [DONE by adding to existing example 20020607] #5 Milestones: add another example that deals with large volume of legacy content; consider with Webtrends, at least update most frequently-accessed pages. Emphasize that you should get to everything at some point. Emphasize use of other tools that can help with converting the legacy problems.
  • [DONE 20020607] Somewhere: add statement about considering UAAG conformance of browsers & multimedia players without restricting individual's ability to use adaptive browsers etc.
  • [DIDN'T DO; DIDN'T WORK] #Monitoring: break out as a separate bullet the feedback item.

Change requests from 15 June 2001 discussion

• Who's doing what: reviewed http://lists.w3.org/Archives/Public/w3c-wai-eo/2001AprJun/0178.html
  • bunch of changes, detailed in meeting minutes
• Education, Higher, Implementation Plan http://lists.w3.org/Archives/Public/w3c-wai-eo/2001AprJun/0177.html
  • make it somewhat specific, though fictitious, rather than general
  • split it into two pieces: a business case and an implementation plan
  • bus case part should sound a document one could present to convince management
  • maybe should include a very very brief (2 sentence) exec summary
  • should emphasize several different kinds of reasons why it's important for the university to make Web accessible
  • particular emphasizing requirements (assuming that those exist in this environment, or may soon)
  • include emphasis on if you make it accessible, they will come
  • present a discussion of cost & benefit at a high (management) level that apply to educational setting:
    • (including initial cost and cost over time)
    • upgrading of software
    • training, technical assistance, etc.
  • discuss potential impacts on institution
  • make "develop a detailed implementation plan" as a last paragraph, e.g. "if management agrees to commits to accessibility, then the next step would be to develop a detailed implementation plan.
  • draft an implementation plan to complement the business plan
  • consider adding a timeline into the imp plan including references to external events that could hypothetical drive that timeline
• Appendix umbrella page http://www.w3.org/WAI/EO/Drafts/bcase/ap
  • mention the different environments that we've develop modules for
  • potentially add another appendix, on setting up training
• Developing an Organizational Policy http://www.w3.org/WAI/EO/Drafts/bcase/pol.html
  • NOTE: Also tweaked the nav bar at top (need feedback) and added a mini-policy-statement example and a more in depth one, again need feedback.
  • NOT YET format: turn it into a link farm
  • DONE monitoring: add "what involvement there will be by people with disabilities in reviewing the site"
  • DONE milestones: add milestones for getting internal process (training and tools) for creating pages supportive of accessibility
  • DONE milestones: raise issue of dipping into Triple A (as associated with organizational goals)
  • DONE naming guidelines: mention benefits of harmonization & avoiding fragmentation
  • DONE conformance level: add "do at least what is mandated by regulations applying to your Web site"
  • DONE monitoring: take out "should pages" and "if so"
  • DONE logos: tweak them more
  • DONE logos: change header to conformance claims
  • DONE logos: depending on logo used, should conform to criteria that they provide
  • DONE follow-up: incorporate a feedback mechanism on Web pages
  • DONE roll-forward: explain more
  • DONE roll-forward: allowing a policy to update itself automatically
  • DONE software: take out the should
  • DONE format: abandon question format throughout bullets & use some directed questions
  • DONE naming: take out parenthesis, highlight
  • DONE milestones: add the option of going directly to Double A
  • DONE naming: clarify to "reference" instead of naming
  • DONE gap: add: look for poss to add xs to other org-wide Web site policies
  • DONE priorities: change to "do not make assumptions about which sections of a Web site pwd are not interested in"

Change requests from 8 June 2001 discussion

• Benefits matrix draft http://members.optushome.com.au/amja/wai/ap-auxben3t.html (AA)
  • link all yes' in matrix to the narrative in the appendix
  • neaten up the headers at top
  • make it the first section after a brief TOC in this appendix
  • try swapping what's in columns now for what's in rows (may not work anymore)
  • mark up column & row headers more consistently (HB will help AA mark up more clearly)
  • label the column headers & row headers as categories, e.g. accessibility solutions AND auxiliary benefits
  • find our tool for row & column swapping, build it in on the page for dynamic swapping
  • link checkpoints from parenthesized number
  • experiment with different to treat the "no" or "n/a" that minimizes clutter and maximizes cross-disability readability
  • consider using + and - . Or yes/no cleanest approach ?
  • link column headers (benefits) as well, to benefits headers
  • add more explanations in narrative where andrew has noted new ideas (as long as they don't sound like a stretch)
  • re-examine groupings to make sure they make sense, e.g. literacy & semantics go in benefits
  • add a least a little bitty introduction to the matrix, so people have some clue what they're about to read
• Implementation planning http://lists.w3.org/Archives/Public/w3c-wai-eo/2001AprJun/0163.html (SS)
  • Use international terms for macro-educational levels: basic, secondary, and higher (this draft is directed to basic & secondary -- we need to say so)
  • Avoid use country-specific terms such as "districts." Use "schools" and "school systems" and mention in policy section that one needs to address decentralized systems differently than centralized systems.
  • Identify at what level decision-making and systems-change happens in the school system AND THEN identify decision-makers and change agents at the appropriate levels within the system. Consider the following categories of people within the system.
  • Try to ensure that the document can speak to whomever in a given system might become interested in this issue, and allow them to be a catalyst within that system, e.g. don't prescribe who to speak to.
  • Mention that assistive technology may be needed and should also be considered at the individual student level.
  • Put in same format as other pages to make it easier to review for comparability with other sections.
• Top page review http://www.w3.org/WAI/EO/Drafts/bcase/ (JB)
  • DONE split education more
  • DONE add software implementation plan
  • yes, do flow chart or sequence of steps on umbrella business case page and umbrella implementation plan page, not on top page
  • DONE yes, new appendix line-up is okay, with some renaming and with dropping of references page
  • take new index from top page and put out list of who's working on what to the EOWG list & check schedule

Change requests from 6 June 2001 discussion

• Top page
  • NOTE Reorganized & added appendices -- check this
  • DONE make it into an index not narrative
  • TRIED [difficult for appendices] make shorter headings pointing to more information
  • DONE [but shorter] take the menu at the top of the screen, put it under top heading, then put individual sections with 2 or 3 lines explanation
  • DONE clean up but keep the internal nav bar for resource suite
  • DONE shorten overall title
  • NOT [jb: thinks we need to do this on a separate page -- DP working on] walk them through a process of building own business case & implementation plan
  • make it a flow chart of choices (differentiate making the business case vs. coming up with implementation detail) (DP volunteer)
• Umbrella page for sample business cases
  • needs more white space, some kind of different formating
  • make links to modules strong
  • need modules to get the discussion going (GL may send Ed bcase)
• Umbrella page for sample implementation plans
  • will be stripping out all the detail & putting it into appendices, as per previous discussion, and link to those (JB)
  • but also make the embedded detail as a sequential detailed version
  • take out reference section and put it in the appendix where it belongs
• Policy appendix
  • break page down into different environments (OR different questions (how specific? how general a policy is needed?) OR countries)
  • try reformating a question and answer dialog

Change requests from 1 June 2001 discussion

• Discussion on draft of Auxiliary Benefits of Accessible Design for Business Case
  • tighten up explanations to try to shorten document somewhat -- try to eliminate wordiness of many sections.
  • look for any unnecessary redundancies to eliminate
  • add in brief intro reminding people of this document's position relative to other documents in resource suite
  • try using a tabular representation of issues (first thing to try), or a table of contents
  • server load - mention that better navigation results in fewer unnecessary downloads of pages, including better defined links, and including clear & consistent use of graphics to indicate key features & functions on sites

Change requests from 25 May 2001 discussion

• First draft of appendix on auxiliary benefits: http://members.optushome.com.au/amja/wai/ap-auxben1.html
  • check whether reduced number of links is clear in our guidelines (WL will do)
  • relate improved usability to development tools (combine with XHTML & XML point)
  • clarify how XHTML & XML provide benefit (look at XML guidelines)
  • DONE intro should highlight that the aux benefits appendix is (entirely) for benefits above & beyond those for pwd (AA will revisit)
  • DONE clarify server-load and LOW bandwidth (AA will revisit)
  • ask Hakon Wium Lie to look at style sheet sections once more done
  • consider repurposing & low bandwidth as combined -- see what happens in the detail
  • DONE add multimodality as a support for comprehension among non-first language speakers -- increase market share -- emphasize -- and
  • DONE consider spinning off a set of resources from this
  • DONE low-bandwidth -- add mention of style sheet efficiency as well
  • DONE! really needs more detail (AA: yes! will! just wanted to get it started) (CL: would like to help filling in the detail)
  • DONE add support for semantic Web, under improved search engine listings and resource discovery or elsewhere
  • DONE add a few-sentence intro. CL working on it.
  • DONE text alternatives seems redundant; clarify more
  • DONE improve consistency of headers (AA will fine-tune)
  • DONE re-organize the order of headers, put usability first
  • DONE also add device independence under usability -- situational
  • DONE do some cross-checking to ensure that everything we mention here is really part of the guidelines (WL)
  • DONE consider having no links on this page (!) make sure standalone-readability
  • DONE change multilingual... to increase support for internationalization
  • DONE **break up the list into two super-sections -- market share and efficiency**
  • OKAY don't add explicit checkpoint links
• Add an appendix discussing benefits of using software that conforms to authoring tool accessibility guidelines

Change requests from 18 May 2001 discussion

• Corporate implementation plan http://fit.gmd.de/~velasco/wai-eo/ipcorporate.xml
  • Discussed some minor wording changes, to be followed up off-line by Carlos & Judy
• New Appendix draft on Developing Policy on Web Accessibility http://www.w3.org/WAI/EO/Drafts/bcase/pol.html
  • DONE agreed, okay to have it as a separate appendix & take detail out of implementation plan
  • DONE link to policy reference links page
  • DONE clarify headings, make cleaner, e.g. "specify a conformance level"
  • DONE address roll-forward to WCAG 2.0 once available
  • DONE consider phase-in of level A then double A later
  • DONE address old/existing documents on sites as well as new documents
  • DONE address subcontracted and/or third party Web site development
  • DONE clarify level A and double AA applicability
  • DONE review software used and consider whether to set a policy on software used
  • DONE consider addressing subcontractor software use if locking organization into proprietary authoring system or if using tools that produce invalid code
  • DONE address development of templates
  • SOME don't reiterate what's in other parts of resource suite; use pointers where appropriate
  • DONE don't specify using particular assessment tools in policy statement, rather specify a general approach
  • DONE attempt a draft of something addressing prioritization of which areas or pages on a site get first treatment, or drafting something to counter the idea that people with disabilities are only interested in certain kinds of pages
  • SOME (discussion: enough?) provide neutral statements & highlight pros & cons about different approaches
  • NOT YET (wait until this appendix is stable) link from policy reference links page to this page
  • NOT YET provide examples about different approaches
  • NOT YET provide statement of issue, rationale, and example

Change requests from 11 May 2001 discussion

• Corporate implementation http://fit.gmd.de/~velasco/wai-eo/ipcorporate.xml
  • add more links to detail e.g. for training
  • roll in Lila's comment & strip code
  • jb roll it into site
• Cost factors http://www.w3.org/WAI/EO/Drafts/bcase/ap-impcos.html
  • link from "ways to mitigate cost" to retrofitting tools
  • in assessment section, provide link to tools and to review process
  • drop question marks
  • link to appropriate types of curriculum
  • on tech assist also link to section of annoted resource list that highlights techniques documents
  • flip conditionality around, e.g. sites with substantial problems... may require additional time (e.g. statements)
  • link to tools and link to new QA matrix, from the QA & testing section, and link those two to each other.
  • change reference to "prompt"
  • take out "accessibility solution" for CSS
  • several grammar and punctuation errors, will be sent to list
  • clean up "reduce increase" error
  • in some cases, reduces file size.
  • emphasize other ways in which descriptive material can be search engines
  • add people with distance/bandwidth problem
  • change "10%" to substantial
  • link to demographics appendix once done
  • add impact on Web site functioning -- simplify lists -- if needing examples...
  • all agreed that with these changes the page is basically done, pending intersections or collisions with other parts of the document
• Review factors:
  • review process: build a clean appendix page -- JB (and get ERT WG to review it)
• Appendices review:
  • Demographics -- starter piece from Kevin Carey
  • Auxialiary benefits of accessible design -- starter page http://www.w3.org/WAI/EO/Drafts/bcase/ap-auxben.html (AA interested in working on) be cautious about overlaps with cost factors appendix
  • Legal requirements for accessibility -- JB will draft a small bridge piece linking to Policies Relating to Web Accessibility
  • Implementation considerations -- remove this page unless we need a mega-list of implementation steps.... may still need that.
  • Cost factors -- close to done
  • Resources/references -- see whether need a separate page or can point to existing WAI resource pages.
• Demographics http://lists.w3.org/Archives/Public/w3c-wai-eo/2001AprJun/0000.html
  • request Steve Jacob's framework, see if he can share on public list
  • use some of Kevin's text to describe this
  • be sure to incorporate some information from developing countries
  • include a core section about disability demographics and then a menu of other demographics to consider (LC interested; JB may do brief starter piece)

Change requests from 20 April 2001 discussion

[need to incorporate discussion from minutes]

Change requests from 6 April 2001 discussion

• http://fit.gmd.de/~velasco/wai-eo/ipcorporate.xml
  • add clarification about accessibility
  • address core external services and core internal services first
  • acquisition/deployment/training
• http://diap.net/bizcost.htm
  • take out "accessibility implementation strategies" and following paragraphs

DONE Change requests and writing commitments from March 30, 2001 discussion

• Reviewing draft prepared by MU, RN, PJ, at http://lists.w3.org/Archives/Public/w3c-wai-eo/2001JanMar/att-0119/01-part
  • DONE add "liability" back in.
  • DONE provide more definition of business terms/jargon, as an in-line explanation of the terms
  • DONE careful about placement of items. for instance, architecture (in 2nd list) might belong in first list also. change transfer rate cost. number of pages, dynamic vs. static. variations in user agent support. all could go either way. what about creating new list, cost or benefit categories, or other considerations (cost or benefits)
  • DONE separate out the implementation material from the beginning and move it to another part of resource suite
  • DONE consider adding some brief elaboration to each item
  • DONE add a brief introduction to cost item list and benefit item list -- NOTE -- now we want to collapse these
  • DONE clarification: new method of providing services will lower cost of providing services (for government)
  • THANKS next writing volunteers, Jean-Marie & William. Maybe Andrew.
  • DONE mention "investment" in intro.
  • DONE collapse cost & benefit items into cost considerations.
  • DONE provide a thinking-framework to the cost considerations list.
  • DONE try to reduce the number of items, for instance, group the training items in one category, however preserve the detail as an inline explanation.
  • DONE mention short-term and long-term.
  • DONE GL will ping SS about applicability for earlier education
  • DONE remove reference to "corporate" but clarify that it is organizational
  • DONE take out "universal accessibility"
  • DONE change the "executive summary" more to an "introduction" format, like on the http://www.w3.org/WAI/EO/Drafts/bcase/ip -- do this a bit later. Remember that people can come into these resource suites sideways.
• THANKS Business implementation plan -- CV sending mid-week, SD, CL, LC, HB, will comment.

DONE Change requests AND WRITING COMMITMENTS from March 25, 2001 discussion

• DONE costing model: consider training costs, as well as implementation costs, subject matter expert, materials necessary to support accessibility including adaptive technology, cost of developer time for putting in the accessibility components, cost of QA by subject matter expert, include retrofit costs broken out separately;
• DONE costing model: careful to look out for the added disadvantage level;
• DONE costing model: look at potential loss of opportunity revenue, as well as risk factors such as from liability, then look at implementation cost, and build it into checklist. There will be a spike on cost to implement, then smooths out over time. Also look at the cost of not doing this, in terms of accommodations that need to be made otherwise, e.g. point to How PWD Use the Web.
• DONE costing model: look at questions for marketing department
• DONE costing model: look at marginal cost on what they're doing anyway, e.g. a standard cyclic retrofitting.
• DONE costing model: acknowledge cost of retrofitting. sometimes redesign from scratch.
• DONE demographics: possibly rephrase it in terms of customer base.
• DONE costing model: helps in porting to wireless...
• DONE costing model: think about better headers, more inviting. get away somewhat from the word accessibility. usability. universal accessibility. want more discussion on this.
• DONE style: careful about making it too specific, it's very hard to make it too specific. go from "as is" to "to be" to "how you're going to get there"
• DONE incorporate sample corporate plan info from http://fit.gmd.de/~velasco/wai-eo/ipcorporate.xml
• DONE comments on CV's draft examplar: start with a bold crisp intro, e.g. "our organization's challenge is to..." or "our organization, having made a commitment to..."
• DONE comments on CV's draft examplar: (state a note that option of differt argurmanets)
• DONE CV: drop "enforce"
• DONE CV: use "we"
• DONE CV: add step to adopt a specific policy
• DONE CV: make it more future-oriented. by such and such a date, a person would be appointed to take responsibility for this... e.g. make sure technicians know about it first.
• DONE CV: identify the sequence of people who need training. identify the number of days of training needed. Assign responsibilities and accountab. Build a timeline for implementation

Change requests from February 23, 2001 discussion

• As pages are cleaned up a bit, e.g. the /ip page now, upgrade the warning to state: replace under and circumstances to without permission of the editor, and put a big draft on the top. Add a draft warning.
• Add in something about an advisory committee, meeting frequently, with representation from different stakeholder groups, to assess needs & establish an appropriate policy.
• Emphasize that this is optional, not prescriptive, use what is appropriate for your business context. "Use the level that is appropriate to your needs or to the org's requirements."
• Promote awareness section should include strategies to address questions that arise about implementation, especially in areas where there is decentralization of management of Web sites.
• Also address this in training section, where designers need access to techniques reference materials.
• Authoring tools: if cannot change tools in use, increase the evaluation and monitoring of sites.
• Training: emphasize the need to train designers with the tools that they have.
• Broaden the term Web master -- use a long form at the top, and short word after that.
• Address issue of how to certify that sites CONTINUE to meet the organizational standard.
• Intro: don't start with an apology. Re-organize and get more feedback.
• Assess current situation: make clearer statements. Do this, do that. Just put a disclaimer up front.
• Assess: also consider customer's and partner's Web sites.
• Assess: change title to "Quickly Assess Current Situation and Develop Priorities"
• Assess: add "clarify WHAT accessibility means while doing this evaluation"
• Assess: what is the training structure within the organization
• Assess: mention usability in current #5, assessing policy.
• Assess: training notion fits into #3.
• Policy: getting organizational commitment in terms of time and resources from relevant departments, also document flow and content management.
• Policy: emphasize getting commitment of training resources and identifying responsible parties.
• Policy: emphasize stability of WCAG 1.0, and not add 2.0 in process. Careful of mentioning 2.0. At whatever point _a_ future WCAG becomes a recommendation.
• cost: pj, rn, mu developed a sample -- will rework it according to input from wg meeting

Change requests from February 16, 2001 discussion

• address more about cost considerations up front
• add more about myth debunking up front
• intro page should make more clear why bundling together the business case and implementation plan
• emphasize use policies for the whole thing, and also on sample pages
• consider making better solution for situations that don't fit the models -- making a compilation of modules, one document with everything, or make it easier to choose from among -- or one generic for each
• emphasize that the categories shouldn't be taken as absolute, make it much clearer, no forcing!
• titles need to be shorter. creating a business case.
• needs graphics, simple graphics, little pictures of people, scale of justice
• think about cross-references between the business cases
• provide back-links to modules from the appendices
• consider making a mega-table cross-referencing the various modules
• try better way suite nav bar
• try combining business case + implementation plan into business plan
• LC will work on demographics... JB will send...
• HBj interested in helping SS & GL on education, and working with KA on policy/governmental

Change requests from February 9, 2001 discussion

• add concept of "legal" to "policy" without making "legal" only
• use general demographics but with pointers to resources on a country-by-country basis
• WL: compiling factors affecting cost (currently seeking resources)
• KA: compiling linkset for additions to legal requirements & policy development
• CV & HB: compiling info for Web design, for business plan & implementation plan
• SS: education -- K-12 implementation plan
• GL: education -- secondary implemention plan
• SS & GL: education -- business case, for next week
• Business section should be the why; implementation plan section should be the how

Change requests from January 26, 2001 discussion

• JB: collecting implementation experience from several governments
• make it clearer that this is for helping people build their own business cases
• front page should be more like planning/training resource suite
• need to add lots of pointers to other resources
• add a succinct initial motivator chapter
• clearly separate business plan & implementation plan; once committed, no need for business plan
• CL: will try to get implementation info from CA government; turn into composite if needed.

Change requests from Oct 6, 2000 discussion

• [DONE? See draft re-org] Consider making it a "how to build a business case" with some generic variant examples and some appendices that could be modular elements of a "level two business plan"
• [DONE? See draft re-org] one page how-to; up to four generic sample top management, 2-page plans; various appendice/modules for 2nd-level management (maybe one page each); attach implementation case studies (maybe one page each?);
• [Feasible in new format] enable dichotomy between profit-motive focus and greater-good focus
• [DONE] make it a WAI Resource! not a Note.
• Missing!!! In the "resources to support implementation" give them more assurance that the resources exist _and_ that there is a growing int'l buy-in to consensus solutions on Web accessibility -- that this is an accepted industry standard...
• Missing!!! growing expectation of rights/ expectations for accessible information
• Add a lead-in (ego appeal) for each: and for corp one it would be, hullo in this modern age your customers expect this; as a modern education institution we are moving ahead to implement widespread ed; service to citizens (taxpayer value for their money)
• DONE Restructure how we talk about benefits, e.g.: (make it more blatant!!)
  • DONE Benefits include (for corp)
    1. direct access to broader market because of being able to sell to pwd
    2. indirect because of device independence
    3. situational independence...
    4. indirect broadening of market because of family members etc (never assume that there isn't a pwd in the network of p using your material)
    5. also indirect because of agencies that need to purchase, either because of their publ info role or because pwd working w/in the co.s....
    6. also benefits of efficiency/css/ updating/audio/indexing etc etc
    7. also decreased liability to lawsuits where requs exist
    8. and by the way makes your co look good//leadership
    9. suitability for multilingual translations
    10. AND accessibility contributes to general usability!
• General: Make the section headers zippier! e.g. not "demographics of disability marketplace" but "how to increase our market share" :-)
• Ordering of individual bcase samples:
  • For corp bcase, use section order of benefits, costs, impl considerations (retitled zippier!)
  • For academic bcase, call it what? justification? inclusion?: use section order: benefits section (should emphasize requmts/liability up front; and inclusion up front; demographics of the student population); implementation considerations (incl on-line curric); then cost;
  • For gov't agency policy/practice/bcase; (0?1?) social inclusion/digital inclusion; (1?0?) requ's; (2) other benefits; (3) implementation considerations (bury a little bit of cost info here, but don't emphasize)
  • For non-profit organizations OR OTHER, NGO's: benefits (esp includ visibility, "draw," usability, attractiveness, leading by example); cost; implementation considerations; resources/assurances...
• Benefits:
  • keep it in this mode: feature, benefit! feature, benefit!
  • talk about the elegance of technology design, and using pwd as a litmus test for effective technology design (including the imptnc of hiring from outside of the box... --> implementation plan)
• Demographics:
  • build in little spotlights on interesting statistics, e.g. in the UK... Age Concern & Microsoft found that 20% of people aged over 50 have shopped online; and 2/3 of vis imp people in the UK are over 60
  • extend the competitive market sector model to government, education, and NGO's bcase's as well, to the extent appropriate...
  • also talk about the purchasing power...(sensitivity...) (see if can find any info from market analysis of how this sector spends its money) e.g. look at loyalty patterns, bookmarking trends, etc.
• "How To" section
  • we have sprinkled the text w/ some illustrative stats, however unless yours is a multinat'l org, you will prob want to tailor these
• Stats/fast facts appendix
  • give some interesting stats as examples that people might want to find corrallaries (sp?) for locally
  • suggest questions for future surveys and studies as well!!
• We need an "answering objections" module
  • a yes/but page w/ common objections and canned answers as an additional appendice/resource at the end... that people can roll into their bcase
• Requirements:
  • somehow make it bridge nat'l boundaries, & diff enforcement policies, maybe by emphasizing rising soc expectations for accessibility of IT, and by mentioning the UN standard rules, and EU.
  • separate out the requirements levels by headers
• Resources
  • be sure to clearly cite wcag and also to explain assurance of int'l standard
• Implementation section
  • need to clarify that the policy to be complied with may be part of a larger policy, e.g. in Canada the Common Look and Feel
  • need a point person within the organization -- ask whether there is someone who is accountable within the organization.
  • pull out the external perspective items from Daniel's plan and maybe throw those over into something tied to review processes; and make the remaining items clearer that they're from an internal implemtntn perspective
  • implementation plan, with timelines, etc....: implementation considerations... retrofitting, and then what, beyond fixing what's broken...
  • if a checker used, has more than one?
  • have pwd had an oppty to view and comment? EARLY.
• DONE Cost
  • DONE also talk about authoring tools here
  • DONE talk about "investment" as much as we can
  • DONE put in a template of potential costs
    • projected cost for training
    • and/or outsource!, or new hires to bring skills in (buying the skills in)
    • software
    • new template development
    • time spent in retrofitting inxsbl pages
    • time spent encoding xsblty info in new pages
    • addtn'l eval & QA costs (incl time to check & people to check)
    • re-approval time by mngmnt
    • be sure to differentiate between new and old locations....
    • overall cost of site (i.e., look! the access cost is only a small proportion...)
    • cost-savings in medium- to long-term maintenance and upgrading of site
• Who's doing what, by Oct 16th.
  • GL gathering statistics
  • HBJ try to find Nordic stats... extrapolated
  • WS help out with benefits part
  • LC evaluation plan in implementation plan

wishlist

• Link to table of contents - draft at http://www.w3.org/WAI/EO/Drafts/bcase/toc.html
• Have resource covering "myths" that relate dto business case that can link to -- common challenging questions, e.g.:
  • Why address Web accessibility if it only affects a small number of people?
  • But our audience doesn't include people with disabilities. (Handicapped people don't come here anyway!)
• Perhaps add section about the isses (problems) surrounding
• Social Factors, Role of Organizations' Web Sites:
  consider adding "Accessible Web authoring tools, browsers, and other Web tools also have a role in Web accessibility." when have Components to link to
• Social Factors, Barriers to Web Use:
  "Currently there are significant barriers on the Web for many people with disabilities. Because most Web developers do not make their Web software and Web pages accessible, many people with disabilities have unnecessary difficulties using the Web, and in some cases, cannot effectively use the Web at all." [@@need for example here? wish had doc to point to!!!] "However, if Web sites were made accessible, people with disabilities could effectively use the Web. (How People with Disability Use the Web includes scenarios that illustrate some requirements of people with disabilities when using the Web.)"
• Legal and Policy Factors, Are the requirements adequate to meet the needs of people with disabilities?:
  "Required guidelines or minimum conformance level might not adequately meet the needs of the Web site's users with some disabilities. In that case, an organization might choose to meet additional guidelines or conformance levels in order to provide sufficient accessibility."
  Would be great to be able to point to comparison of WCAG 1.0 & Section 508 1194.22 and show where 508 does not need needs of all people with disabilities.

Copyright © 1994-2008 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.