Coding for intranets (was RE: [thelist] Color Chooser Review -- correction)

Shirley Kaiser, SKDesigns skaiser1 at skdesigns.com
Wed May 29 14:59:01 CDT 2002


Tom,

At 12:24 PM 5/29/2002, you typed:

>Shirly, very well said.

Ah, thanks. :-)

>I've been trying to say all along that I don't disagree with standards or
>accessiblity, etc. Sure, writing standardized code will (most likely) help
>you in the future,
>regardless of what you are building.

That's the idea that we're working toward, at least!

>But I was hired to perform a certain function, and I was given the
>parameters that I have to work
>in. Were I hired and told "write HTML 4.0 validating code that is
>accessible to all disabled
>persons and works in any browser" then - I would.
>
>However, I've been hired and told to write DHTML and JS code that works
>only in IE5+, and to also
>make generous use of VML as well. Besides that, our application connects
>with all kinds of other
>things, including Windows apps - which obviously would not work on a Mac,
>either.

I haven't had a chance to read all the posts in this thread. I jumped in
with Joel's note just a bit ago.

But as I mentioned, if you're building an Intranet, the typical world-wide
accessibility rules may be different, of course. And if you're told to do
what you mention above, they may not have a clue about cross-browser,
cross-platform issues at all (and it may not immediately matter now but
could down the line). I'd personally consider explaining the details to
them (with a follow-up in writing to cover yourself.... as you'll see with
what I write next) about accessibility and standards and that if they
switch browsers that it could mean having to re-do markup and code. Then
they can't come back later and say, "hey, you idiot, this doesn't work with
our new browser." They'll know ahead of time that switching browsers (or
maybe even platforms) will mean the site breaking and will necessitate some
code and markup changes.

So I really think each situation must be evaluated on its own merits, and
that evaluation must be based on understanding and being educated about the
variabilities.

>I love WaSP, I love Zeldman (actually got a chance to meet and talk to
>him) and his work, I wish
>we had cross-platform standards!

I adore him, too. I'm also on the WaSP steering committee. :-)  We've been
quiet while we're working on stuff behind-the-scenes. We're close to
launching a new site design with new material, too. So stay tuned. :-)

>But I also love writing snazzy DHTML/JS code for IE5+ that Martin and Jeff
>hate - but my employer
>likes.

Quite understandable that you enjoy that. It's cool stuff! I haven't read
Martin's and Jeff's comments or the rest of this thread, so I can't comment
about any of that. My own view <em>in general</em> is that these
technologies certainly have their place and purpose. If it's just a bell
and whistle for an Internet site that causes accessibility and/or usability
problems, I'm not excited, though.

>BTW - let's not confuse "accessibility" with "usability". Although they
>can be linked, they are
>not the same thing.

Exactly.

>I've seen plenty of DHTML and Flash interfaces that were plenty usable (and
>very "cool"), and not even remotely "accessible."

Yep. It's how they're designed and implemented. :-)

Warmly,
Shirley
--
Shirley E. Kaiser, M.A.,  SKDesigns  mailto:skaiser1 at skdesigns.com
Website Design, Development      http://www.skdesigns.com/
WebsiteTips: Design Resources  http://www.websitetips.com/
Brainstorms and Raves  http://www.brainstormsandraves.com/
WaSP Steering Committee       http://www.webstandards.org/

>Tom
>
>
>--- "Shirley Kaiser, SKDesigns" <skaiser1 at skdesigns.com> wrote:
> > At 06:11 PM 5/28/2002, you typed:
> > >.jeff, rudy, whoever -
> > >
> > >You both know I share your feelings about usability, accessibility, etc.
> > >You've both commented on practical application of these concepts in a
> closed
> > >environment.
> > >
> > >If I control the environment (and will continue to control it unless I
> leave
> > >the company) what are the dangers of browser specific coding?
> >
> > Well, what if you decide you want to switch from using browser A to browser
> > B for some reason? (such as if browser A's upgrades aren't as good as
> > browser B anymore, or maybe browser B didn't even exist awhile back.....)
> >
> > Either way, though, if you continue to create your Internet with standards
> > in mind, accessibility in mind, usability in mind, you won't have as many
> > switch-over problems if you continue to work with a standards-oriented
> > browser. You'll have that particular browser's quirks to contend with, of
> > course, since each browser company doesn't interpret the W3C
> > recommendations the same (and a few of the recommendations are still vague
> > enough that this has happened -- see Jeffrey Zeldman's weblog
> > <http://www.zeldman.com/> where he's written about this within the past
> > month or two especially).
> >
> > So in the long run, it saves the company money.... the bottom line that
> > companies usually appreciate and want.
> >
> > No browser is perfect (and don't we all know that?!?!? Geesh) and each has
> > its strong and weak points and will mean changes to your Internet web pages
> > in some way if it changes.
> >
> > And if you leave and someone else takes over and decides to take another
> > approach, well, it ought to be easier, hopefully, on the next person, too.
> >
> > >Or, in Tom's
> > >case, if it's not possible for a blind or other special user to even
> access
> > >the system, what are the real-world problems with coding with that in
> mind?
> >
> > Any chance of having a blind employee? While I don't mean this at all in a
> > discriminatory way, there are tasks that one must be sighted to do, while
> > others can do fine whether sighted or not.
> >
> > Seems to me that if you don't have any blind employees right now (or other
> > disabilities) and you're working with standards in mind that it would be
> > easy enough to accommodate down the line if it comes up.
> >
> > I would have a different opinion for a Web site open to the world, of
> > course. Intranets are different, though.
> >
> > >Are there cases where the rules can legitimately be ignored?
> >
> > I wouldn't say so much "ignore" as choose not to implement at the moment,
> > keeping in mind that it could change in the future and allowing for that
> > possibility to ensure a smoother transition if needed.
> >
> > Warmly,
> > Shirley




More information about the thelist mailing list