- 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>
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> <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"> </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 UTC