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

Re: A proposal for changing the guidelines

From: Robert Neff <robneff@home.com>
Date: Mon, 13 Mar 2000 23:16:06 -0500
Message-ID: <002a01bf8d6c$0588d0a0$59b10f18@alex1.va.home.com>
To: <gv@trace.wisc.edu>, <w3c-wai-gl@w3.org>
i also agree with Nir, in that universal design is independent of the state,
that is server or client-side - the goal is to ensure the user gets what
they need.  this is done several ways:
1.  Server side processing of requests that generate or spit out HTML pages
per universal design.  These are produced by dynamic low-end solutions or
via middleware, and
2.  Client-side efforts that can be turned off or rendered through other
means.  But a form can be processed via server-side if client is turned off.

So in effect if i use personalization and content management software, then
you can subscribe to a service. Where you can be a PWD with different
profile.  This could be an effective means.  As software and content
delivery becomes more sophisticated, it is a way to reach a broader
audience - as based upon guidelines.  There are already subscription
services that broker credit card payment and this could be a similar service
for a protal.

I disagree, I do not think server side solutions will wreak havoc with
accessibility validators.  Validators must be tuned to meet requirements to
meet demand.  The fact that it is a free service is a question, that is, can
it meet demand or do we need to find someone to modify it on a continual
basis.  For example, macromedia flash, where we now use ALT tags, or server
side validation.  A standard or technique to be implemented would be for
form validation to use bold and asterick for mandatory items, and upon
validation a plus sign and red bold for invalid entries.  You can still use
javascript but wold not need to use <NOSCRIPT> if it is validated on server
side.

Client-side valisdation increase download time and server side validation
increases server processing time.  How you chose to implement this is an
operations issue dependent upon your server configuration (one, two or three
tier, processor and traffic for both normal and the unexpected spike)

I agree with item 4 and 5.  Please go to
http://www.webspots.net/WCAG_Checklist-understand.htm and view.  May I
suggest you click on
http://www.webspots.net/WCAG_Checklist/WCAG_Matrix-rating_sheet.xls and use
the checkpoint list to comment.


thanks, rob

----- Original Message -----
From: Gregg Vanderheiden <gv@trace.wisc.edu>
To: <w3c-wai-gl@w3.org>
Sent: Monday, March 13, 2000 10:29 AM
Subject: RE: A proposal for changing the guidelines


> Some short notes and an important call....
>
> Short Notes (opinions not rulings)
>
> 1) When discussing universal design,  we should be sure to decide if we
are
> talking about universal design applied to the website - or applied to the
> page.   I think dynamically generated presentations is clearly universal
> design of the site.     I think I prefer pages that transform of
themselves
> rather than server side assisted transformations, but I'm not sure which
> will actually give more people more usable pages.     My guess is that
> transforming pages will more often provide users with all the information
> (e.g. less inadvertent editing out of info)  but that server side would
> generate more usable pages for each domain
>
>
> 2) I don't think our guidelines should take a stand on how the pages are
> generated.... But rather on what makes a page accessible...   If we can
> avoid how and stick to what - I think that is better.
>
>
> 3) I think server side solutions will wreak havoc with accessibility
> validators
>
>
> 4) We should look again at the interaction of our priority guidelines and
> regulations.   In the past our priorities have been determined basically
by
> what makes a page accessible.... Not by its ease of implementation.     If
> regulations are going to say Priority 1 and 2  -  then we need to think
this
> through carefully.  I hate to say this but I think we do.
>
> 5) I think we will have some very interesting discussions at CSUN.  I am
> looking forward to everyone's views.
>
>
> -- IMPORTANT CALL --
>
> BUT MOST IMPORTANTLY -  If you think that we need to do something
different
> with the guidelines
> You must come to CSUN with suggestions (or post them to this list).
Specific
> suggestions for change.
>
> We are beginning to just run in circles with opinions and general
concepts.
> I think that this stage is essential, but we also need to move on to the
> next one as well.  At least we need to see what the options might look
like
> if they were implemented.      There are always problems with any
approach.
> The question is, would an alternate approach be a better than what we
have.
> To determine that we need to start looking at specifics as well as the
> general concepts.
>
>
> Specific ideas or suggestions for the guidelines or techniques doc anyone?
>
>
> Gregg
>
>
>
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
> Professor - Human Factors
> Dept of Ind. Engr. - U of Wis.
> Director - Trace R & D Center
> Gv@trace.wisc.edu, http://trace.wisc.edu/
> FAX 608/262-8848
> For a list of our listserves send "lists" to listproc@trace.wisc.edu
>
>
>
Received on Monday, 13 March 2000 23:16:59 GMT

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