> EOWG Home Page > Building the
Case
Change Log: Developing a Web Accessibility Business Case for Your
Organization
A new changelog along with analysis for and development of the 2009 revisions is at www.w3.org/WAI/EO/changelogs/cl-bcase-update.
This page records change requests and changes made to the draft WAI
resource suite Presenting the Case for Web
Accessibility. Please send additions or corrections to wai-eo-editors@w3.org.
Last updated on $Date: 2012/08/01 20:32:46 $ by $Author: shawn $
NOTE: Change log for "Implementation Plan
for Web Accessibility" has moved to http://www.w3.org/WAI/EO/Drafts/impl/changelog
and changes to "Evaluating Web Sites for
Accessibility" are also now in that log.
on this page: about "business case"
resource suite | Review Notes | changes by date | wishlist
Audience
- Primary audience for this document is people who are
trying to "sell" accessibility to their organization, or get "buy-in"
from an organization to start a Web accessibility initiative, adopt a Web
accessibility policy, etc.
- Secondary audiences include reporters, trainers,
...
- All types of organizations, including commercial/industry, government,
education, non-profit, etc.
- Direct audience for this document could be varied,
such as technical Web developer, business analyst, outside accessibility
advocate, etc.
- The indirect audience is the people reading the
organization's customized "business case" which is often managers and
others who are responsible for allocating time and money resources to Web
projects.
Approach
Since each organization has different motivations, we cannot write one
master business case that will apply to everyone. Instead, this resource
suite is like a cafeteria where people can take what best applies to them and
create their own customized business case. As such, the content will
include:
- Direction on what might be relevant to a particular reader's
organization (e.g., if your organization XYZ, then ABC).
- Text that readers can cut and paste to use directly or with some
customization for their own "business case".
We will avoid overlap in information between this resource suite and other
WAI resources as well as between pages of this resource suite. This is a bit
tricky because several aspects of Web accessibility have benefits in more
than one area. For those cases, we will cover it in one page and link to that
page from the others, rather than repeating the information.
Review Notes as of 9 August 2005
Overview, Social Factors, Legal and Policy Factors, Financial Factors,
Technical Factors
status:
- all comments incorporated
- submitted for final EOWG review
Roll Out Notes
- @@ update site map
- @@ update resources
- @@ update & regenerate site navigation
- @@ home page highlight
- @@ notice to WAI IG
- @@ other promotion within or outside of W3C?
- @@ in http://www.w3.org/WAI/intro/accessibility.php change link from drafts to final location
[DONE] 15 August 2005
- all pages: in nav, changed "Business Case" to "Business Case: Overview" (per Call for Review comments)
- Social Factors: fixed typo ("The United Nations "Human Functioning and Disability" page
includes links to data for different contrives." to ... countries)
- Overview page: fixed spelling typo Enviroments > Environments
[DONE] 12 August 2005
- Overview & Social Factors: added aging as described in e-mail to EOWG list
- Overview & Social Factors: changed title "...Speakers of Other Languages" to "People Not Fluent in the Language" (in the text it is written out: "people who are not fluent in the language of the Web site")
[DONE] 11 August 2005
- all pages: typo corrections and minor copyedits, from thread starting at http://lists.w3.org/Archives/Public/w3c-wai-eo/2005JulSep/0072.html
- Technical Factors page, Be Prepared for Advanced Web Technologies, first bullet: to "Allow content re-use by using metadata and representing it using resource
description framework (RDF)." added ", such as is described in "<a href="/RDF/FAQ.html#What">What is RDF?</a>"" so it now reads:
"Allow content re-use by using metadata and representing it using resource description framework (RDF), such as is described in "What is RDF?". "
[DONE] 8-9 August 2005
- all pages: put in new design format, minor edits.
- Social Factors page: content edits to "Web Accessibility is a Social Issue" section
- Technical Factors page: deleted the following:
Location: Section "Reduce Site Development and Maintenance Time", 5th/last bullet.
Previous wording: "Reduce time and money spent in employee recruiting, training, and development by using technologies that many developers already know. (WCAG 1.0 Checkpoint 11.1, 3.2)"
FYI: 3.2 is "Create documents that validate to published formal grammars." and 11.1 is "Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported."
Rational: Web site developers don't necessarily knew W3C technologies more than many of the proprietary alternatives. For instance, it's more likely that they've been trained in Flash than in SVG. While it might be true, for example, to say that more Web site developers know HTML than Flash - this point is not strong/important enough to leave in.
- sub-pages changed titles to:
"Technical Factors in Developing a Web Accessibility Business Case for Your Organization"
(from: "Developing a Web Accessibility Business Case for Your Organization: Technical Factors")
[DONE] Additional changes made 12 April - 12 May 2004
- [DONE] Identifying [xyz] Factors for a Specific Organization in EACH
page: streamline so mostly just includes the explanation of question, to
provide conceptual support, but not get bogged down. as appropriate
change order to de-emphasize links to lower sections. - consise &
simple! OR the sentence itself is self contained (but then not need
explanation) - but icky uaag & atag faq
- Legal and Policy: significant re-org & tweaking. moved stuff
from under questions to new sections: "Determining Applicable
Policies" & "Understanding Risks for Non-Compliance" &
"Considerations for the Future" & "Considerations Beyond
Requirements"
- Financial: added section, "Decreasing costs" - from sentences
previously under "Cost Considerations"
- Technical: added section, "Have High Quality Web Sites"
- Social: added subheading. "Barriers to Web Use" and added examples
in first paragraph under "Barriers to Web Use"
- [DONE] added acknowledgements
- [DONE] integrated reviwers' comments, recorded in http://lists.w3.org/Archives/Public/wai-eo-editors/2004Apr/
- [DONE] Tech: changed "by defining presentation through a style sheet
and using proper HTML markup for structure" to " by defining presentation
through a style sheet and using proper markup for structure" since it can
be HTML or XHTML or XML
- [DONE] Overview, Introduction: edited first sentence and last
paragraph
- [DONE] change "Legal & Policy " to "Legal and Policy"
- [DONE, added short concluding paragraph to each] 3.
Social/Technical/Financial/Legal -- with the exception of the Legal page,
I find the sudden end of each document after its last bullet to be very
abrupt and - from a narrative standpoint - unsatisfying. Does anyone else
think that a short paragraph of summation, or a sentence conveying
"Well... now you have the w-factor building blocks for your business
case. If you haven't already done so, visit our x-factor, y-factor and
z-factor pages for more great stuff." would be of use? [from chuck]
- [DONE, changed it all to Web sites since that is the focus of this
document. added sentence to wishlist: "Accessible Web authoring tools,
browers, and other Web tools also have a role in Web accessibility." to
link to components when it is done]
term "Web product" [from Doyle]
On the Social Factors page in the paragraph titled; 'Role of
Organizations' Web Sites', I saw the use of the word, 'product', four
times. I believe that the word Assets better suits the usage to which
Products in the first two instances appears. In the third instance of the
word Products I found the word, Resources, appropriate. And I would leave
the fourth product alone.
That paragraph would then read: "When an organization's Web ASSETS (Web
site, authoring tool, etc.) are not accessible, they further exclude
people with disabilities from society. When an organization's Web ASSETS
are accessible, they empower people with disabilities to participate in
society. Providing accessible Web RESOURCES can directly increase Web
product usage,.."
- [DONE, removed "production and distribution" left "translating" since
have "-ing" in others] financial:
current: "Decreases cost of alternative format materials production and
distribution" & "Decreases cost of translating"
what about: "Decreases Costs of Translations" [from libby] "Decreases
costs for producing and distributing alternative format materials"
- [DONE] Technical: added the following explanations:
- Reduce site-wide presentation change time and
effort by defining presentation through a style sheet and
using proper markup (HTML, XHTML, etc.) for structure. (WCAG 1.0
Checkpoint 3.1, 3.3, 3.5, 3.6, 3.7, 5.4)
Presentation includes design and style such as font size, font face,
and background color. If the presentation is defined in an external
style sheet, it can be changed throughout the site by making the
change to that one style sheet. However, if the presentation was
improperly defined throughout the HTML, the presentation markup would
have to be changed in every instance on every Web page.
- Reduce redesign and translation time and
skills needed by using standard markup language and style
sheets to style and format text, instead of using bitmap images of
text or math. (WCAG 1.0 Checkpoint 3.1)
Site designers often use bitmap images for stylized text. In such
cases, to change or translate text content or style, each image has
to be manipulated. If instead the text was not in an image and the
style was provided in a style sheet, then the text can be changed or
translated without touching the image, and likewise the style can be
changed in the style sheet.
- [DONE] Technical: cleaned up the @@s
- [DONE] Financial: cleaned up the @@s
- [DONE, added reference at end] referencing WCAG Checkpoints (and w3c
technologies in technical). - link all (too distracting), link just the
number (not sufficinet?), reference at end...
- [DONE] added a subheading "Overlap with Digital Divide Issues" and a
paragraph at the endof that section to tie it in
[DONE] Changes from 2 April 2004
- [DONE] remove references page
- [DONE] change title to Developing a Web Accessibility Business Case for
Your Organization: ...
[DONE] Overview
- [DONE] Developing a customized Business Case
- [DONE] fix awkward wording ... quality phrase awkward ... perhaps
conformance to technical standards...
- [DONE] Consider Sailesh's comment about "interest" and "emphasis "
"Some organizations might be more interested in the economic factors,
others in the legal factors, and others the social impact of Web
accessibility"
- [DONE] Example Emphasis for Different Environments
- [DONE] Web development: clarify first point: "skill necessary to
understand & implement accessible Web sites" competive
advantage
- [DONE] move table of contents to separate page
[DONE] Additional changes made 1 April 2004
Changes requested 26 January
2004
- [DONE] Identifying [xyz] Factors for a Specific Organization in EACH
page: streamline so mostly just includes the explanation of question, to
provide conceptual support, but not get bogged down. as appropriate
change order to de-emphasize links to lower sections.
- [DONE, send msg to Eo-Editors] add Stds Harm discussion to "developing
a policy" suit
- [DONE] editors discretion to examine discussion of CSR in Social so
more on action, not on appearance - and also not financial factors
- [DONE] slh to redraft "addressing multiple Stds" in legal to remove
'opinions' - use jb's notes
- [DONE] ideas for heading change: identifying, question to ask...
- [DONE] remove "related resources" section - see how it looks
- [DONE] edits from Judy listed at http://lists.w3.org/Archives/Public/wai-eo-editors/2004Mar/0029.html
[DONE] Social Factors
- [DONE] General question on Checkpoint listings: Are
the ones that are listed good ones to list? Should others be listed? For
example, in "Access for People with Low Bandwidth Connections to the
Internet and Older Technologies" section should there be any for image
maps?
- [DONE] Not list all screen reader related checkpoints:
In the "Web Accessibility Benefits People with and without Disabilities"
section we list the relevant WCAG 1.0 checkpoints. The last paragraph
under, "Access for People with Low Literacy and Speakers of Other
Languages" says something like, "In addition, accessible sites can be
read and navigated by screen readers (for people who are blind) and
people who cannot read can benefit from listening to sites." [might have
been edited since] Because the list of relevant WCAG checkpoints is so
very long (WCAG 1.0 Checkpoint 1.1, 1.2, 1.3, 1.4, 1.5, 2.1, 3.1, 3.5,
3.6, 3.7, 4.1, 4.2, 4.3, 5.1, 5.2, 5.3, 5.4, 5.5, 5.6, 6.1, ... and
several more), editor suggests not listing them here. Thoughts?
- [DONE] Not list checkpoints that have "until user agents"
clause that many in WCAG WG consider deprecated: In the "Access
for People with Low Bandwidth Connections to the Internet and Older
Technologies" section, only list those checkpoints which are still valid
with modern browsers as well, not the checkpoints that have "until user
agent" clause and are considered deprecated by many. Thoughts?
[DONE] Legal and Policy Factors
- [DONE] Repetition between main sections:
The "Considerations for Different Types of Organizations" section seems
too repetitive with the questions in the first section.
- Should the information be separated differently
between the sections? Should more or less be repeated in both
sections?
- Should the first question "Is Web accessibility
required for this type of organization?" include all the information
from the bottom section ("Considerations for Different Types of
Organizations") (and the question "Are there other Web accessibility
policies the organization should comply with?" -- note that the total
would be much shorter becase there is a lot of repetition between the
first question and the bottom section, as well as within the
subsections at the bottom.
- Or is it OK as is?
- [DONE] Do any government policies require non-government sites
be accessible?
Is this statement true: "Some government policies require
industry and non-governmental organization (NGO) Web sites to be
accessible. "
- [DONE] Please review carefully the new section:
Addressing
Multiple Standards or Guidelines
[DONE] Additional changes made 13-24 March 2004
[DONE] Changes requested 1 March 2004
[DONE] All pages
- [DONE] consistent page format of intro; customizing for a specific
organization; sample text; additional resources
[DONE] Overview
- [DONE] add "abstract" before intro & fill w/ last two paragraphs of
intro text
- [DONE] SLH: add an overall, detailed contents list
- [DONE, did not integrate full list because to be inclusive would be too
long, did add a few examples] consider integrating overall WHY:
- its best practices --- [technical]
- because its international [technical]
- because we don't want to be behind our competitors [financial
including corporation]
- because of the broad international involvement & consensus
building
- reference the standards harmonization document [Legal and Policy
]
[DONE] Social page
- [DONE] try adding these questions:
- Is this organization interested in enhancing its image with regard
to social responsibility?
- Does the organization already have a corporate social
responsibility statement or program?
- Which avenues of maximizing the benefits of Web accessibility as
CSR are most relevant to the organization?
- Is your organization obligated by some CSR policy?
- [deferred to "myths"] have a section that lists the common challenging
questions, e.g.:
- Why address Web accessibility if it only affects a small number of
people?
- But our audience doesn't include people with disabilities.
(Handicapped people don't come here anyway!)
[DONE] Financial page
- [DONE] try adding these questions
- How much will it cost to make my Web site accessible?
- What is the return on investment if we make it accessible?
- What are the advantages of up-front accessible design vs
retrofitting?
- What would be the costs if you get sued for non-compliance?
- How can I minimize the cost of making my site accessible?
[DONE] Technical page
- [DONE] see if want to add something about quality
- try adding these questions:
- would your management like to improve its...?
- would these issues resonate with your management...? [improving
quality]
- are you interested in future-compatibility of your technology?
- see where to add consistency, corporate image, quality, etc.
[DONE] Legal and Policy page
- [DONE] try adding these questions:
- are there any possibilities under development?
- are you looking at other markets where this might be an issue?
- are there professional, trade association, or standards
organizations standards
- [done] judy: For general discussion of demographics in
"Presenting the Case...", explain difficulty of obtaining consistent
disability demographics internationally across different regions, then
provide links to examples of specific kinds of regional research,
including Microsoft's
Forrester report (check intended persistence of this link)
[done slh] Changes requested 30
January 2004
- [DONE] try to smooth out this sentence "Many people with disabilities
are impacted by several aspects of the digital divide related to Web
use."
- [DONE] if leave the sentence in, change it to: In addition, since the
benefits of accessible design also extend to other groups affected by
these and other limiting situations, Web accessibility also supports
improved access and social inclusion for many other groups,
including:
- [DONE] consider changing: "While the main focus of Web accessibility is
people with disabilities, accessibility also benefits people without
disabilities, including those in groups disadvantaged by the digital
divide." with to "While the main focus of Web accessibility is people
with disabilities, accessibility also benefits people without
disabilities whether or not they are affected ?? impacted ?? by the
digital divide." make sure here or elsewhere covers situational
limitations
- [DONE] continue to look carefully at how we are using the term digital
divide. also, read the link harvey sent. (note: jon, helle, natasha (last
week) said that 'digital divide' works very well in their countries and
those they know of)
- [DONE] judy: take a stab at
integrating some ideas from sailesh's 22 Jan email, subject: "Social
Factors page", archived at:
http://lists.w3.org/Archives/Public/w3c-wai-eo/2004JanMar/0033.html
- [DONE] incorporate ideas from sailesh's 23 Jan email, subject: "Re:
bcase-social factors for 23 January 2004 teleconference", archived at:
http://lists.w3.org/Archives/Public/w3c-wai-eo/2004JanMar/0040.html,
...
- [DONE] look at how financial factors refers to CSR and social
factors
- [DONE] incorporate new category: # New users / Casual users (don't
understand things like new/multiple windows and non-underlined [unclear]
links). add temporary disabilities, probably with PWDs, but maybe a
separate category. (charmane
draftedl)
- [DONE] charmane's edits archived at
http://lists.w3.org/Archives/Public/w3c-wai-eo/2004JanMar/0056.html
[DONE] Changes requested 9 January
2004
- [DONE] Change "Web Accessibility is a Requirement for Equal
Opportunity" to "Web Accessibility is Essential for Equal
Opportunity"
- [DONE] Under "Barriers to Web Use" trim down or maybe totally out P1
& P2 (except maybe leave link to How PWD Use Web) - make sure
adequately covered on overview page. [decided not appropriate for
overview page] possibly tweak P3 & P4 down a bit [deleted" While
international guidelines define Web accessibility for Web content (that
is, what is on a Web page), Web "user agents" (including Web browsers,
multimedia players, and software that people with disabilities use to
access the Web), and authoring tools (software used to develop Web pages)
[x - links to guidelines info], the guidelines are not well implemented.
" & "How People with Disability
Use the Web illustrates some of the requirements of people with
disabilities when using Web sites and Web-based applications, and
includes scenarios of people with disabilities using accessibility
features of Web sites and Web-based applications with some types of
assistive technologies and adaptive strategies used by some people with
disabilities when accessing the Web."]
- [DONE] Look at whether to leave link to How PWD Use Web here or on
intro
- [DONE] CSR more directly addresses audience, do same thing in previous
section, e.g., does your country do digital divide? Think about if there
are any questions about the organization type and how that would impact
how they incorporate social factors into business case. (but becareful
not to overlap too much with introduction) [this is actually integrated
into the CSR section, "Does the organization already have a corporate
social responsibility statement or program?... If no,...]
- [DONE] For "other groups" section, do something in between March 2003
with detailed examples and the previous version's small bulleted list
- [DONE] Intro, last P: "In presenting a case for Web accessibility for a
specific organization, the following social factors can be customized
based on how they apply to the organization's situation." social factors
can't be customized - maybe the following SF can be applied according to
the organization's situation. [changed to: In developing a case for Web
accessibility for a specific organization, the following social factors
can be presented based on how they apply to the organization's
situation.]
- [DONE] Intro: tweak examples, add: 1. org made goal to demonstrate
social leadership, then the others...
- [DONE] "The Web is an opportunity for unprecedented access to
information for people with disabilities." maybe weave barriers IF can do
it briefly - mention functional problem (maybe w/o disability), e.g.,
lifting journal, hearing... this is a side point to this section which is
an initial statement of need... [add, ", including getting to the
library, physically getting the resource, and reading the resource" - but
don't really like it]
- [DONE] "Additionally, providing Web information that is accessible to
people with all different types of disabilities is much easier and less
expensive then developing and distributing multiple alternative formats
(such as large print, Braille, audio)." maybe don't need here 'cause
financial factor -- maybe the point is it's more practical... Therefore,
people with disabilities, as well as organizations, can have more
effective and efficient communications and interactions through
accessible Web sites - in some cases where there was essentially no
access before. "digital media is eminently suitable for
accessibility".
- [DONE] fix wordo: "it becomes exponentially users for many people"
- [DONE] "Web Accessibility is a Social Issue" is statement of need.
maybe third paragraph integrate with first paragraph. maybe emphasis
employment/job notion. "People with disabilities can actively participate
and provide content for the Web." - maybe add discussion forums &
stuff. when move to the top, don't lose it, make sure it still has
emphasis
- [DONE] Scope section: maybe move "Millions of people have disabilities
that impact their Web use." to the beginning of that section. make the
list non-bulletted & move with/after pwd. (be careful to keep the
focus on the social factors aspect, and not the additional benefits)
- [DONE] change "myriad" to "many"
- [DONE] Change "media" to "medium"
- [DONE] format: not so long stretches of bolding [removed bolding from
"Barriers to Web Use" section. [left bolding of first sentence of
paragraphs in "Web Accessibility is Essential for Equal Opportunity"
sectoin. OK?]
all pages
- [DONE] look at actively helping people build a business case, e.g.,
what questions you should ask (and how their answers impact what they
do)
[DONE] Changes made 7 January
2004
- [DONE] significantly rewriting to try to focus on business case aspects
of social factors
[DONE] Changes from 7 November 2003
discussion
- [DONE 18 Nov slh] change heading "audience reach" to just
"audience"...
- [DONE 18 Nov slh] change "building the case..." to "presenting the
case..."
- [DONE 2 Dec slh] in intro section: edit "An organization's efforts to
make its Web site accessible can impact profitability and return on
investment." - make broader statement of benefit. maybe change
"profitability" to "cost efficiencies", & put after "return on
investment"
- [DONE 2 Dec slh] in intro section: consider changing different,
different, different
- [DONE 2 Dec slh] in intro section: look at munging the redundancy in
first two paragraphs
- [DONE 2 Dec slh] in intro section: "for example, costs are often lower
when building or redesigning a new site rather than when fixing an
existing site" clarify difference between redesigning & fixing. [took
out redesigning] also, clarify comparison statement & claim. [don't
know what this is :-(]
- [DONE 2 Dec slh] reexamine heading levels, can make flatter? try
changing the H4s to paragraphs like below [changed "Increases Audience
Reach" & "Increases Effectiveness" into <p> sentences. left
"Quantifying Benefits" <h4> since it's a separate thing]
- [DONE 2 Dec slh] "Many of the aspects of Web accessibility discussed in
Technical Factors provide direct cost savings" make it clearer that they
should go to the Technical Factors page to get supporting info [added
"which are": Many of the aspects of Web accessibility which are discussed
in Technical Factors... to
be more explicit seemed awkward and really interrupted the flow]
- [DONE 2 Dec slh] "Many of the aspects of Web accessibility discussed in
Technical Factors provide direct cost savings" add "can" in this sentence
and maybe qualify can in list items, too
- [DONE 2 Dec slh] qualifiers - not just 'can' - what about "Decreases
human resource costs for maintaining the site by reducing site
maintenance in the longer term" [changed to "when accessibility reduces
site maintenance long term" (tried "when site maintenance is reduced" but
that's passive, like '"when you reduce site maintenance" but don't think
we want to use "you"), etc.]
- [DONE 2 Dec slh] try changing "human resources" to "personel"
[DONE] Changes from 24 October 2003
discussion
- [DONE, slh, 5 Nov] incorporate introductory text from Sailesh's draft -
make claer this page not all factors, just financial impacts of other
factors
- [cancelled, per 5 March meeting] sailesh & natasha: add section on
stastics & measurement. see Sailesh's draft. frame for organizations
interested in doing statistical measures, here are some things for you to
consider
- [DONE, slh, 5 Nov] make easier to scan. perhaps bring bolded text
forward as paragraph intros, section headers, DT in Dl list. make text
stand-alone, e.g., increase the findability, increase the usability
bold.
- [DONE, slh, 5 Nov] take "Presenting the Case for Web Accessibility:"
out of links to other pages in the suite.
- [DONE, slh, 5 Nov] Put Increased Site Use before Direct Cost
Savings.
- [DONE, slh, 5 Nov] Maybe note that faster loading pages increases
usability.
- [DONE, slh, 5 Nov] Try to break " Increased Site Use" into two
sections: 1. Increased Audience Reach (& say "market share" in text
maybe), 2. Increased Effectiveness or Effective Usage or some such.
Examine for redundancy & add more explicit tie-in to usability w/o
tying everything to usability.
- [DONE, slh, 5 Nov] Changes based on feedback sent to EOWG list (archived)
[DONE] Changes from 24 September
2003 discussion
- [DONE, slh] Major rewrite of main text & some minor clean up,
summarized below
- [DONE, slh] Changed order of items in the navigation section to social,
technical, economic, policy
- [DONE, slh] Changed <H1> and <title> to Presenting the Case
for Web Accessibility: Financial Factors
- [DONE, slh] Reorganized "Investment Considerations" from main bullets
"initial investment, impact on Web site development process, impact on
Web site functioning" & rewrote content
- [DONE, slh] Changed "Economic Benefits" to "Financial Benefits" and
reorganized & rewrote content underneath new headings "Increased Site
Use" and "Direct Cost Savings"
- [DONE, slh] Highlighted in econ-old.html some info not incorporated
[DONE] Changes from 19 September
2003 discussion
- [DONE, slh, 24-sept] Compile Building Blocks for Business Case section:
new first sentence, "Once the interests of the organization have been
identfied, this resources can be used to compile a [@@ suitable?
appropriate? nothing?] business case..." [editor note: tried to
minimize passive voice, and match style of intro sentence in previous
section, and meet main point of this edit request, which was to tie in
better with previous section. Original sentence: "Compile information
from the pages of this resource suite that meets the organization's
interests:" First sentence of previous section is imperative voice:
"Start by..." So revised this sentence to: "Based on the key interests
and motivations of the organization, complie the relevant information
from the pages of this resource suite:"]
- [DONE, slh, 24-sept] Fourth group in Sample Outlines of Business Cases
for Different Environments section: reformat so there is not 3 levels of
bullets
- [DONE, slh, 24-sept] Change "elements" to "buidling blocks" &
"oulines" to "sample outlines"
- [DONE, slh, march] Find a better way to represent or lead into the
other pages of the suite (here & throughout suite)
- [DONE, slh, 24-sept] Take "business case" out of headings "Compile
Building Blocks for Business Case" and "Sample Outlines of Business Cases
for Different Environments"
- [DONE, slh, 24-sept] In the bullets under "Sample Outlines of Business
Cases for Different Environments" consider changing "business case" -
maybe change the intro sentence to "Making a case for:" and then start
the bullets with the entity
- [DONE, slh, 24-sept] Clean up related documents resource link
titles
- [DONE, slh, 22-sept] Change order of items in the navigation section to
social, technical, economic, policy
- [DONE, slh, 22-sept] Change the first line in the suite nav "Presenting
the Case: Overview"
Throughout entire suite
- [DONE, slh, 25-sept] Change order of items in the navigation section to
social, technical, economic, policy
- [DONE, slh, 22-sept] Change the first line in the suite nav "Presenting
the Case: Overview"
- [DONE, slh, 22-sept] Change H1 & title to "Presenting the Case for
Web Accessibility: XYZ"
- [DONE, slh, march] Consider options for referencing the other pages in
the suite
- [on-going] Use of "business case" - try not in headings, with
discretion throughout text
[DONE] Changes made 18 September
2003
- Reviewed "Overview" and "Entire Suite" change requests dated 3 March 2003
- Reviewed "Overview" and "Entire Suite" change requests dated 28 March 2003
- [DONE] Changed title from "Building the Case for Web Accessibility" to
"Presenting the Case for Web Accessibility: Overview"
- [DONE] Removed "the information in this suite may be used... in keeping
with..." for now, since it contradicts the status note above.
- [DONE] Shortened and simplified the introduction -- by making more
concise, and by breaking out some new section-headers.
- [DONE] Broke up many of the big chunks of text into short lists of
examples.
- [DONE] Added a related resources section.
- [DONE] Integrated material from "How to use this resource" into whole
page.
- [DONE] Changed note about business case for authoring tool
accessibility into resource listing.
- [DONE] Changed "Considerations for Different Environments" to "Sample
Outlines for ..."
- [DONE] Broke down sample outlines into sample outlines.
- [DONE] Added in a reference to the implementation plan, for
accompanying information.
Changes from 1 August 2003
discussion
- add transition at beginning of paragraph that introduces digital
divide. perhaps something that discusses the relationship between social
responsibility and digital divide. perhaps idea that social
responsibility is more corporate [?] and digital divide is more ICT...
&/or that this is a hot topic / developing trend
- move most of it out of "Introduction" and into "Social Responsibility
and the Digital Divide" and something like "?Overlapping Impacts...?"
- make one sentence into two sentences: "For instance, in many countries
people with disabilities have among the lowest rates of employment of any
sector in society. Consequently may have less access to high bandwidth
connections, newer technologies, or computer literacy training; or less
ability to buy the latest upgrades of assistive technologies that might
give them increased ability to use the Web."
- perhaps address the technical barriers and social barriers - perhaps
link to How People with Disabilities Use the Web to help combat the
social prejudices and stereotypes related to social factors ?
- perhaps re-structure the document around the issues of social factors
and access to technology, that organizations might be interested in for
their case (not structured around the specific groups)
Changes from 16 July 2003
discussion
- @@ [done?] added in concept of digital divide, tangible, leadership
- [done] paragraph starting with "Many organizations...": fewer words,
bullet the items
- [done] two paragraphs start out with "This document..." - munge
them
- [removed] change "wish" to "want" (slh suggestion not verbalized in
mtg)
- [term clarified initially & then "social factors" generally used]
get away from just "social responsibility" (william's & doyle's
comments on broader "social factors") - maybe document/page title is
social factors and social responsibility is just one point
- [done] add/move umbrella info at/to the beginning. (e.g., "In many
countries, use of the Web already pervades many areas of daily life,
including access to government information and services, educational
opportunity, commerce, and entertainment." which is under PWDs section,
applies across all sections and therefore should be up at the top
level)
- [done] perhaps better definition of "social responsibility" (Natasha
shared http://www.hp.com/e-inclusion/en/index.html)
- [clarified, and added variants] Pierre on translation: "social
responsibility" not translate, perhaps "citizen..." (jb: civic
participation)
- link to How People with Disabilites Use the Web
- refilter for read and write ability (PWDs not just receive content, but
develop content) - promoting interactivity, not just passive reading
- perhaps add idea of "leadership"
- separate internal from external, public vs. employee. also make sure to
cover the idea that many people in your potential audience could have
disabilities - public, employees, vendors, collaborating
organization...
- perhaps add "digital divide" term
- "make it tangible" (perhaps ask Michael for specifics)
- In umbrella, mention overlap with economic, auxillary benefits is
beyond PWDs.
- Perhaps explain in PWD section why there is not a segment giving
specific disabilities and statistics.
- number of people: need to add temporary disablities, family members,
etc....
Other areas
- technical factors - need to look at translatability...
Change requests from 16 May 2003
- overall level:
- check H2 capitalization; set a policy
- legal and policy factors:
- "Some governments may not have laws specific to Web accessibility.
Nevertheless, they may have applicable regulations, directives, or
other requirements based on laws and policies such as
anti-discrimination legislation or information technology policy."
change to "Some governments have laws specific to Web accessibility.
Other governments have applicable regulations, directives, or other
requirements based on laws and policies such as anti-discrimination
legislation or information technology policy." -- editor should also
try to get this into more of an and/or mode.
- Try a version keeping the bold on the questions, but running the
detail into the same bullets as the questions.
- Add "rather" before "than" in last question.
- "educational institutions and organizations," "and publishers"
- fix jigteam link on "technical resources"
- current --> currently
- change "Resources related to building a case for Web accessibility"
to "Other topics within this suite"
- technical factors:
- [done aa] fix div at top
- [done aa] align the document title
- [done aa] status section needs note class
- [done aa] correct the in-page navigation
- [done aa} replace the intro w/ a parallel into to legal/policy
- [done aa] generalize in the subsections within body of document and
put the additional detail at the bottom (help to reduce redundancy
between subsections)
- [done aa] [CC, HS] try re-writing "reduce site maintenance" with
1/2 as many words and with more direct statement of technical benefit
and less detail on the statement of the checkpoint -- [CLT, CC, HS,
AA, BM will debate]
- economic & social:
- previous change requests as noted
- also the consistency change requests from the technical factors
document
- overall comments:
- still discuss qu of bottom nav for suite and/or related
resources
Additional changes 15 May 2003
- [jb] shortened intro to policy question section
- [jb] copy-edited "considerations for different types of organizations"
section for conciseness and clarity.
Change requests from 2 May 2003
On Legal and Policy page
http://www.w3.org/WAI/EO/Drafts/bcase/pol.html
- [done/jb -- incorporated re-edited version of charmane's
comments] CHARMANE: in questions section, sentence still need to be
crisper
- [done/jb] in questions/Policy section, first sub bullet - clean up "at
at" (notes in minutes)
- [done/jb] update the in-page navigation to match the new headings
(questions -> policies). consider other options for separating the
sections in the in-page nav. remove H3s in in-page nav
- [done/jb] change "Considerations for Specific Envrionments" section
heading to "Considerations for Different Types of Organizations"
- [done/jb] EOWG: relook at Additional Resources - maybe change
"Additional Resources" heading to "Relate Resources" "Other
Resources" "Finding related infomration" "How to find related
information" ? perhaps also include search engine tips - in thsi
section at the end of the page, or at the end of each organzation section
?
Additional changes 1 May 2003
- [done] incorporate Libby's edits sent to wai-eo-editors list http://lists.w3.org/Archives/Public/wai-eo-editors/2003Apr/0009.html
- [done] add "and organizations" after "educational institutions" (2
places in document)
- [done] change "distance learning" to "online learning"
- [done] change "and refers to government requirements" to "and refers to
government or other official requirements"
- [done] marked up the page nav bar a bit differently
- [done] added in an experimental "additional resources" link farm at
bottom of page
Change requests from 25 April
2003
On Legal and Policy page
http://www.w3.org/WAI/EO/Drafts/bcase/pol.html
Throughout entire suite
Change requests from 28 March
2003
Throughout entire suite
- [DONE, slh] fix [business] case throughout, including all page
headings, suite navigation title, title of pages
- change marketing tone, e.g., take out qualifiers, adverbs
- change "- assembling a business case" to match the
subheading in doc body
- move "how to use this resourse suite" up to after intro, move some info
from intro into that section
- consider limiting the intro to just what this document is
- [rewritten] look at reorganizaing paragraph starting: "In order to
assess audience growth it is imperative to have auditable
“current” traffic statistics..." lower
- [rewritten] under "Audience expansion - many aspects
of Web accessibility are about increasing the general usability of a Web
site such as: " move "Improving the access for all people is likely to
have an impact on the way a Web site attracts visitors. " to the first
item under bullet
- consider design to add more whitespace (possibly inpage style to
add space before &/or after list items)
- [rewritten] [clarification 20030411 -- editor's discretion -- try to
keep something on this, but make it less absolute] "Employee
retention - accomodating employees with disabilities is cheaper
than replacing them - consider " - sometimes not, sometimes, yes
- [rewritten] clean up wording so that it doesn't look like we're going
to have examples
Change requests from 3 March
2003
- In introduction, scope section, clarify that this is about
accessibility of Web sites - mention other UAAG, ATAG, "Selecting and
Using Authoring Tools for Web Accessibility" and AT Business Case [that
Carlos is working on]
- Experiment with different ways of including different links to the AT
Business Case, perhaps including another section in the overview page
- Look at other AT Business Case to see how it fits in, and they fit
together
- [DONE] Change title to "Building the Case for Web Accessibility" and in
the overview page make sure to use the term "business case"
- Add all the other terms in meta data keywords: business case, how to
sell Web accessibility, convincing, etc....
- [DONE] Change suite navigation from "Business Case Suite" to "Business
Case resource suite"
Introduction section
- DONE first paragraph:
try flipping wording, inverting to lead with the Web being a core
technology. jb, "see if can also build in the serving part of the
business case there"
- DONE second paragraph:
remove the "but" and consider changing "clearer" to "clear" and "some" to
"many"
Considerations for Different Environments section
- add "would facilitate inclusion of more" idea
- DONE add faculity & staff (in addition to students)
Assembling a Business Case section:
- Change section title to "How to use these materials in a business case"
[DONE slh suggests considering "How to use this resource suite"]
- add idea that this could be part of a large doc, or you can use just a
small part of it; that it could be formal or informal; that you might
want ot gather a team to work on development of a business case
- perhaps add a list of questions to ask
In entire suite
- Throughout all pages, look for appropriate places to link to other
documents - UAAG, ATAG, "Selecting and Using Authoring Tools
for Web Accessibility" and AT Business Case
- DONE Change from "Policy Factors" to "Legal and Policy Factors" in
suite navigation
- Check to see what's missing in the new draft, that is, what info we had
before in Aux Benefits that is not in latest draft
- Keep the main page information as concise as feasible, move details
that explain separately - start with it at the bottom section of each
page (like footnotes), possibly will go on separate page
- Consider if we need to have all these separate sections... are there
different policy considerations?
- Change title from "Policy Factors" to "Legal and Policy Factors"
- Add obligations (under the law) to make workplace accessible
- Change "Corporations" to "Businesses"
- Change "industry/ professional associations" to "associations" -
include industry, professional, academic, trade, etc. in first sentence
text
- Rearrange list, perhaps: government, business, education, ngo,
associations [check with jb]
- In first paragraph under NGO, explain that NGO includes not-for-profit
and non-profit
- DONE Consider if employee retention for employees with disabilities,
especially employee without disability gets temporary or permanent
disability
- DONE Change "semantic Web integration" to something like "helps set the
foundation for advanced Web development"
- DONE Clarify the economic benefit of "semantic Web integration" -
some possible terms: ...interoperability... multipurposing of
content...syndication....
- DONE Bold the phrases - e.g., under "initial investment," the phrases
at the beginning of the bullets before the dash - to facilitate
skimming
- DONE Change from "Costs" to "Potential Investment Considerations"
- DONE Consider marketing perspective - is cost list too overwhelming
over benefits list?
- DONE Look at reorganizing - e.g., developer time and a few others
should go in other section
- DONE Remove contingency and misc. item - add those considerations
elsewhere they belong
- DONE Munge Benefits section & ROI section into one, with heading to
"Economic Benefits" (and leave it as first section)
- DONE Include "ROI" "return on investment" etc. in intro paragraph text
& matadata
- Move train co... [@@ Andrew took written notes, didn't get details in
chagne log]
- DONE In in-page nav:
To "employees" add "with disabilities"
To "bandwidth" add "low bandwidth"
others?
- DONE Change "legacy technology" to "older technology"
- DONE Change from being guideline-centeric to more people-centric
throughout, e.g., under PWD section, reorder wording and <strong>
the phrases about the people - order: problem/need, benefit, then
solution is to adopt the guidelines (like in access for Older People)...
at Low Literacy section, we go into the specifics of the guidelines...
consider more consistent/parrallel structure... consider putting the the
basic intro (e.g., the list of the items) at the top, and then put the
details at the bottom.... also might be able to eliminate some
redudancy
- DONE Consider changing "Access for..." to Access by..."
Access for People with Disabilites section
- DONE Try generalizing this section a little more so it's not dependent
on WCAG
- Consider linking to How PWDs Use the Web
- DONE Consider beefing up Access for People with Disabilities section -
about don't exclude 'cause Web is key role in participation in life...
and there are also advocates that might pursue... [jb had ideas for this
section]
Access for Employee with Disabilites section
- DONE [mentioned in Economic doc instead] Add idea of retaining
(limiting attrition) & recruiting employees!
- Consider if we need to mention AT here
Access for Older People section
- DONE Think about an intro sentence that is not questionable about if it
is true universally - e.g., Increasingly more older people are using the
Internet... in some cases, faster growing # of aging
- DONE Think about rewording to not use the term "disability": Sometimes
when people are aging... people get changes in XYZ... and that is
actually a very important group not to use disability with!
- DONE Delete the word "deterioration"
- Make list inclusive, e.g., add hearing
- Use "cognitive or neurological"
- DONE Delete the first sentence
- DONE Remove "Unfortunately"
- DONE Point to How PWD Use the Web for details
Access for... Language section
- Add primary language markup
- Consider non-native... and alternative to "speakers"
- Action item: check with internationalization gurus on how to word
this
- Generalize in the subsections at the top and put the additional detail
at the bottom - help to reduce redundancy between subsections
- DONE Consider if need to break up bullets, separate points into
multiple bullets, or separate sub-points with line breaks within a
bullet
- DONE Consider adding emphasis with STRONG for key intro phrases
throughout
- DONE Change "repurposing of content" to something like "work for
different devices" that's more lay-person's terms rather than jargon
Change requests from 1 November 2002
- Comments on http://www.w3.org/WAI/EO/Drafts/bcase/
- change title to "Customizing a Business Case for Web
Accessibility"
- policy (Legal and Policy requirements in different settings)
- economic (cost factors including expense & revenue, clearly
include market share considerations but linked to detail in social
factors sections)
- social (social factors, including demographics, literacy)
- technological (page transmission, device independence)
- save all the content but eliminate redundancies by cross-linking
- eventually build a multiple-choice business case template
- people also willing to help: AA, AG, BM, JB
Change requests from 9 August 2002
- Comments on July
29, 2002 draft of auxiliary benefits document
- Change header from "increase market share and audience outreach" to
"expand audience" but then include reference to market share in the
narrative;
- Use the term "resource suite" instead of "suite.
- Change "size and breadth of audience" to "size and diversity of
audience."
- Comments on top level of suite
- Put a definition of business case in top level of suite.
- Explain what is meant by resource suite up front in the
document.
- Complete the resource suite before checking the document again for
translatability.
- Continue to use business concepts in the document, but explain them
as you go.
Change requests from 24 March 2002
- Comments on whole suite
- marketplace: add caution about assumptions checking, and link to
caution in scope section in policy document
- repackage content according to ...? ] four motivators// don't split
original document until testing draft re-organization
- give people hints for different context? or very short business
scenarios? use some little scenarios for business cases -- business
case examples that highlight the un-obvious//scenarios
- roll the increase marketshare into demographics
- roll the legal into policy
- set up the cost factors so that it more logically links to the
organization of the rest of the suite
- sections:
- 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)
- scenarios:
- 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 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.
- Comments on business benefits
- make sure all points are bullet proof (NL, LC, HB, CL, CV)
- link to substantiation where possible (LC, AA)
- note in document that it is not an exhaustive list
- name, in the introduction, the other resources that will be part of
the business case resource suite (AA)
- get moving on the demographics piece:: JB will start with a
fill-in-the-blanks piece; EOWG will help fill in the blanks.
- do a first pass through the document again before doing any survey
(JB follow up again w/ KB)
- if we do encourage the survey, have it reviewed for methodology
(CV, later)
- once we think that the next draft is ready for feedback, do the
survey ourselves
- try trimming the document -- jb send to gv (AA + JB)
- try adding an exec summary -- that prioritizes (AA)
- 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
- Comments on supposedly "done" draft of business benefits
- still some missing titles on checkpoint links in linear version of
table (HB & KA will send details)
- change skip table link to link to lineared version
- add link to linearized version after benefits matric in TOC
- check space between links
- check relative vs absolute size & positioning & add inline
comment to explain usage
- Comments on Evaluating Web
Sites for Accessibility
- DONE add "...and changed pages" after ongoing monitoring in conf
eval"
- [UNDONE - unable to clarify] run at least HTML validation service
or HTML Tide (clarify coverage of XHTML)
- DONE add WAI nav bar to upper right of eval page
- evaluate the page
- in the review request, mention:
- ask people comment on how info is displayed
- and on any redundancies at given levels
- and invite translations.
- 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.
- 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
- 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...
- 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
- 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 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
- 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.
- 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
- 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)
- 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.
- 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
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.
- 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"
- 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
- 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
- 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 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
- 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
- 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
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
- 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
- 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)
- 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...
- 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
- Link to table of contents - draft at
http://www.w3.org/WAI/EO/Drafts/bcase/toc.html
- Have resource covering "myths" that relate dto business case that can
link to -- common challenging questions, e.g.:
- Why address Web accessibility if it only affects a small number of
people?
- But our audience doesn't include people with disabilities.
(Handicapped people don't come here anyway!)
- Perhaps add section about the isses (problems) surrounding
- Social Factors, Role of Organizations' Web Sites:
consider adding "Accessible Web authoring tools, browsers, and other Web
tools also have a role in Web accessibility." when have Components to
link to
- Social Factors, Barriers to Web Use:
"Currently there are significant barriers on the Web for many
people with disabilities. Because most Web developers do not make their
Web software and Web pages accessible, many people with disabilities have
unnecessary difficulties using the Web, and in some cases, cannot
effectively use the Web at all." [@@need for example here? wish
had doc to point to!!!] "However, if Web sites were made
accessible, people with disabilities could effectively use the Web. (How People with Disability Use the
Web includes scenarios that illustrate some requirements of people
with disabilities when using the Web.)"
- Legal and Policy Factors, Are the requirements adequate to meet
the needs of people with disabilities?:
"Required guidelines or minimum conformance level might not
adequately meet the needs of the Web site's users with some disabilities.
In that case, an organization might choose to meet additional guidelines
or conformance levels in order to provide sufficient
accessibility."
Would be great to be able to point to comparison of WCAG 1.0 &
Section 508 1194.22 and show where 508 does not need needs of all people
with disabilities.
Copyright
© 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.