Re: Minutes from 16 November 2000 WCAG WG telecon

> 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.

Can you cite a reference for that fact (i.e. the definition)?

> 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?

Well, <font size="+1"> implies an exact scale increase to the font, where as
<big> is a little more generic.

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

I agree. The problem is that there isn't really an equivalent...unless you
used:-

     <strong class="big"> and
     @media screen { strong.big { font-weight: normal; font-size: 1.2em; } }

but that's hardly an ideal solution. It's all about achieving the best
accessible balance operating within the constraints of the technology
(XHTML) we're using. Luckily we will soon have the opportunity to change
those constraints...
In the meantime, I feel that <big> is semantic enough to promote its use
over <font size="+1">, but not perfect.

> 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.

It all depends how you contsrue the semantic meaning of the tags. Both <b>
and <big> have very limited semantics, but it's a sliding scale:
<em> is more semantic than <i>
<strong> is more semantic than <b>
[<strong class="big"> is more semantic than] <big> which is more semantic
than <font size="+1">
Where by semantic I mean more abstract and carries more "meaning".

> 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.

I'm not dismissing the need, only stating that there are going to be cases
whereby people *require* to override the background provided by the author.
The best case scenario would be if the author him/herself were to provide
alternative styles and presentations to the page, but even then it is the
accessibility requirements of the page user that are most important.
One example is a Christmas theme: green writing on a red image background. A
lot of people will require a means of changing either the text or the
background, or both. In my own case, I require a dark background, so I
always need to change the background!

> 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.)

In some cases you might have to use lots of methods because there isn't one
clear advantageous one.

> 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.

Degrading gracefully does not have to mean losing presentation entirely
(case in point: the CSS/Style homepage). But even if it did, the whole fact
that it can be got rid of it's it's primary accessibility point: you can
replace the styling with one of your own (one that you may *require* in
order to use the document).

> This is the major problem with the use of CSS, besides
> the inconsistent support in existing browsers

That is a problem. But it's being gradually fixed, thankfully.

> -- 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".

That's why you mustn't rely on CSS: a site should still work without it.
It's fairly easy to accomplish, but it is a tight-rope walk. I think that if
you look upon CSS as a tool to enhance what you have already defined in the
markup, rather than movng away the presentation you already had there, then
it will seem a much friendlier option.

> 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.

Great. I saw your little reply about Edapta to WL and it looks like a very
neat system. In particular, I see it working very well sending over custom
CSS sheets: if a user requests for example a ceratain colo(u)r font, Edapta
could override the authors style sheet and send only a style sheet of that
colo(u)r. Am I correct in thinking that? If so, great application!

Kindest Regards,
Sean B. Palmer
http://xhtml.waptechinfo.com/swr/
http://www.w3.org/WAI/ER/
http://www.w3.org/WAI/GL/
"Perhaps, but let's not get bogged down in semantics."
   - Homer J. Simpson, BABF07.

Received on Thursday, 23 November 2000 07:04:11 UTC