> EOWG Home Page >
Change Log: Business Case for Web Accessibility
This page records change requests and changes made to the draft WAI Resource
Case and Implementation Plan for Web Accessibility. Please send additions
or corrections to email@example.com.
Last updated August2, 2002, by Andrew Arch (firstname.lastname@example.org).
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
- 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
- '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
- 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
- overview (outline/how to)
- marketplace (disab demog & other marketplace)
- auxiliary benefits (whatever's left, eg. efficiency)
- legal considerations (requirements/liability)
- social responsibility (image)
- scenarios (short)
- cost and value of implementation (how to roll together)
- university, i18n [bh]
- government, transitioning physical access mandate to e-government [mu]
- abstract from example from paper [hbj]
- tesco example [bh]
- online shopping, broader family [lc]
- web design business [jb]
- library, ellen? [hb]
- 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
- 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.
- Comments on business
- 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,
- once we think that the next draft is ready for feedback, do the survey
- try trimming the document -- jb send to gv (AA + JB)
- try adding an exec summary -- that prioritizes (AA)
- 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
- 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
- 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
- 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:
- ask people comment on how info is displayed
- and on any redundancies at given levels
- and invite translations.
- Comments on new outline for corporate
- 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
- 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
- Web design implementation plan
- emphasize the need for designers & developers to be able to sell the
- 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
- 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
- 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
- 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,
- DONE move questions about site into usability section
- DONE split up the usability section
- DONE potentially including evaluation for each page type and a
- DONE to maximize likelihood... instead of provide assurance
- DONE clear statement
- DONE add validation to ongoing monitoring
- 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)
- OK stripped suite nav header in prep for standalone review
- OK multiple edits to clarify 'conformance to wcag 1.0' instead of just
'eval of accessibility'
- OK cleaned up goals language in intro and changed to "help ensure"
- OK replaced 'eval tools' for 'accessibility checkers'
- OK changed 'shut your eyes' in prelim review
- OK added brief summary and disclosure step in prelim review
- OK added line about screen resolution
- OK added 'tabbing to form controls'
- OK clarified page selection, including those generated by databases, and
'contact us' pages
- OK removed spell & grammar checking from conformance eval
- OK added CLAD test under manual eval
- OK changed 'captions' to 'text equivalents'
- OK added multiple platforms into wcag 1.0 conformance
- PARTIAL removed 'see' in images turned off
- Evaluation of Web
- 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
- 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
- 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
- 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
- reflect social responsibility and market share in benefits matrix
- 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
- 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
- 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
- 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
- discussion of
latest aux ben draft
- replace wrangles slang -- reduce legal liability, vulnerability,
- 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
- [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
- [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
- DONE (add feedback loop on site for more comments from general)
- discussion of materials posted from Diana Pursells
- make it optional to come in sideways; not all people will want both
- lay out the step options without assuming different orders
- make sure not to mix implementation plan steps with initial business
- 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
- 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
- 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
- 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
- [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
- 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
- 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
- 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
- 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
- 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
- DONE priorities: change to "do not make assumptions about which sections
of a Web site pwd are not interested in"
- Benefits matrix draft http://members.optushome.com.au/amja/wai/ap-auxben3t.html
- 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
- 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
- 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
- Use international terms for macro-educational levels: basic, secondary,
and higher (this draft is directed to basic & secondary -- we need to
- 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/
- 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
- 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
- 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 &
- 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
- 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
- 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
- relate improved usability to development tools (combine with XHTML &
- 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
- DONE change multilingual... to increase support for internationalization
- DONE **break up the list into two super-sections -- market share and
- OKAY don't add explicit checkpoint links
- Add an appendix discussing benefits of using software that conforms to
authoring tool accessibility guidelines
- 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
- 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
- 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
- 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
- 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
- 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
Change requests from 20 April 2001 discussion
[need to incorporate discussion from minutes]
Change requests from 6 April 2001 discussion
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
- 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
- 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
- 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
- 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
- DONE comments on CV's draft examplar: (state a note that option of differt
- 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
- Broaden the term Web master -- use a long form at the top, and short word
- Address issue of how to certify that sites CONTINUE to meet the
- 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
- 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
- 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
- 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
- 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
- add concept of "legal" to "policy" without making "legal" only
- use general demographics but with pointers to resources on a
- WL: compiling factors affecting cost (currently seeking resources)
- KA: compiling linkset for additions to legal requirements & policy
- CV & HB: compiling info for Web design, for business 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
- JB: collecting implementation experience from several governments
- make it clearer that this is for helping people build their own business
- 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
- [Feasible in new format] enable dichotomy between profit-motive focus and
- [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
- Missing!!! growing expectation of rights/ expectations for accessible
- 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
- DONE Benefits include (for corp)
- direct access to broader market because of being able to sell to pwd
- indirect because of device independence
- situational independence...
- 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)
- 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....
- also benefits of efficiency/css/ updating/audio/indexing etc etc
- also decreased liability to lawsuits where requs exist
- and by the way makes your co look good//leadership
- suitability for multilingual translations
- 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...
- 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)
- 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
- 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
- be sure to clearly cite wcag and also to explain assurance of int'l
- 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
- 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
- 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
- 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
© 2000-2002 W3C (MIT, INRIA, Keio
), All Rights Reserved. W3C liability,
use and software
licensing rules apply. Your interactions with this site are in accordance
with our public