RE: CSS-P Site Built For Accessibility

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

Received on Sunday, 9 January 2000 04:25:23 UTC