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

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

Cheers

Charles McCN


On Sun, 9 Jan 2000, Joel Sanda wrote:

  Charles;
  
  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!
  
  Regards;
  
  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
  
  Joel,
  
  In questionging the necessity of Javascript I was referring to it as a
  browser requirement - there seems to be ittle if any functionality
  provided
  by the Javascript that cannot either be replicated by a more widely
  accesible
  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
  past
  - there are regularly people operating on a smaller screen than 800x600,
  either through hardware restrictions, magnification, only having a
  partial
  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
  available.
  
  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
  am
  not sure if Javascript is really a requirement).
  
  Congratulations again on the good work - Keep it up *grin*
  
  cheers
  
  Charles McCN
  
  
  
  On Fri, 7 Jan 2000, Joel Sanda wrote:
  
    Charles;
    
    Thanks for your response and critique. I hope my responses can explain
  why 
    we chose to do some things the way we did.
    
    The JavaScript is necessary to maintain the page layout in Netscape
  browsers 
    when the window is resized. As we all know, you resize a window in
  Netscape 
    and the CSS-P is thrown out the window. That JavaScript forces a
  reload, 
    which restores the CSS-P formatting. It's actually a modification of
  some 
    JavaScript published by O'Reilly in one of their JavaScript books -
  there 
    version is buggy in a couple of Netscape 4.x versions, particularly on
  the 
    Mac.
    
    Great feedback on the video and audio links. I will make that
  correction 
    Monday.
    
    There is no fixed screen size - except that the site is coded for
  800x600 
    resolution, so the maximum width of all the page elements is 744
  pixels. 
    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
  originally 
    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
  CSS2 
    Recommendations. The page was at least 1/2 the size before we added 
    functionality in Netscape.
    
    Again, thanks for the comments!
    
    Regards;
    
    Joel Sanda
    Webmaster
    eCollege.com
    
    
    ----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
  graphic
    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
  accessiblity
    in general, and doing it through Javascript is a bad idea in
  particular.
    
    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 
    current
    code something like
    
    <p><a href="videofile"><img src="realvideo_icon" alt="welcome message
    (video)"></a>&nbsp;&nbsp;<A href="videofile">Welcome message
  (video)</a></p>
    
    something like
    
    <p><a href="videofile" title="Welcome message, real Video
  version"><img
    src="realvideo_icon" alt="Real Video" title="Real Video Icon"><span
    class="nounderline">&nbsp;&nbsp;&nbsp;</span>Welcome message
  (video)</a></p>
    
    would be nice - provides the fact that it is realvideo (you should
  also use 
    a
    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
  multiple
    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
  crucial 
    bits
    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
  hassle.
    
    For the rollover functions it would be nice to make them work for
  non-mouse
    users - add an onFocus/onBlur set of triggers.
    
    In general the text alternatives seem to be done intelligently. It
  would
    probably have made more sense to use a single external stylesheet. And
  given
    a regular image-naming schema you could write a short function to find
  the
    names, and reduce the size of the page source by a substantial amount.
    
    Cheers,
    
    Charles McCN
    
    --
    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
    
    On Thu, 6 Jan 2000, Joel Sanda wrote:
    
       Hi;
    
       I'm a webmaster for eCollege.com - a company that puts schools on
  the
       Internet with a variety of solutions for online and distance
  education. 
    We
       have been researching and implementing W3C WAI standards, and have
  a site 
    we
       would like some feedback on. Our most recent attempt employs CSS 
    Positioning
       for nearly all layout. There are minor exceptions where we had to
  insert
       simple (no embedded) tables to ensure consistent formatting for
  both
       Netscape and Microsoft browsers.
    
       The site is at http://online.luc.edu/, and should comply with all
  WAI
       Priority 1 Recommendations, with a few minor exceptions. Some of
  the 
    content
       areas do not yet have text-based versions available, although we do
  have 
    a
       video and audio version.
    
       I have used JAWS 3.31 on the site, and it seems to do fairly well
  with 
    site
       navigation and content. The site also passed Bobby and the W3C's
  CSS
       Validator.
    
       Any feedback would be greatly appreciated!
    
       Joel Sanda
       Webmaster
    
       eCollege.com
       10200 A East Girard Avenue
       Denver, CO 80231
    
       phone	303.873.7400  ext.3021
       fax    	303.873.7449
    
       "Educators Working for Educators"
       www.eCollege.com
    
    
    --
    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!)
    
    
    ______________________________________________________
    Get Your Private, Free Email at http://www.hotmail.com
    
  
  --
  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!)
  

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

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:13:47 GMT