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

RE: My Action Item: Multiple interface guideline

From: Charles McCathieNevile <charles@w3.org>
Date: Sat, 14 Oct 2000 08:53:04 -0400 (EDT)
To: Cynthia Shelly <cyns@whatuwant.net>
cc: Kynn Bartlett <kynn-edapta@idyllmtn.com>, "'w3c-wai-gl@w3.org'" <w3c-wai-gl@w3.org>
Message-ID: <Pine.LNX.4.21.0010140850070.15622-100000@tux.w3.org>
I think we all agree that it is a requirement that the content overall is
accessible, and a major requirement at that. I agree that it is not as
important that each individual variant of a personalised presentation be
accessible, but I do think it is a goal insofaras it is consisstent with
delivering a good quality version of the information. If for nothing else,
becuase it saves users from having to learn and use the mechanism for
selecting the version appropriate for them, which is a performance hit and a
usability barrier initially.

(the counter argument is that if it is seen as good enough people will not
bother to get the version that is really good for them. But I think the
premise, that it is good enough, destryos the value of the argument)



On Fri, 13 Oct 2000, Cynthia Shelly wrote:

  I'm not convinced that it should be a goal for each version to be broadly
  accessible.   I see tailoring UI to the specific needs of the user as a
  potential way to create interfaces that are far more accessible to any given
  individual than a one-size-fits all approach could ever be.  As long as the
  sum of the versions is accessible, then I think the content can be
  considered accessible.  It makes sense to require that one version be
  broadly accessible (maybe even AAA) to cover any cases the author didn't
  think of, and that it's easy to get to that version.
  I expect this to be controversial, so I'll duck now :-)
  -----Original Message-----
  From: Charles McCathieNevile [mailto:charles@w3.org]
  Sent: Friday, October 13, 2000 7:51 AM
  To: Kynn Bartlett
  Cc: 'w3c-wai-gl@w3.org'
  Subject: Re: My Action Item: Multiple interface guideline
  The truth lies somewhere in between for the real world, I think. As people
  have said in this discussion, it is critical that the method for getting the
  version that you can use is accessible - P1 that it is level-A accessible in
  the current terminology, and I would argue P2 that it is double-A, P3 that
  is triple-A, using the relative priority that exists in ATAG.
  I don't think it is P1 that each alternative version of content be level-A
  accessible. I think it is P1 that the collection of alternatives (and as
  above the method for choosing which of a collection a user atually gets) is
  I think it is at least P3 that each piece be broadly accessible - i.e. that
  it meet level-A or double-A on its own, without relying on its
  alternatives. In some cases that is not currently possible - some formats
  simply not able to achieve that on their own. But it is generally superior.
  am wondering about an argument that it is P2 - i.e. important for
  accessibility of the overall content - what do people think?
  Charles McCN
  On Fri, 13 Oct 2000, Kynn Bartlett wrote:
    At 5:18 AM -0700 10/13/00, William Loughborough wrote:
    >I wonder if in the explanation it could somehow be emphasized that 
    >this technique must not serve as a copout for failure to provide 
    >conformance in the provided versions? One problem with "separate but 
    >equal" is that you tend to get a whole lot of separate and not 
    >enough equal. "Oh, I provided a text description so I didn't think 
    >it necessary to make the xxx (Flash, SVG, whatever) version conform 
    >to the guidelines.
    Uh, part of the whole point of doing server-side multiple interfaces
    is that the different pages don't _have_ to be held to the same
    standard of accessibility.
    For example, if I were making a page that was intended solely for
    a screenreader, I would produce a structured textual page without
    graphics -- save for the one graphic to allow change back to a
    "base" state which has been held to a higher standard of
    A purely textual page obviously -- as Jonathan and Anne would tell
    us -- violates the needs of people who rely upon graphics.  And yet,
    for the specific audience who had selected this interface, it _is_
    accessible (remember, accessibility does not exist in a vacuum,
    you can only be accessible or inaccessible _by a person_).
    The one graphic is there because the mechanism needed to "change
    back" is required by the proposed guideline (as articulated well
    by Cynthia).
    A parallel solution would indeed be the Flash version.  I can
    deliver a near-pure Flash interface to site users who desire or
    who can use it, and I don't -have- to hold it to the same standard
    of general accessibility as a single-interface page.  However, the
    mechanism to switch back (the same graphic, with -- of course --
    appropriate ALT text, etc.) must be made accessible so someone who
    wanders onto this page with a screenreader has a way out.
    There is no concept of "separate but equal" or "whole lot of
    separate and not enough equal" involved here.  You are misapplying
    social rhetoric and trying to force technology to bend to simplistic
    As long as the _content_ is accessible to as broad an audience as
    possible, there is no need to require that every single interface
    be equally accessible to everyone -- only that the mechanism for
    selecting an appropriate interface be of the highest level of
    accessibility.  This is not a "separate but equal" case, and I think
    it is _very_ dangerous to try to apply pithy slogans in ways which
    they were never intended to be used.

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
September - November 2000: 
W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France
Received on Saturday, 14 October 2000 08:53:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:34 UTC