RE: rationalize presentation [was: Use consistent presentation]

I don't believe an appropriate markup exists that can convey the same
information that images in navigation bars do.  It would be a sad day
for accessibility if the only way to make a AA or AAA site would be to
remove graphical navigation bars.

-----Original Message-----
From: gdeering [mailto:gdeering@acslink.net.au]
Sent: Monday, 14 January 2002 6:31 PM
To: Gian Sampson-Wild
Subject: RE: rationalize presentation [was: Use consistent presentation]


I don't know how you can claim it is AAA when Checkpoint 3.1 says; "When
an
appropriate markup language exists, use markup rather than images to
convey
information" (Priority 2).

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]On
Behalf
Of gian@stanleymilford.com.au
Sent: Friday, 11 January 2002 9:55 AM
To: w3c-wai-gl@w3.org
Subject: RE: rationalize presentation [was: Use consistent presentation]


I wasn't talking about a large graphic-intensive site, just the use of
images in navigation bars.  I have designed AAA sites that use this kind
of graphical navigation

-----Original Message-----
From: gdeering [mailto:gdeering@acslink.net.au]
Sent: Friday, 11 January 2002 7:34 AM
To: ESlaydon; Gian Sampson-Wild; w3c-wai-gl
Subject: RE: rationalize presentation [was: Use consistent presentation]


Yes, I am well aware of that, and constantly experience that mentality
with
clients myself, and I guess all of us have been overpowered by the clout
of
various marketing departments when they insist upon such designs.

But at the same time, there is an industry out there (which I am also a
part
of), that is asked to repair bloated, inaccessible sites or redesign
bandwidth heavy sites.  These clients realise they have a problem; they
get
complaints, their web logs tell them there are problems, and
inaccessible by
low bandwidth users who turn graphics off or are timed out.  It is not
unusual for these sites to get 75% of their web accesses going no
further
than the home page, especially if they have Flash splash screens or the
like.  That is a different kind of accessibility problem.

Yes, they will always want these sites first, and if they insist, you
have
to give them what they want.  But I also see it as part of our job as
web
professionals to tell them about the penalties they will incur; audience
loss, alienation, etc, they will suffer because of this.

By and large, if you are going to serve up a large graphic intensive
site
you need to have the images on a separate server to handle all the
separate
http/tcp.ip requests and cache the images into memory to avoid disk
reads.
This is how the good large sites manage.  There are a lot of things to
consider in order to successfully implement this strategy.

The point is to educate the client.  Give them the whole pros and cons.
Give them very real data and case study and usability experiences.  Then
it's their decision, and you can't be blamed if they come back to you
and
say there is a problem, because you forewarned them.  That's our job, I
feel; especially as accessibility professionals.

Geoff Deering
http://www.acslink.aone.net.au/gdeering/



-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]On
Behalf
Of Slaydon, Eugenia
Sent: Thursday, 10 January 2002 1:25 PM
To: 'gdeering@acslink.net.au'; gian@stanleymilford.com.au;
w3c-wai-gl@w3.org
Subject: RE: rationalize presentation [was: Use consistent presentation]

I have to disagree. It isn't always the case that the designers are
unwilling to abandon pixel based designs. They have to deliver what the
clients want. And in this day and age of huge, flash driven, moving
pictures, animated navigation, etc., the clients are seeing and WANTING
certain graphical looks. They also want them to work in multiple
browsers.
Even though most browsers are CSS capable - they don't handle it the
same
way. There are still what I consider severe limitations with CSS. You
may
lay something out beautifully with IE and have it totally unusable in NN
or
vice versa. I do agree that we should encourage designers to move their
designs to a more accessible, liquid design approach. But we also have
to
realize that the clients control the ultimate result.

Thanks,
Eugenia Slaydon
Lead Content Developer
Beacon Technologies, Inc.
336-931-1295 ext. 225


-----Original Message-----
From: Geoff Deering [mailto:gdeering@acslink.net.au]
Sent: Wednesday, January 09, 2002 6:33 PM
To: gian@stanleymilford.com.au; w3c-wai-gl@w3.org
Subject: RE: rationalize presentation [was: Use consistent presentation]


I take your point, and I agree designers have an unwillingness to
abandon
their pixel based design tools for a more liquid based design approach,
but
I don't agree with you that markup has not progressed to the point of
placing graphical navigation.

Most analysis of current web logs shows a very very high percentage of
CSS
capable browsers (eg
http://thecounter.com/stats/2002/January/browser.php).
So designers should know that most people are seeing their design as
they
designed it, or close to it.  It is also becoming uneconomical to design
navigation using pixel based designs as more and more sites require data
driven generation of pages.  All major News sites, and any site that
produces a large amount of information uses this approach.

Designers can still control the fonts, colors, text and hover effects,
and,
most importantly it scales better. There are so many benefits from at
least
abandoning graphic labels in navigation.  I know designers are
reluctant,
but it I feel it is more from habit and having a fixed pixel based 800 x
600
mentality, that being restricted by the markup.  Also pixel based
graphics
navigation can look terrible and difficult to read under certain
resolutions.

Re: Checkpoint 3.1 WCAG1.

If you have specific instances, can you please refer to them?

My feeling is that at this point, preparing WCAG2, if we DO feel that
pixel
based graphics navigation is still a legitimate choice, then WCAG2 needs
reorientation.  There seems to be a great change from WCAG1 to WCAG2.
WCAG1
set out the 3 levels of Priority, and if you have a site designed
according
to any flavour, you can still go over it and adopt all the Priority 1
recommendations to repair it to make it more accessible without
fundamentally causing a redesign.  Unfortunately a lot of companies
(like my
last place of work) just use Bobby to get a Priority 1 error free
report.
It does not matter that Bobby did not pick up that there were no
<NOSCRIPT>
tags for each <SCRIPT> tag (6.3).

WCAG2 seems to have moved beyond that approach.  It seems to be saying,
in
this place and time: this is the way to address markup in order to
address
accessibility (I am making my own assumption here, please correct me).
If a
designer really looks at this thoroughly, they should not feel that
their
freedom and creativity are being taken away, instead, it is our job to
show,
teach and communicate how they can be just as creative, and more so,
while
also making their design more accessible and usable.

I do feel that the delivery technology is up to this, but the basic
design
tools definitely are not.  In good web teams, it is often best for the
designer to produce the design in their pixel based tools, then a
HTML/CSS/WAI specialist take that design and render it in markup.  1)
Because the tools just aren't good enough, and may not be for a long
time,
and 2) Most designers cannot come to terms with a liquid design
approach.

Geoff Deering
http://www.acslink.aone.net.au/gdeering/

My two cents on this issue is that appropriate markup for navigation
(HTML/XML/CSS/XSL) has not progressed to the point of being able to
replace graphical navigation. Until that is the case designers will want
to use graphical navigation ahead of any markup.

Gian

-----Original Message-----
From: gdeering [mailto:gdeering@acslink.net.au]
Sent: Tuesday, 8 January 2002 5:53 PM
To: asgilman; w3c-wai-gl
Subject: RE: rationalize presentation [was: Use consistent presentation]


I feel this is an important distinction.  WCAG2 seems to have advanced
quite
a way from WCAG1 in the way it now focuses accessibility issues for
online
producers.  To me, WCAG2 does not seem like a clarification of WCAG1,
which
is what was originally intended, but a redefining and refinement of core
issues of Web Content Accessibility.

It seems a powerful statement that WCAG2 starts with Guideline 1;
putting
the focus back on the users needs and preferences.  This was one of the
main
objectives of CSS; the power of design, so that the author based design
could easily be overridden or substituted by the users own CSS.  This
seems
to be lost on most of the web designers.  If this is lost on most web
designers, it is difficult enough for them to come to terms with a model
where the user is actually in control of the form and how they
assimilate
the content.

It is very hard as a designer to feel that your site could or should be
"skinned" (have another CSS wrapper put around it, other than your own).
This is an ideal, but very hard to achieve or deliver for the simple
reason
of using abstract class definitions that a base User CSS will not
implement.
Still basic declarations like font properties, etc, should be able to be
skinned.

What strikes me most about WCAG2 as compared with WCAG1 is the
refocusing
back on marking up content to facilitate full accessibility to all
users.
With such focus in WCAG2 on user control, there seems to be an implicit
statement that presentation markup follows strict guidelines and syntax
(correct use of CSS / XSL), and these are the type of guidelines that
say;
"Markup your document's presentation style in such a way that users can
enforce their own style and rules on your documents and sites".

If this is the intention, what are the cases for using navigation bars
comprised of graphic images?  It seems in WCAG2 we have gone beyond
that,
saying now that there is an appropriate markup for navigation
(HTML/XML/CSS/XSL), graphic text images are obsolete.

Is this the implication?  Or am I missing something?

Geoff Deering





-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]On
Behalf
Of Al Gilman
Sent: Saturday, 5 January 2002 3:15 AM
To: w3c-wai-gl@w3.org
Subject: rationalize presentation [was: Use consistent presentation]

Well, we are building a problem for ourselves as soon as we use
'consistent' as
the headline.  This sends too superficial a message.  It creates an
appearance
that consistency of appearance is the success criterion, whereas this is
not
the point.  What we are after is a consistent relationship between
variations
in appearance and distinctions in the rhetoric of the site content.

The success criterion here is that most presentation differences within
the
site can be explained by a systematic binding [pattern of relationship]
of
presentation effects to one consistent set of organizing principles
across
the
whole site.  The organizing principles cover concepts not only of parts
of
the
whole but also kinds of stuff found here.  This includes both
similarities
and
differences.  It is possible to quantify this criterion with entropy
measures.

What the content provider should accomplish is a balance of a dominant
core
rationality - functional application of effects - and a light ripple of
dither
- un-rationalized variation - to combat highway hypnosis.

If we just say "rationalize your presentation" and people do this to the
max,
the result _will_ be boring.  A modicum of reasonableness is required in
how we
try to get people to curb their wildest flights of fancy and employ
discipline
in presentation.

The rational core (of presentation decisions) follows the XAG
injunctions:
- have a model
- bind the model to interface specifics
- stick to this plan
- share the reasoning for those who have to re-bind

Changes in presentation are rocks that turn over.  People expect to find
information under those rocks.  When there is no sense to the change,
then
all
distinctions are treated as senseless.  The consistent styling of
navbars
etc.
to indicate the consistent functional role that they play across
different
pages will be defeated if one does not at the same time hold to a dull
roar
changes in presentation that are _not_ explainable by site-organizing
principles.

What Gian has had trouble selling to his customers is good design.
Exceptional
presentation for exceptional circumstances.  It is all backed up by a
well-developed design concept or model.  But the neanderthals with the
money
don't have a basis for judging what is a bona-fide exceptional
circumstance,
unfortunately.  So they cling to shallow rules that actually work
against
the
application of the better, deeper, rule.

Not a problem with a simple answer, because in many situations we need
to
rely
on the funding authorities to sit on the heads of the designers and make
them
exercise some discipline in addressing access issues.

Al

At 07:07 PM 2002-01-03 , gian@stanleymilford.com.au wrote:
>Hi,
>
>I think we had a very productive meeting this morning.
>
>On the subject of consistency of presentation, I think what we are
>trying to say (while still following our own guideline 14.1!) is that
>the presentation is similar in design throughout the entire site, and
>over a finite period of time (as in, one does not expect the
>presentation to continually change on a week-to-week basis).  I did go
>talk to one of our graphics designers and he did not like the word
>'predictable'!  So perhaps we can consider other words.  A search in
the
>thesaurus for predictable found:
>- obvious
>- unsuprising
>- expected
>- anticipated
>- evident
>- observable
>A search in the thesaurus for consistent found:
>- reliable
>- constant
>- uniform
>
>And secondly, on the actual amount of consistency, I have found myself
>arguing against the guidelines when discussing this checkpoint with
>project managers. For a large site I usually advocate the use of
>secondary navigation appearing when on a particular page (for an
example
>see
<http://hnb.dhs.vic.gov.au/ds/disabilitysite.nsf/pages/prov%A0vs>http://
hnb.
dhs.vic.gov.au/ds/disabilitysite.nsf/pages/prov vs
><http://hnb.dhs.vic.gov.au/ds/disabilitysite.nsf/pages/prog%A0or>http:/
/hn
b.dhs.vic.gov.au/ds/disabilitysite.nsf/pages/prog or
><http://www.womensultrasound.com.au/dev/ultra.html>http://www.womensult
ras
ound.com.au/dev/ultra.html).  However when I
>suggest this I get checkpoint 13.4 thrown at me and told that it can't
>be done (usually I then ask why they have employed me if they aren't
>going to listen to me- as you can tell this is a sore point!).  So I
>believe we should somehow incorporate these navigational mechanisms
into
>the guidelines, or at the very least, ensure that they aren't outlawed
>by the guidelines.  The other thing to consider is the use of
breadcrumb
>trails (see:
><http://www.legalonline.vic.gov.au/CA2569020010C266/All/7002B178A09E591
EC>
http://www.legalonline.vic.gov.au/CA2569020010C266/All/7002B178A09E591EC
>A256958002682E1?OpenDocument&1=Lifestyle~&2=Drugs~&3=Drug+use+and+the+l
a
>w~ or
><http://www.doi.vic.gov.au/doi/internet/transport.nsf/headingpagesdispl
ay>
http://www.doi.vic.gov.au/doi/internet/transport.nsf/headingpagesdisplay
>/transport+projectsgreat+ocean+roadstrategy+process+and+timing).
>Breadcrumb trails are a very good way of indicating where in the site
>you are, especially for those sites that are very large.
>
>Happy New Year to everyone!
>
>Cheers,
>Gian
>
>Gian Sampson-Wild
>Consultant
>
>Member: Web Content Accessibility Group Working Group
>W3C Web Accessibility Initiative
>
>Stanley & Milford
>A Software Communication Group Company
>Level 16
>644 Chapel Street
>South Yarra VIC 3141
>Australia
>Tel. 613 9826 5829
>Fax. 613 9826 8336
>Mob. 0404 498 030
>Email gian@stanleymilford.com.au
>
>********************************************
>This message contains privileged and confidential information intended
>only for the use of the addressee named above. If you are not the
>intended recipient of this message you must not disseminate, copy or
>take any action in reliance on it. If you have received this message in
>error, please notify Software Communication Group immediately. Any
views
>expressed in this message are those of the individual sender except
>where the sender specifically states them to be the views of Software
>Communication Group.
>********************************************
>
>
>
>
>