[thelist] When should you redirect? (was site redirect check)

[martin.p.burns at uk.pwcglobal.com]

Memo from Martin P Burns of PricewaterhouseCoopers

-------------------- Start of message text --------------------





Please respond to thelist at lists.evolt.org

Sent by:  thelist-admin at lists.evolt.org

To:   thelist at lists.evolt.org
cc:


Subject:  RE: [thelist] When should you redirect? (was site redirect check)


>The question still remains -  is a redirect appropriate for sites which
>don't cater for certain categories of visitors, whether browser or some
>other factor is the determinant.  For example, flash only sites and text
>based browsers.  Or, sites designed for Win and any Mac user.

There are another couple of questions before this - is it appropriate to
design a site which *is* Flash only, or Win only?

If so, when?

>>-----Original Message-----
>>From: thelist-admin at lists.evolt.org
>>[mailto:thelist-admin at lists.evolt.org]On Behalf Of Martin
>>

>>I don't think avoiding event listeners would cause unjustifiable
>>hardship...

>I don't think not coding  a base font size, avoiding nested tables and
>avoiding using colour to indicate incorrect information entered into a
form
>would cause unjustifiable hardship either.  What's your point?  Are you
>suggesting that I shouldn't use event listeners because it won't be
>accessible?  event listeners on the ranger site are used for effects which
>sighted users expect.  It is still useable (mostly) without js (actually
it
>is getting more usable all the time thanks to suggestions from .jeff)

Sorry, my fault. That was shorthand for "avoiding Javascript as a
necessity for accessing the site's core functionality"

Nothing wrong with doing something which gives *added* value beyond
the core functionality to capable browsers as long as it degrades
gracefully.

An example - most forms I've done for UK users have a wee JS function which
simply uppercases the postcode (as upper case is the standard format)
onChange. Degrades beautifully and is just an extra wee bit of niceness to
users.

>The same can't be said of the fact that I've taken the underlines off the
>links and identified them with a  colour change - fine for sighted users
but
>not very helpful if you are colour blind.

More significant with low-contrast colour changes, but yes, you're
right.

>I'm not thrilled about the use of images for the nav menu either - to try
>and allow for that each A tag has a title, each img has an alt and they
are
>the same - I thought this would help people with aural browsers understand
>what was happening.

If you *really* can't use real text, then this is a good substitute.

>Flash nav menus must be a problem for aural browsers -
>are you suggesting nobody should use those?

It's something I'd advise extreme caution over, yes.

>The internet is a global medium - I think that quoting Australian
>legislation is only part of the story.  Even if the Australian legislation
>is the most restrictive (ha - Australian politicians think they can ban
>online gambling) isn't the issue that sites need to cater for all global
>legislation - there is a possibility that the owners of a website could be
>sued by anyone anywhere?

Yes. Look at the French suing Yahoo. There's a case at the moment
where an Australian is suing some Californian outfit for defamation
in the Australian courts. However, for disability legislation, you could
possibly get away with arguing the case for the juristiction of your target
audience to apply. If that's global, you're out of luck (vide the SOCOG
case)

But I haven't seen a juristiction yet where disability explicit legislation
or
working practise to general legislation hasn't been based on WAI
guidelines.

Plus it's generally good practise to make sites accessible - think of it
as an easy expansion of your potential market.

>Are we getting to the stage where browser differences
>will be the least of the worries and catering for people with disabilities
-
>most of which you can't test for

You can, but it's a bit more tricky - you need to get real people to test
it for you. But you'll be doing this anyway in the name of usability,
surely..?

>- will be the real issue.
Probably, yes.

>hmmm - I think I'd better start learning a couple of server side
languages!

Always useful... they have 2 advantages:
* You can cope with any user agent variations
* Most things you do are transparent to users (ie they don't notice that
they're
  getting something different unless another user is next to them - it just
works)


Cheers
Martin

--------------------- End of message text --------------------

The principal place of business of PricewaterhouseCoopers and its associate
partnerships is 1 Embankment Place, London WC2N 6NN where lists of the
partners' names are available for inspection. All partners in the associate
partnerships are authorised to conduct business as agents of, and all
contracts for services to clients are with, PricewaterhouseCoopers. The UK
firm of PricewaterhouseCoopers is authorised by the Institute of Chartered
Accountants in England and Wales to carry on investment business.
PricewaterhouseCoopers is a member of the world-wide
PricewaterhouseCoopers organisation.
----------------------------------------------------------------
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.   If you received
this in error, please contact the sender and delete the material from any
computer.