RE: checkpoint 3.1 RE: rationalize presentation

I think there is a whole new design approach once you move out of the WCAG1
Priority 1 Guidelines into the Priority 2.  In Priority 1 you can use many
different techniques; images for text, tables for layout, etc, but the
Priority 2 Checkpoints mean a whole new design strategy (in my opinion);

1. Separate content from display markup - HTML (XML) for content CSS XSL)
for display. (Re Checkpoints 3.3, 11.1, 11.2, etc)
2. Use Markup rather than images (Re Checkpoints 3.1)
3. I would also say that using images for text breaks the spirit of 3.4, as
well as not using them in CSS.

When you put all the other Checkpoints in P2 together, that makes AA a very
strict approach to design.  If you aren't complying with the P2 guidelines
completely, you are back at single A, which there is nothing wrong with;
it's just how you have designed.

If you are designing with AA (or AAA) in mind, you are willing to hand your
design over to the user, as is the spirit of CSS2.  Your basic design will
be what most people see anyway, and it can be extremely elegant (I feel CSS
is powerful enough, but needs more adoption), but you know when you design
with this approach that you are giving a lot of control to the user.

It seems that in WCAG2 Checkpoints 1 & 4 are very focused on giving the user
as much control as possible, and I only see this as being achievable and
compliant if designers understand and follow P2 guidelines, and the approach
to move as much of display markup into W3C assistive technologies; CSS, XSL,
SVG, SMIL, etc.  If they only use some of them, fine, that's great.  But if
there is going to be some method of classifying web pages to meet criteria
such as A, AA, and AAA, it needs to be very clear, what the criteria are to
meet them.  Whatever the answer, it needs to be clarified, and clear for
people who read the guidelines.

I don't see this as shutting out designs that use images for text; it's just
where the various levels of compliance are clearly defined.


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

-----Original Message-----
From: Kynn Bartlett [mailto:kynn-edapta@idyllmtn.com]
Sent: Monday, 21 January 2002 12:43 PM
To: Charles McCathieNevile
Cc: gdeering@acslink.net.au; WAI GL
Subject: Re: checkpoint 3.1 RE: rationalize presentation

At 3:07 PM -0500 1/20/02, Charles McCathieNevile wrote:
>I don't claim total enlightenment, but maybe the following thoughts based
on
>experience will do...
>
>There are a couple of things we were trying to achieve with the checkpoint
>(as I recall the history). One was to avoid relying on (here Kynn's point
>about wording is clearly relevant) images of text, for reasons already
>discussed. And yes, SVG does provide a way around this and so would be
>considered "markup" not an image.
>
>The other was finding images of mathmatical content, or chemical formulae,
>instead of some kind of markup version rather than as well as.
>
>My take on using bitmap images of text is that if the content of the text
is
>meant to be read (rather than the overall shpae being recognised, as in a
>logo - w3c uses the same logo in all scripts, but uses arabic script for
>arabic text) then don't use an image. Most particulrly this applies to
>navigation bar text - in my opinion among the most important text on azn
>average page.
>
>On the other hand, for something like Maths or chemistry, providing an
image
>as one alternative, with other recognised formats - mathML or cheML and
>LaTeX - can be a useful thing to do.

I think that maybe we need to recognize this as two checkpoints.  Ideally,
one checkpoint should not be serving two different cases with different
justifications, because then it makes it much harder to understand what
the checkpoint is about.  We want to minimize confusion, and one way to
do that is to avoid OVER-simplifying to the point where we have one
checkpoint which means two things.

Even so, the idea of the W3C's logo is still problematic here; W3C
itself uses text in logos, so I think that an absolute prohibition
for dogmatic reasons rather than practical -- i.e. if the content is
still available and accessible you STILL can't put text in an image
-- will only lead to confusion.  I would rather have an easy to
understand and easy to use accessible solution that says "use both"
than a complex and footnoted and incomprehensible one that tries to
define each case in which you "can" and "cannot" put text in an image.

--Kynn

--
Kynn Bartlett <kynn@idyllmtn.com>                 http://kynn.com
Chief Technologist, Idyll Mountain            http://idyllmtn.com
Web Accessibility Expert-for-hire          http://kynn.com/resume
January Web Accessibility eCourse           http://kynn.com/+d201
Forthcoming: Teach Yourself CSS in 24 Hours

Received on Monday, 21 January 2002 02:03:21 UTC