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?)

This is true. There are people who are designing for "minor" browsers, too.
Netiher strategy is a guarantee of accessibility, and in many cases sites are
made inaccessible for no good reason, just a poor understanding of how the
web works.

I have used http://www.microsoft.com and had a different site presented to me
when using IE 5 on windows from what I got using other browsers. (I just
checked using IE 5 ona a Mac and iCab, and in both cases got what I think is
the alternative version - no fly-out menus. I am going from memory here
though - or perhaps they have changed the site). To get to the same content
using the alternative cversion was possible, but involved slightly different
navigation paths. This is just unhelpful design - it poses some accessibility
problems particularly because it doesn't provide a predictable browsing
experience for people used to using more than one browser.

Using http://www.mbta.com with a browser which was capable of doing what was
apparently required it was still impossible to get to certain types of
content (for example an image of a map - even lynx can handle that!). On the
other hand a browser which clearly did not have the capabilities required was
given access. I am pretty sure that this is a piece of badly-designed
browser-sniffing at work. The result is a total breakdown in accessibility.
If the site works differently in different browsers that may be due to poor
coding, either of the site or of a lot of browsers. But to block access
deliberately is not "a corporate policy that we should take into account", it
is a corporate policy to block access. (Or it may just be an oversight.
Either way, it is, in my opinion, terrible design and not accessible.)

cheers

Charles McCN

On Sun, 7 Jan 2001, Robert Neff wrote:

  charles, i was inferring that there are major corporations that are
  specifying or designed for this speciofic browser and version and this is
  normally netscape and IE.


  ----- Original Message -----
  From: "Charles McCathieNevile" <charles@w3.org>
  To: "Robert Neff" <robneff@home.com>
  Cc: "Jason White" <jasonw@ariel.ucs.unimelb.EDU.AU>; "Web Content
  Accessibility Guidelines" <w3c-wai-gl@w3.org>
  Sent: Sunday, January 07, 2001 10:40 PM
  Subject: SSL Re: Proposal for Guideline 2 as well as a proposal to trim WCAG
  2.0 to 3 guidelines (won't william be glad?)


  > 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
  >


-- 
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

Received on Sunday, 7 January 2001 23:44:55 UTC