W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2001

RE: process of a site development

From: Robert Neff <rneff@bbnow.net>
Date: Fri, 26 Jan 2001 15:29:49 -0600
To: "Matt May" <mcmay@bestkungfu.com>, "Lisa Seeman" <seeman@netvision.net.il>, "WAI" <w3c-wai-gl@w3.org>
Here is an excerpt from my presentation at www8 in Toronto.  The text speaks
to the powerpoint slide, which I need to locate and post.   This is somewhat
dataed but the process is still good.  Note need to update this to add CSS

To build a Universally Accessible web site, here is an outline of the life
cycle development process the web designer, coder, content manager, graphic
artist or team can use. The foundation for any universally accessible web
site is the guidelines. The World Wide Web Consortium's Web Accessibility
Initiative (WAI) has published the Web Content Guidelines for people to
use - these are free! On the WAI web site you will also find the List of
Checkpoints. Should you have questions, the Web Accessibility Initiative
provides an Interest Group or forum for discussion on issues relating to Web
accessibility, particularly issues related to WAI activities.
Universal accessibility incorporates usability and universal design. So when
building a web page or web application, accessibility problems or other
design, errors can be greatly reduced before the web page or site is
released to the public. This is accomplished by applying quality assurance
to check the concept, syntax and code; layout, navigation, and graphics; and
acceptance testing on multiple browsers and users.
Quality assurance incorporates internal or external reviews or peer reviews,
and applying third party tools. For example, CAST's Bobby for an
accessibility check, W3C's HTML to validate the code and StarBase's
StarSweeper to check for ALT Tags, Title's, Height and Width, build an image
library from the web site and other quality assurance functions. Unit or
Acceptance testing can be accomplished on multiple browsers to ensure the
information is conveyed and there are no navigation or site usage problems.
For example, here is a simple process to follow in order to build a
universally accessible web page or web applications:
* Define the audience, business requirements and rules, objectives, and
timeline with the user.
* Determine resources, schedule, and sketch the process with a flowchart.
* Determine the design requirements and approach; refer to the Web Content
Guidelines and internal design documents.
* Design the web site or web application.
* Design Review with the customer to ensure the design is what they
* QUALITY ASSURANCE. The web coder or programmer would then conduct a
Quality Assurance review by using Bobby; and a HTML code validator and one
or a combination of the following tools or methodologies: content review;
preview on Lynx, a text based browser; multiple browsers and versions
(Internet Explorer 3 and 4, Netscape Navigator 3, 4.x, and Opera);
voice-based web browser (pwWebSpeak), and screen readers (WIN Vision and
Jaws For Windows), Palm devices, StarBase's StarSweeper and WebSite Garage.
Other items that can be checked are, does the page print properly in black
and white and color? Can the all print and graphics be read?
* UNIT TEST. The coder or programmer tests compliance to the business
requirements. For example, test to ensure the e-mail functions and the
message is received by the recipient, forms are tested and data checked,
links are tested. Usability testing can be either simple or more formal.
Users who are not associated with the design can conduct this or an
independent third party can provide a review of the design concept. If the
design uses queries or updates to modify or retrieve information from the
database, then this will need to be tested. The coder can develop scenarios
using a spreadsheet to document the process, more commonly referred to as a
script. There are also automated testing tools that will record your script
and play it back anytime or simulate different browsers. These tests serve
as a baseline for the design criteria and also can document the expected
* Acceptance Test. This is formal acceptance by the customer of the product
you designed as based upon customer requirements and a test plan. This
procedure can be either a simple checklist or a more formal document if it
is part a more business critical function.
The above process is shown below using a flowchart, see Figure 1 Life Cycle
Development. The keys to any project using the life cycle development
approach are the business rules, the technical and functional design
reviews, and tracking the project using a scheduling tool. This flowchart
describes the major tasks as identifying the project, requirement
definition, test plan, site design, quality assurance, unit test, and
acceptance testing is started. Once requirement definition is complete then
two tasks can start, requirements definition and the test plan.
Before the design is moved between the major tasks, the code can be
baselined and submitted to configuration management or an automated
configuration management tool could be used to manage the code. At this
point the project lead and/or customer also review the design. If the design
fails the review, then a corrective action report is issued and rework
begins to correct the discrepancy. If the design passes and the customer is
satisfied, then design moves to the next task.
When the unit test and the test plan are complete, then acceptance testing
can begin. If the acceptance test fails, then a corrective action report is
issued and rework begins to correct the discrepancy. If the project passes
and the customer is satisfied, then project is promoted to production, which
can involve alpha or beta test.
Each major task has inputs that can be used as a metric or requirement and
the inputs to:
Requirements definition are business rules; scope and definition; allocation
of resources, timeline and budget; design requirements, guidelines, and flow
chart; database design and schema: and, security.
Site Design which includes web applications and database are content,
usability, graphics, layout, HTML or CSS, web application development,
email, forms, and banners.
Quality Assurance are content review; Bobby; layout; code validator; view on
lynx, pwWebSpeak, multiple graphical browsers and versions; review and use
email and forms; print in black and white, and color; and spell check.
Unit Test are use cases, test scripts, test web applications and database.
Test Plan are test environment involves use cases, test criteria, and test
scripts; and test such as usability, performance, functional, regression,
and/or load, which incorporates concurrent users.
Requirement management and traceability requirements are the cornerstone of
any successful project. Each time there is a change to the requirement or
there is a schedule slippage, then the dependencies and constraints must be
Received on Friday, 26 January 2001 16:27:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:09 GMT