Re: SSL Re: Proposal for Guideline 2 as well as a proposal to trim WCAG 2.0 to 3 guidelines (won't william be glad?)

Unfortunately, SSL isn't part of the general distribution of Lynx.  It's a 
patch [1].  This is due to US export regulations.    So we can't count on 
Lynx users having access to SSL.  For example, lynx here on our unix 
machines at Temple don't have it, even though they're running version 2.8.

As a result, Pennsylania's internet guidelines [2], require alternatives to 
SSL, viz.

quote
1) printable forms that can be printed, completed off-line, and mailed in; 
or 2) personalized service via email communication or a toll-free number. 
Every effort should be made to administer these accommodations in a timely 
manner, consistent with comparable online transactions.
end quote

Shall we do something similar in WCAG?

Len

[1] http://lynx.isc.org/release/ssl.html
[2] http://www.oit.state.pa.us/oit/Policy/view.asp?Q=16655

At 10:40 PM 1/7/01 -0500, Charles McCathieNevile wrote:
>I don't think that it is OK to say "you have to have IE or netscape to use
>SSL". Apart from anything else, it just isn't true. (Similarly,
>http://www.mbta.com excludes browsers other than those two on the grounds
>that CSS and javascript are required. Even if those browsers have CS and
>Javascript deactivated. And it excludes Opera 5.0, which has fine CSS and
>Javascript support).
>
>On the other hand, I think SSL is a requirement that it is reasonable to make
>on a browser - it is now widely available (Lynx, iCab, IE, Netscape, Opera
>all provide it and I believe there are others as well).
>
>cheers
>
>Charles McCN
>
>On Sun, 7 Jan 2001, Robert Neff wrote:
>[other comments snipped]
>   comment on 'Guideline 4: Compatibility.'
>   how are we handling companies that have made a concious effort to set a
>   minimum standard for browser compatibiltiy?  these decisions are normally
>   driven by cost and security - especially where secure socket layer is used
>   (SSL).  do we have an alternate method for people to access 
> information?  do
>   we need to address security here and state that there may be overidding
>   reasons and justifications where a call center may not be avaialble to help
>   someone.
>
>   overall my i think this is a great step forward and need to look at teh 
> cost
>   impact and help those people who do not have the funds nor technical means
>   available to satisfy each line item in the quideline.
>
>
>
>   ----- Original Message -----
>   From: "Jason White" <jasonw@ariel.ucs.unimelb.EDU.AU>
>   To: "Web Content Accessibility Guidelines" <w3c-wai-gl@w3.org>
>   Sent: Sunday, January 07, 2001 12:56 AM
>   Subject: Re: Proposal for Guideline 2 as well as a proposal to trim 
> WCAG 2.0
>   to 3 guidelines (won't william be glad?)
>
>
>   > Lest I be accused of having become a polemicist, I would here like to
>   > amplify my own proposal a little more, though it is still very much 
> in the
>   > form of an outline:
>   >
>   > Guideline 1: Device-independence.
>   >
>   > 1.1 Text equivalents.
>   > 1.2 Synchronization of text equivalents with auditory/visual content.
>   > 1.3 Auditory descriptions.
>   > 1.4 Exposure of structural and semantic distinctions in markup or in a
>   > data model.
>   > 1.5 Logical separation of content and structure from presentation.
>   > 1.6 Device-independence of input event handlers.
>   >
>   > Guideline 2: Design content to facilitate browsing, navigation and user
>   > interaction.
>   > 2.1 Consistent interaction/navigation mechanisms.
>   > 2.2 Avoid content that interferes with the user's ability to navigate.
>   > 2.3 Provide user control over time-based events or content that 
> introduces
>   > unexpected changes in context.
>   > 2.4 Provide a range of search options for various skill levels and
>   > preferences.
>   >
>   > Guideline 3: Design content for ease of comprehension.
>   > 3.1 Consistency of presentation.
>   > 3.2 Emphasize structure through presentation.
>   > 3.3 Use the clearest and simplest language appropriate to the content.
>   > 3.4 Use auditory/graphical presentations where these facilitate
>   > comprehension.
>   > 3.5 Summarize complex or highly structured information.
>   > 3.6 Define key terms.
>   > 3.7 Provide structures that divide information into small, logically
>   > organised units.
>   >
>   > Guideline 4: Compatibility.
>   > 4.1 Use markup and style languages, API's and protocols in accordance 
> with
>   > applicable specifications.
>   > 4.2 Ensure that content is compatible with assistive technologies and
>   > that, so far as is practicable, it is backward compatible.
>   >
>   >
>   > Here, I have incorporated what I regard as the best and most 
> innovative of
>   > Wendy's ideas into what I hope is a better organised structure. One point
>   > worth noting is that, instead of requiring the use of style languages as
>   > such, I have made the more general point that structure/semantics should
>   > be represented separately from presentation, whether this be achieved by
>   > way of a style language, or by, for example, alternative versions of the
>   > content (for example, a structural tree which is logically distinct from,
>   > and provided along side of, page descriptions, as in PDF, or XSL with the
>   > ROLE and SOURCE attributes). The direct reference to style languages is,
>   > perhaps, more specific than is necessary to specify the requirement.
>   >
>   > I welcome comments, polemics and, above all, thoughtful suggestions.
>   >
>   >
>   >
>   >
>
>
>--
>Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
>W3C Web Accessibility Initiative                      http://www.w3.org/WAI
>Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
>until 6 January 2001 at:
>W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, 
>France

--
Leonard R. Kasday, Ph.D.
Institute on Disabilities/UAP and Dept. of Electrical Engineering at Temple 
University
(215) 204-2247 (voice)                 (800) 750-7428 (TTY)
http://astro.temple.edu/~kasday         mailto:kasday@acm.org

Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools Group
http://www.w3.org/WAI/ER/IG/

The WAVE web page accessibility evaluation assistant: 
http://www.temple.edu/inst_disabilities/piat/wave/