> EOWG Home Page > Business Case

Change Log: Business Case for Web Accessibility

This page records change requests and changes made to the draft WAI Resource Suite Business Case and Implementation Plan for Web Accessibility. Please send additions or corrections to w3c-wai-eo@w3.org. Last updated August2, 2002, by Andrew Arch (andrew.arch@visionaustralia.org.au).

NOTE: Change log for "Implementation Plan for Web Accessibility" has moved to http://www.w3.org/WAI/EO/Drafts/impl/changelog and recent changes to "Evaluating Web Sites for Accessibility" are also now in that log.

Change requests from 9 August 2002

• DONE Change 2.1 heading to "Expand Your Audience"
• Define 'business case' briefly in the suite document, and use 'resource suite' rather than just 'suite'
  Suggestion: "A business case is a structured argument or justification as to why an organisation should commit to a path of action or commit resources to a project - it compiles the rationale for a course of action."
• Try using 'expand' rather than 'increase' in the document in general
• DONE Section 2.1, 3rd dot point - change 'breadth' to 'diversity'
• DONE Take Charmanes Corcoran's and Chuck Letourneau's comments on board as appropriate.
• Consider Natasha's comments for introduction.

Change requests from 2 August 2002

• DONE Sect 2, 1st para: "discovery" - change or explain in parentheses
• DONE References draft document - needs disclaimers

Change requests from 30 July 2002

• DONE (see discussion on list) Filters to apply include:

• • '1st' order outcomes vs '2nd' order outcomes/claims (eg audience reach vs market share)
  • Language used - consistent approach
  • Look at any ref to PWD - say 'beyond the impact on PWD' these are considerations
• Change title (Section 2) to "Increase the potential audience" (see August 9 changelog)
• Use of "User Experience" vs "Customer"
• Section 2 suggestions
  • regaining market share is important as you have already lost many people
  • 'beyond regaining your market share, it would also help reach ....'

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)
  • DONE (see draft References document) link to substantiation where possible (LC, AA)
  • DONE note in document that it is not an exhaustive list
  • DONE (via menu) 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)
  • DONE change skip table link to link to lineared version
  • DONE add link to linearized version after benefits matrix in TOC
  • check space between links
  • DONE 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 Håkon 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

Copyright  ©  2000-2002 W3C (MIT, INRIA, 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.