Re: Minutes from 16 November 2000 WCAG WG telecon

At 5:32 PM +0000 11/23/00, Sean B. Palmer wrote:
>True. We need RDF, for stuff like this. I suppose we have to ask "why do we
>want this bit of text to be 'big'?". All current methods are hacks (<font>,
><big>, <strong class="big">), but if something needs to be bigger, there
>must be a reason. Once we have found that reason, it must be possible to
>include the reason in the markup and add style based on that meaning.

This is why I believe that content should not be encoded in XHTML, but
in an appropriate XML dialect.  In my line of thinking, XHTML and other
languages which have presentational markup are entirely appropriate and
useful as end presentation languages, chosen appropriately by the
server.  My process for web serving looks like this:

(ascii art follows, sorry, it's the best way to get it across)

  XML Data Store         Edaptation Engine       User Agents
[ content in XML ] --> [ XSLT edaptors   ] --> [ presentation ]
                               _            \-> [ presentation ]
                              |\             \> [ presentation ]
                                \             > [ presentation ]
                                 \
                                  [ cc/pp profile ]<-- [ prefs ]

In other words, data is stored in XML; a request comes in from the
user agent that includes an appropriate capabilities/preferences
profile.  The edaptation engine (using XSLT or another content
reformatting option) produces an appropriate _presentation language_
language for the user agent based on the content of the data store
and the capabilities of the end device.

The presentation language _must_ contain the necessary information
(call it semantics, call it markup, call it something else) for the
user agent to appropriately render/provide access to the data on the
specific end device, but it's not necessary to send _all_ information
to that user agent if it won't need it.

I can see one argument against this, and it's come up before; it's
the objection of "how dare you presume that we don't need/want all
the information, how dare you make decisions about what -we- might
want?"  However, it's important to note that how you know what's
necessary is that the user agent _tells you_ via CC/PP profile.
So it's not a case of someone arrogantly deciding "we don't need
to know that!", it's a case of providing what has been requested.

>Can you
>offer me any advantages of using <b> rather than <strong>? Implementation
>factors aren't an issue here, son't forget; I mean what are the
>philisophical reasons that you believe <b> is better to use than <strong>?

Actually it depends on what you're wanting to do.  If you want to make
a piece of text bold (for whatever reason) then you should use <b>.
If you want to emphasize a piece of text (for whatever reason) then you
should use <strong>.  Philosophically it's important to realize that
sometimes someone may just want to say "this should be bold, because
I feel it should be bold."

Why do I object when people rant about <strong> vs <b>?  Because I think
that it doesn't deal with actual issues of accessibility in the real
world, and it distracts people from making real changes.  The issue of
"<b> vs <strong>" is really such a minor, meaningless issue in practice
that it's not worth dealing with.  It's been solved, in the browsers
(because they _all_ treat <b> and <strong> appropriately), and it
gives people the wrong impression of what accessibility is about.

It's a distraction, and a meaningless one, ultimately, because changing
<b> to <strong> is going to effect zero change in increasing
accessibility by any person anywhere in the world.  When you tell
people "use <strong> instead of <b>" that's all they remember, and the
ideas behind the concepts are lost, and it just becomes a case of
doctrinal purity rather than actual improvements for human beings.

And when we forget about human beings and instead put HTML specs
ahead of people, we've lost the fight.

Here's a real example:  Let's say that I'm giving a seminar in web
accessibility, and I say "well, if you use <strong> instead of <b>,
then you are making your page more accessible."  Then some heckler
in the audience asks, "how?" and I explain about semantics and
other stuff stuff.  The audience nods along with me and agrees, until
the heckler stands up again and says, "okay, so which browsers for
people with disabilities don't recognize <b>, and do recognize
<strong>?  why should we listen to this if it makes no difference?"

Then I've lost the audience and my credibility.  If this makes no
difference whatsoever (and I firmly believe that <b> will be with us
in HTML as long as we have HTML of any flavor), then why am I using
it as an example?  In fact, for that very reason, I don't tell
people to use <b> instead of <strong>.  It's a non-issue entirely, and
a bad example to use.

>I look at it the other wat round because I believe Semantic markup can be
>interpreted much more broadly, and therefore adds a range of accessibility
>to the element. If the author wants all <strong> elements to be presented as
>bold text, then it is up to them to say so, but at least it can be
>overidden.

The "overridden" ability is less attractive to authors, by the way. :)
But please note that <b> can be overridden, too!  (As far as CSS goes,
<b> and <strong> are both equally useful...)

>BTW:, by saying:
>>  Background and font are semantic because they convey content and
>>  meaning which is important to the author.
>You are slightly contradicting:
>>  Why do you think it's semantic?  There is nothing semantic about
>>  <big>.  It's a purely presentational tag.
>but I get what you mean.

Of course I'm contradicting; I was explaining Anne's viewpoint, not
my own.  <big>, <b>, backgrounds, and fonts are presentational, but
note that you and I place different values and uses on presentational
markup.

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

Received on Thursday, 23 November 2000 13:09:50 UTC