W3C home > Mailing lists > Public > wai-eo-editors@w3.org > April 2004

RE: Comments on: business case status as of 2 April 2004 & review notes

From: Shawn Lawton Henry <shawn@w3.org>
Date: Tue, 13 Apr 2004 21:30:38 -0500
To: "'Sailesh Panchang'" <sailesh.panchang@deque.com>
Cc: "wai eo editors" <wai-eo-editors@w3.org>
Message-ID: <000301c421c8$7a277ac0$418d7544@SLHenry>

Sailesh,

Thank you for your review and comments on the business case. I will post
a revised version with your changes and other's changes soon. 

Replies to your comments are below indicated with my initials (SLH) and
surrounded by brackets [SLH:]. Let me know if you want to discuss any of
them.

Regards,

~ Shawn

---
A. Social Factors page
 
Following wording seems odd : 
- enhanced reputation to potential customers...
[SLH: DONE, changed to: "improving corporate reputation"]
- Corporate social responsibility (CSR), also called corporate
citizenship and other  terms ...
[SLH: are you saying the terminology is odd?  "corporate social
responsibility" and  "corporate citizenship" are two terms that are
fairly commonly used]
 
B. Financial Factors:
1. Too long and winding: 
"This page provides questions to help focus how financial factors are
covered in  the business case for a specific organization, and examples
of how financial  factors can be addressed in a customized case for Web
accessibility."
[SLH: DONE, changed to "This page provides guidance on customizing how
technical factors are covered in a specific organization's business case
for Web accessibility."]

2. I suggest a replacement for 
"The following points can help determine how financial factors are
covered in a  specific organization's business case for Web
accessibility:"
SP: Answers to the following questions might helpidentify the impact of
Web  accessibility   on the org.'s financial costs and benefits.
(This suggestion applies to other pages as well) 
[SLH: DONE, edited to be consistent on all pages: "The following
questions can help identify how the social factors of Web accessibility
apply to the organization:"]

3. Questions (e.g. for Financial factors page):
Can the org.'s website  be made to increasingly influence its revenues
and  the  manner in which it conducts its operations?
[SLH: This seems too high-level, too complicated to relate to Web
accessibility,  beyond the scope of this document.]
- What is the present state of Web accessibility? 
[SLH: I don't see the impact of this statement - that is, how does the
answer to  this question affect what is put in the organization's
business case?]
- Can the org.'s accessibilitty initiative be made to dovetail with the
org.'s wider  usability initiative?
[SLH: The working group decided to be careful not to focus too much on
usability  for several reasons, for example, usability is not a given
for many organizations  and is often a hard sell itself. Do you think
this is adequately covered in "Are there  other efforts in the
organization that overlap with the financial benefits of Web
accessibility?
Is the organization focusing on improving search engine rankings,
increasing  market share, or improving usability for all users? " ?
(also note that many  organizations do not have a usability initiative)]
- Does the legal risk of operating an inaccessible website have a
financial impact ?
[SLH: Isn't the answer to that always yes? and it the risk depends on
Legal &  Policy factors? The document currently states, "In some cases
it is useful to  include in a business case the potential legal costs
associated with defending  against legal action for not complying with
requirements for Web accessibility"]

I strongly feel listing questions in abulleted form helps to focus
better. The  material following the questions can be moved to an
introductory / background   part. 
[SLH: Right. That is in the changelog, "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." I will work  on that as soon as I respond to
all reviewer comments. I do think I can move  some things out from under
the questions; however, I think it might be best to  leave some there.
Some of the question might need further clarification to be well
understood. And I think after the question should be immediately
followed by  direction on what to do based on the answer. Let's see what
you think after I take a final pass at it.]

C. Legal Factors page
Questions re-phrased as under  to avoid explanation:
- Is the organization required by law or other mandate to make its
Website  accessible?
[SLH: DONE, replaced first question]
- Does the organization have a formal   Web accessibility policy?
[SLH: I think if an organization already has a formal Web accessibility
policy, they  would not usually be writing a business case to justify
Web accessibility.]
- What are the  risks  of not  having an accessible website?
[SLH: I think many audience members will not know that. That is one of
the things  we need to tell them in this suite. In the final editing
pass, I will try to clarify that  better.]

2. Repetition:  Last question again says easier to  build accessibility
from start...  This is said in other pages too.
The document should  be as concise as possible and should make a point
at the  appropriate place and go on. It should not depend on repetition
to get the point  across. 
[SLH: Right, we want to be very careful to limit repetition. However, I
think it is  needed here. The question is "Will policies later become
applicable?" and what we  don't want is for people to say, "well, they
might, but we're going to wait until  we're required to do it later, and
not bother with it now." So I think it is important  to clarify that
there are benefits to doing it now and not waiting, albeit briefly
here.]
 
D. Technical Factors
1. Replacement text suggested for  para starting with 
"The technical performance benefits related to Web accessibility vary
according to  the type of organization and type of Web site."
 
SP:  Web accessibility solutions  often result in improved technical
performance;  its impact differs from organization to organization and
by the nature and size of  the website.     Serverload is critical  for
an organization that depends heavily on  its extensive website for its
business but may not be critical for a not for profit  organization with
just a few pages of Web content which it hosts through a service
provider. Efficiency of Web content maintenance might be  important for
a news  organization whose content changes several times a day. Enabling
content on  different configurations might be important to another
enterprise. 
[SLH: DONE, integrated your suggestions with edits to be more consistent
with  other pages.
Changed to:"Web accessibility solutions often result in improved
technical  performance. The importance of various technical benefits of
Web accessibility is  different for specific organizations and
situations. For example, reducing server  load might be most important
to an organization with a large, mission-critical,  high-traffic site;
whereas another organization that focuses on cutting-edge  technology
might be more interested in interoperability and being prepared for
advanced Web technologies. Yet these same technical benefits might not
be very  important for organizations with small, simple sites."
(Previous version was: "The technical performance benefits related to
Web  accessibility vary according to the type of organization and type
of Web site. For  example, an organization with very limited personnel
resources might be more  interested in reducing site development and
maintenance time, while another  organization that focuses on
cutting-edge technology might be more interested in  interoperability
and being prepared for advanced Web technologies.")]

E. 
Editorial: (only one so please pardon its inclusion here)
[SLH: no problem! <grin/>]
1. This word needs to be corrected in many places throughout the suite:
organziations
[SLH: DONE. thanks]
Received on Tuesday, 13 April 2004 22:30:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 12 January 2010 00:13:10 GMT