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

RE: CSS-P Site Built For Accessibility

From: Charles McCathieNevile <charles@w3.org>
Date: Sun, 9 Jan 2000 07:41:00 -0500 (EST)
To: Joel Sanda <joels@ecollege.com>
cc: "'w3c-wai-ig@w3.org '" <w3c-wai-ig@w3.org>
Message-ID: <Pine.LNX.4.20.0001090730360.638-100000@tux.w3.org>

no, the resizing doesn't worry me for the reasons you outline, and the
rollover stuf is ont really here otr there - when they work well they improve
accessibility I think, although it would be nice if they could also be
activcated from the keyboard where possible - in current terms a simple
matter of adding 

  onFocus="turnOver('registration', 'button4')" 
  onBlur="turnOff('registration', button4')"

(or whatever the appropriate inputs are) for each of the rollover images.

The one real problem I have is with something like

  <a href="javascript:openwindow('http://www.luc.edu')" ...

Which actually requires a javascript-capable browser to work, but

  a) could be achieved without Javascript:

    <a href="http://www.luc.edu" target="_new" ...
  b) goes against the recommendation of WAI not to open new windows unless
  under the control of the user, since this destroys the user's concept of
  where they are, and removes their ability to rely on the Back button -
  the second most popular feature of a browser after the ability to follow
  links, (at least that is what I have read by Jakob Nielsen and see no
  reason to doubt him).


Charles McCN

On Sun, 9 Jan 2000, Joel Sanda wrote:

  I'm not sure which JavaScript you're talking about here - the JS that
  corrects the window.resize function in Netscape or the rollovers. The
  window.resize 'bug' in Netscape, as far as I know, can only addressed with
  JS. And since that does nothing but call a window refresh after the
  window.resize function happens, it doesn't effect accessibility. It actually
  improves it if you're using a Netscape browser - PC or Mac.
  As for the rollovers - that's fairly standard JS. Although we had to make
  some modifications after we noticed some screen readers didn't like JS
  rollovers when the mouse was used. Can't explain that one.
  Because of the limited support of CSS-P in both Opera and Netscape, there is
  no way to use CSS-P and have it scale in Netscape. Opera just won't do it.
  Netscape can't handle a DIV width, nor can it be relied upon to adequately
  render a background color in a DIV tag. To make a 'scalable' document like
  you're talking about means using tables for layout, which we wanted to drop
  in favor of CSS-P. And even Opera seems to have a problem with tables set to
  "100%" width, and with the width of some cells set to "*". I've never been
  able to get Opera to render a table with variable width that well.
  So the variable width problem is a problem. And I'm unsure how anyone could
  build a visually appealing site that scaled from 600x400 up to 1280x1024.
  That would mean the largest image or non-breaking element on a page could
  not be wider than 600 pixels, minus some for the borders on a browser. And
  if you have navigation down the left-hand side of the page, there would be
  very little room left for content.
  I think the real quandry are browsers that don't really support the W3C and
  WAI recommendations. I suppose one solution is to build seperate pages for
  the different browsers, but in that case none of us would get any work done!
  If nothing else, I think we've learned CSS-P is very powerful, and it seems
  to be rendered by screen readers much better than layout done with tables. I
  hope that the upcoming 4.0 release of Opera supports the CSS Level 2 Spec.
  Of course, if we could all count on aural Style Sheet support, our jobs
  would be all that much easier!
  Joel Sanda
  -----Original Message-----
  From: Charles McCathieNevile
  To: Joel Sanda
  Cc: w3c-wai-ig@w3.org; w3c-wai-ig@w3.org
  Sent: 1/7/00 11:35 PM
  Subject: Re: CSS-P Site Built For Accessibility
  In questionging the necessity of Javascript I was referring to it as a
  browser requirement - there seems to be ittle if any functionality
  by the Javascript that cannot either be replicated by a more widely
  method, or is only decorative and therefore need not be replicated.
  In fact the rage of screen sizes today is wider than it has been in the
  - there are regularly people operating on a smaller screen than 800x600,
  either through hardware restrictions, magnification, only having a
  window, etc, and there are also a large number of screens that are
  significantly larger than 800x600. If it is possible to adjust te layout
  to a
  more flow-based model, that wiill make better use of whatever screen
  size is
  I realise the issue of cross-browser support is problematic. Have you
  considered recommending Opera or ICE as alternatives? They provide
  javascript, good quality CSS and HTML, etc. (Although as noted above, I
  not sure if Javascript is really a requirement).
  Congratulations again on the good work - Keep it up *grin*
  Charles McCN
  On Fri, 7 Jan 2000, Joel Sanda wrote:
    Thanks for your response and critique. I hope my responses can explain
    we chose to do some things the way we did.
    The JavaScript is necessary to maintain the page layout in Netscape
    when the window is resized. As we all know, you resize a window in
    and the CSS-P is thrown out the window. That JavaScript forces a
    which restores the CSS-P formatting. It's actually a modification of
    JavaScript published by O'Reilly in one of their JavaScript books -
    version is buggy in a couple of Netscape 4.x versions, particularly on
    Great feedback on the video and audio links. I will make that
    There is no fixed screen size - except that the site is coded for
    resolution, so the maximum width of all the page elements is 744
    Coding for an 800x600 screen resolution is about as low as anyone can 
    realistically go today - in my opionion. If you're refferring to the 
    JavaScript, that does not create a fixed window size, only addresses
  what I 
    mentioned earlier.
    We've had some problems with external style sheets in some versions of
    Netscape 4.x - which is why this is in the index page. I don't know
  what the 
    issue is, nor can we faithfully replicate it.
    Finally, much of the source code is due to Netscape. The page was
    coded for IE4.0 and better, then reworked to work in Netscape. This
  was what 
    we came up with. I suppose we're all stuck with code that isn't as
  clean as 
    we'd like until Netscape opts to support more of the W3C's HTML4 and
    Recommendations. The page was at least 1/2 the size before we added 
    functionality in Netscape.
    Again, thanks for the comments!
    Joel Sanda
    ----Original Message Follows----
    From: Charles McCathieNevile <charles@w3.org>
    To: Joel Sanda <joels@ecollege.com>
    CC: "'w3c-wai-ig@w3.org'" <w3c-wai-ig@w3.org>
    Subject: Re: CSS-P Site Built For Accessibility
    Date: Sat, 8 Jan 2000 00:15:33 -0500 (EST)
    5 minute review impressions...
    It is unclear to me why javascript is necesary - I used a text and a
    browser to check it out without a lot of problem except where the
  links were
    javascript references for a new window. This is not helpful for
    in general, and doing it through Javascript is a bad idea in
    Where there are audio/video versions of information it would be
  helpful to
    provide more details about what they are - for example instead of the 
    code something like
    <p><a href="videofile"><img src="realvideo_icon" alt="welcome message
    (video)"></a>&nbsp;&nbsp;<A href="videofile">Welcome message
    something like
    <p><a href="videofile" title="Welcome message, real Video
    src="realvideo_icon" alt="Real Video" title="Real Video Icon"><span
    class="nounderline">&nbsp;&nbsp;&nbsp;</span>Welcome message
    would be nice - provides the fact that it is realvideo (you should
  also use 
    type attribute in the a element to do this in a machine-readable way)
  to the
    user, and means tere is one link not two - having to skip through
    redundant links is something worth avoiding if possible - especially
  with a
    head-switch or similarly slow input system.
    Requiring a fixed screen size is not very helpful and should be
  avoided -
    people who are using magnified screens (or even just getting the
    by using a 30 or 40 pt font) are then unable to avoid having the
  problem of
    scrolling horizontally as well as verticaly, which is a serious
    For the rollover functions it would be nice to make them work for
    users - add an onFocus/onBlur set of triggers.
    In general the text alternatives seem to be done intelligently. It
    probably have made more sense to use a single external stylesheet. And
    a regular image-naming schema you could write a short function to find
    names, and reduce the size of the page source by a substantial amount.
    Charles McCN
    Charles McCathieNevile    mailto:charles@w3.org    phone: +61 409 134
    W3C Web Accessibility Initiative
    21 Mitchell Street, Footscray, VIC 3011,  Australia
    On Thu, 6 Jan 2000, Joel Sanda wrote:
       I'm a webmaster for eCollege.com - a company that puts schools on
       Internet with a variety of solutions for online and distance
       have been researching and implementing W3C WAI standards, and have
  a site 
       would like some feedback on. Our most recent attempt employs CSS 
       for nearly all layout. There are minor exceptions where we had to
       simple (no embedded) tables to ensure consistent formatting for
       Netscape and Microsoft browsers.
       The site is at http://online.luc.edu/, and should comply with all
       Priority 1 Recommendations, with a few minor exceptions. Some of
       areas do not yet have text-based versions available, although we do
       video and audio version.
       I have used JAWS 3.31 on the site, and it seems to do fairly well
       navigation and content. The site also passed Bobby and the W3C's
       Any feedback would be greatly appreciated!
       Joel Sanda
       10200 A East Girard Avenue
       Denver, CO 80231
       phone	303.873.7400  ext.3021
       fax    	303.873.7449
       "Educators Working for Educators"
    Charles McCathieNevile    mailto:charles@w3.org    phone: +61 409 134
    W3C Web Accessibility Initiative
    21 Mitchell Street, Footscray, VIC 3011,  Australia (I've moved!)
    Get Your Private, Free Email at http://www.hotmail.com
  Charles McCathieNevile    mailto:charles@w3.org    phone: +61 409 134
  W3C Web Accessibility Initiative
  21 Mitchell Street, Footscray, VIC 3011,  Australia (I've moved!)

Charles McCathieNevile    mailto:charles@w3.org    phone: +61 409 134 136
W3C Web Accessibility Initiative                    http://www.w3.org/WAI
21 Mitchell Street, Footscray, VIC 3011,  Australia (I've moved!)
Received on Sunday, 9 January 2000 07:41:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:07 UTC