- From: Shawn Lawton Henry <shawn@w3.org>
- Date: Tue, 13 Apr 2004 14:15:40 -0500
- To: <michaeka@wellsfargo.com>
- Cc: "wai eo editors" <wai-eo-editors@w3.org>
Blossom, 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 surrounded by brackets []. Let me know if you want to discuss any of them. Regards, ~ Shawn [DONE] 1. RELATED RESOURCES LINKS The links under Related Resources should only be to documents outside the suite. The documents within the suite ARE the suite, not RELATED to it. Having links both to the suite docs and to outside pages in one place is confusing. ... [I think it is important to the have links to other pages within the text upfront because: 1. people often "mask out" navigation, 2. people could end up on this page without any other context (e.g., from a search engine or a print out), 3. the page is not intended to stand alone and its relationship to the other pages is very important. I tried simplifying it, e.g., "This page describing the social factors relating to Web accessibility is part of a resource suite..." but I think it is clearer as is and not worth cutting a few words to increase the complexity of the first sentence. (also: a. someone who is familiar with the suite will quickly "mask out" that first paragraph, b. we did remove the bottom links)] 2. THIS PAGE DESCRIBES... I don't think we need to begin the introductions to the Social Factors, Technical Factors, Financial Factors, and Legal and Policy Factors pages with the "This page describes..." sentence. It's redundant. The suite nav and the title of the document already says that we're talking about, for example, social factors. Also, by eliminating this sentence, we're reducing suite link redundancy: rather than three links on most every page to the suite documents, we would only have two - the top suite nav and the bottom links. (Three links on a page going to the same place is not a good screen reader experience.) The introductions to Social Factors, Technical Factors, Financial Factors, and Legal and Policy Factors pages would then begin with the actual subject matter of the page. [totally rewrote Overview Introduction - is this better?] 3. OVERVIEW PAGE, INTRODUCTION The topic of the Overview page is "suggestions on how to compile such a customized business case...." The introduction should focus on this. Having it begin with why Web accessibility is important is a disconjunct for me. It's important to have this info in the Overview, but possibly it could go under its own header after "Introduction" and before "Identify the Organization's Interests." We could list the whys and also link to other places in the suite that further describe the importance of Web accessibility. The Introduction could then begin with "Different organizations have different requirements for a 'business case'...." [DONE] I would change "This WAI Resource Suite" to "The Presenting the Case for Web Accessibility resource suite...." This is user centric rather than organization centric. [DONE] I don't think we should use "building blocks" in the phrase "guide to the building blocks which make up this resource suite." Does this mean the building blocks that the suite itself is composed of or the building blocks that can be compiled into a business case? The suite is more than the building blocks suggested for building a case for Web accessibility. > -----Original Message----- > From: w3c-wai-eo-request@w3.org > [mailto:w3c-wai-eo-request@w3.org] On Behalf Of > michaeka@wellsfargo.com > Sent: Thursday, March 25, 2004 6:17 PM > To: w3c-wai-eo@w3.org > Subject: Presenting the Case for Web Accessibility: Comments > > > > Hello, everyone - > > Here's some suggestions for the suite: > > 1. RELATED RESOURCES LINKS > The links under Related Resources should only be to documents > outside the suite. The documents within the suite ARE the > suite, not RELATED to it. Having links both to the suite docs > and to outside pages in one place is confusing. > > If we want navigation for the suite at the bottom of the > page, we should design it as navigation, not as related > links. Possibilities include: > > - Repeat the suite nav at the bottom of the page. > > - Create another design for "footer nav." > > - Put this navigation in a paragraph at the end of the > document content right before the Related Resources header: > > "This document is part of the Presenting the Case for Web > Accessibility resource suite that includes: Overview, Social > Factors, Technical Factors, Financial Factors, Legal and > Policy Factors, and References." [Each of the parts named > would be links, except for the page the user is on.] > > 2. THIS PAGE DESCRIBES... > I don't think we need to begin the introductions to the > Social Factors, Technical Factors, Financial Factors, and > Legal and Policy Factors pages with the "This page > describes..." sentence. It's redundant. > > The suite nav and the title of the document already says that > we're talking about, for example, social factors. Also, by > eliminating this sentence, we're reducing suite link > redundancy: rather than three links on most every page to the > suite documents, we would only have two - the top suite nav > and the bottom links. (Three links on a page going to the > same place is not a good screen reader experience.) > > The introductions to Social Factors, Technical Factors, > Financial Factors, and Legal and Policy Factors pages would > then begin with the actual subject matter of the page. > > 3. OVERVIEW PAGE, INTRODUCTION > > The topic of the Overview page is "suggestions on how to > compile such a customized business case...." The introduction > should focus on this. Having it begin with why Web > accessibility is important is a disconjunct for me. > > It's important to have this info in the Overview, but > possibly it could go under its own header after > "Introduction" and before "Identify the Organization's > Interests." We could list the whys and also link to other > places in the suite that further describe the importance of > Web accessibility. > > The Introduction could then begin with "Different > organizations have different requirements for a 'business case'...." > > I would change "This WAI Resource Suite" to "The Presenting > the Case for Web Accessibility resource suite...." This is > user centric rather than organization centric. > > I don't think we should use "building blocks" in the phrase > "guide to the building blocks which make up this resource > suite." Does this mean the building blocks that the suite > itself is composed of or the building blocks that can be > compiled into a business case? The suite is more than the > building blocks suggested for building a case for Web accessibility. > > Ran out of time - have to go now.... > > Regards, > > Blossom > _____________________________________ > Blossom Michaeloff > Web Research and Design > Wells Fargo > 415.222.3045 > michaeka@wellsfargo.com >
Received on Tuesday, 13 April 2004 15:54:13 UTC