Re: Minutes from 16 November 2000 WCAG WG telecon

At 11:33 PM +0000 11/22/00, Sean B. Palmer wrote:
><font size="+1"> would be better as <big> and then use a style sheet to say
>how much bigger big is. +1 doesn't really mean much, but 1.1em means 1.1
>times larger, typographically speaking.

I don't agree with the conclusion that "+1" doesn't mean much.  It's
decently well defined enough and some browsers allow the users to set
the scale explictly.

>Long story short, using the font tag
>means that people are forced to some extent to put up with what the browser
>decides is +1 bigger, whereas using semantic markup, it is up to the user,
>whos opinions and requirements of "big" vary from person to person. e.g.
>Aural browser users could increase the volume, but a font change to them
>would be otherwise inapparent!

This argument seems to fold back on itself several times -- I don't
see how <big> is any better than <font size="+1">; are you saying that
<big> is semantic and not presentational?

You've said before that <b> shouldn't be used, because it is not semantic
and only specifies a textual change.  And it is correct that <b> is only
defined for text; but likewise, <big> is a textual formatting tag of
the same type as <b>.  They are defined in the same place in the HTML
4.01 specification, and that describes each as:

      B: Renders as bold text style.
      BIG: Renders text in a "large" font.

So if <b> is to be avoided, so is <big>.

You argue here that Aural browsers could increase the volume of <big>,
but that was what was suggested for <b>, and you didn't find that
argument compelling.  What exactly do you see as the difference between
these two text formatting tags?  Neither one explicitly states that
it should be used in any way by a non-textual user agent.

>As for background, there aren't many occasions when a background image is
>vital to a page, is there?

That would really be up to the creator of the page to determine, I'd
think.  There are some cases in which someone would consider a background
image to be very important for visual users to understand and using the
page; we need to be careful about not dismissing these needs out of
hand.

>Even if it is, by hard wiring it into the page,
>you are making it very difficult for people with disabilities who can't use
>that background to replace it with one of their own.

But there isn't currently an easy way for users to do this anyway.  A
background image (in HTML or in CSS) is still likely to be equally easy
or hard to replace.  (In some cases, you can just turn it off in your
browser preferences; in others, you may have to create a custom CSS
stylesheet, and it is not a reasonable suggestion to suggest CSS editing
to end users.)

>  > What if it's a user with an old browser? or using the web on a tv?
>Backwards compatability *is* an issue, but it's not too hard to make pages
>that degrade gracefully. In other words, you can still make pages that look
>good without CSS, but that enable users to apply CSS if they want. You just
>have to be careful.

It's important to note that "degrading gracefully" when presentation
is lost entirely is not acceptable to a number of designers and/or
web site owners.  This is the major problem with the use of CSS, besides
the inconsistent support in existing browsers -- if someone looks at
your site without CSS support, and you have relied upon CSS, then
the site is going to look "broken" for certain (legitimate) definitions
of the word "broken".

>Also, you can't really blame it on the browser *too* much: if a Web user
>needs as much pictorial information as possible to assist them, they aren't
>going to want to use Lynx, for example. Whereas if people don't like looking
>at images, they will love using Lynx. In summary, although no solution is
>perfect, we must strive to find the best compromise for everyone!

Just to slip in my plug here, I don't feel that a "compromise" which
excludes some people is necessary, and that's why Edapta is working
hard on creating technology which eliminates the "works for all, but
not works _well_ for all" compromises inherent in the single interface
model of web design.

--Kynn
-- 
Kynn Bartlett <kynn@idyllmtn.com>
http://www.kynn.com/

Received on Wednesday, 22 November 2000 21:06:18 UTC