Font sizes - Best practice... px vs. em

[William Tasso]

Re: Font sizes - Best practice... px vs. em

Barry Pearson wrote:[color=blue]
> William Tasso wrote:[color=green]
>> Barry Pearson wrote:[/color]
> [snip][color=green][color=darkred]
>>> Yes it does! I've spent a lot of effort over the last month trying
>>> to make my web sites more accessible to people who can't use
>>> conventional browsers.[/color]
>>
>> ok - my point wasn't about you and your web sites. More of a general
>> comment, let me restate it: It is less effort to build an accessible
>> web site than a broken one - it is certainly less effort to build it
>> right the first time than it is to go back and fix up the issues.[/color]
> [snip]
>
> Let's see if there something we can agree on:
>
> - For a given development cost, there is a whole range of levels of
> accessibility that can be achieved. The trick is to know what the
> equal-cost good ways are. (I suspect that this is a point that you
> and others are trying to emphasise). It still costs effort - but that
> is in the learning, rather than per-page costs.[/color]

ok - for me it has been like someone switching on several lights in a dark
room. each light revealing more. I understand that others experience of
the learning may be different, more a gradual assimilation.

html is trivial - if it hurts then one is doing it wrong (as they say)

<div id="heading">
<h1>blondes have more fun</h1>
</div>
<div id="content">
<p>It has been my life's work to verify that blondes do .....</p>
<p>...</p>
<p>...</p>
</div>
<div id="menu">
<li>The ideal blonde</li>
<li>Blondes at large</li>
<li>Blonde attitude</li>
<li>...</li>
</div>
[color=blue]
> - There are some things that can be done to further improve
> accessibility at relatively low cost. For example, there may be a
> simple navigation mechanism that can be devised for a web site then
> replicated throughout the site via a template.[/color]

page/site construction techniques (although relevent to cost) are immaterial
to the discussion of accessibility which is a client side issue
[color=blue]
>
> I'll even go to an extreme that you may not have wanted to go to:
>
> - Some things that reduce the accessibility (especially the
> navigability) of web sites cost money to put there![/color]

exactly the point.
[color=blue]
> (Pop-ups, complex
> Flash, perhaps frames?[/color]

see, I knew you would get there.
[color=blue]
> Some of those irritate me, and I am not
> disabled). "Simple" tends to be more accessible, and often cheaper -
> but perhaps not as impressive initially.[/color]

'impressive' is in the eye of the beholder. I don't know if it has meaning
in this context.
[color=blue]
> However, if the impressive
> effects can be put via in the style sheets rather than the HTML, it
> can be win-win.[/color]

all {ALL} presentational suggestions are best made as CSS
[color=blue]
> (And suspect that this is another thing that you and
> others believe, given this NG. But only you can say).[/color]

quite possibly
[color=blue]
> But, on the whole, accessibility costs extra.[/color]

No it doesn't. Please stop saying that. It is untrue.

It may be true that accesibility costs /you/ extra time/effort/resources
atm, but it is *not* generally true.
[color=blue]
> I believe that those
> who say otherwise are setting the level too low.[/color]

what level is that?

--
William Tasso - http://WilliamTasso.com

[Barry Pearson]

Re: Font sizes - Best practice... px vs. em

Tina Holmboe wrote:[color=blue]
> "Barry Pearson" <news@childsupp ortanalysis.co. uk> exclaimed in
> <CLCdb.952$hL4. 266@newsfep3-gui.server.ntli .net>:
>[color=green]
>> keep doing so on Usenet & the web. Here are the sorts of statements
>> they make. I suspect you will be aware of such statements:[/color]
>
> From the statements you qoute, I will be blunt and say: you have
> been listening to the wrong people. Let's look at this.[/color]

How do I judge? I have dozens of IE favourites for matters concerned with CSS.
Dozens concerned with validation and other checking. They often contradict
one-another. As you now do.

You are helping to make my point. Instead of being buffeted by the complexity,
I can apply Pareto (the 80:20 principle). Spend basic effort to satisfy 80%,
ignore the 20%, and let them make-do or whatever they choose.
[color=blue][color=green]
>> - Someone criticised one of my web pages and provided an example of
>> how to do it properly. His example failed the W3C CSS validation.
>> When I pointed this[/color]
>
> If an example of how to do something right - and remember: this is a
> technical issue, and there IS right and wrong here - does not pass
> validation without it being a simple spelling error or similar,
> then you can quite safely disregard the advice and the advisor.[/color]

Here is the case concerned. This is the explanation:

http://www.fivesevensix.com/studies/onetruefit/

Note:

<quote>
Major Accomplishments
I'm happy to say the site looks great in:

IE 5 on OSX
Camino on OSX
Safari on OSX
OmniWeb 4.5 on OSX
IE 6 on Windows
IE 5.5 on Windows
IE 5 on Windows
Opera 7 on Windows
Netscape 6.2 on Windows
Other Mozilla browsers - Netscape 7, Firebird, etc.
Basic style - Netscape 4
Basic style - IE 4.5 on MacOS9
Each browser has its own quirks, but they've been worked around with various
hacks. In a few cases I had to change the design slightly for certain browsers
</quote>

If you look at the rest of the page for the URL, you will see a large number
of problems that the author had to overcome, or felt he had to. How can I, or
you for that matter, judge whether he made the right decisions? Were his
concerns important?

It is much simpler to identify a small set of environments that I want things
to look good in, then ignore the rest. "Chance" will determine what it looks
like there. (Having good HTML & CSS won't ensure that it looks good there!)

I spotted this:

http://www.greytower.net/en/archive/articles/customcss.html

Gosh!

"Hey ... is it worth it ? Yeah. Yeah, it's worth it" - but not to me!
[color=blue]
> Why ? The CSS 'validator' isn't perfect, nor is it a validator in
> the strict sense of the word. However, someone who offers an
> explanation and a "right" method but has not taken the effort to
> remove such glaring quality problems as might be revealed by the
> CSS lint looses credibility.[/color]

See above. I think he has gone way beyond the level you are talking about. He
isn't a novice. He gives the distinct impression of being an expert. Or else a
good imitation.
[color=blue][color=green]
>> range of browsers. (I have decided that I will use CSSs that pass
>> the W3C validation, and not put in browsers hacks that would make it
>> fail. Stuff any browsers that need such hacks).[/color]
>
> Correct methodology. It will, on occation, create problems with
> user-agents that are none too picky about what they do to entirely
> correct CSS, but that is something one can live with.[/color]

Who knows whether others can live with it? What I have decided is that I don't
care whether they can or not. It is not my problem.
[color=blue][color=green]
>> - I asked what 2 or 3 browsers I should use to validate my pages. I
>> got back a long list, and clearly it wasn't complete. (I've decided
>> on a much smaller[/color]
>
> It could never be complete. There are numerous browsers out there
> which you have probably never heard of, quite likely can't get at,
> and probably would waste your time with.
>
> But that isn't the issue. The correct answer to the question you
> asked is to NOT use browsers to "validate" pages. Webpages won't
> look the same in all browsers - new or 'old'. That is a concept
> you're better off forgetting; it won't happen, it shouldn't happen.[/color]

I now have an answer (that I've stated earlier here) to the question
"should the web site developer try to ensure that things look the same to
himself/herself, with different browsers, at least with default settings?"

And I think the answer is: "either make them the same or at least understand
why they look different". Because you can learn a lot by doing so, publish
better HTML/CSS, and probably reduce the unwanted variety.

If you can't understand differences even in your own controlled environment,
who knows what will happen "out there"? So: "control the controllables". It
minimise risk and variety.
[color=blue][color=green]
>> set - IE6, Mozilla Firebird 0.6.1, Opera 7.2 & IBM Home Page Reader
>> 3.0, at the moment. IE5/5.5 is a concern, because it is common. But
>> apart from those, I'm ignoring earlier browsers. They can take or
>> leave my web sites).[/color]
>
> Wrong assumption, right idea. If you do your right, "earlier"
> browsers will be able to handle your site just fine - you don't
> need to do something as unneighbourly as "ignoring" them.[/color]

No they won't. That is quite clear from what I've read. They may be tolerable,
but that is vastly different from "just fine".

[snip][color=blue]
> - Suggest a design using CSS. Not IE-CSS, not Mozilla-CSS. CSS.
> Use the fact that Netscape 4 only supports media="screen" to
> hide the styles from it.[/color]

No. I'll ignore NN 4, not put in a hack to cater for it. Or any of the others
that you have pointed out exist.
[color=blue]
> - Use ECMAscript / DOM to create decorative or helpful effects,
> but make sure no essential functionality is created that way. It
> won't work in all browsers, but it won't hurt anyone.[/color]

I've stopped using scripts. I'm going for simplicity.
[color=blue]
> - Use a server-side template/pre-processing tool to assemble the
> site from the templates you've created above.
>
> No, basic accessibility does not cost "extra". It's a myth.[/color]

Then we differ about what "basic" means. I don't think it means sending people
in wheelchairs to the back of the building to use the freight elevators. Or
the web equivalent.
[color=blue][color=green]
>> - I saw someone say what he expected the sort of person worth hiring
>> for one's web development to validate against. He included various
>> things on Mac. (I[/color]
>
> Eh ? The person worth hiring is one with a good theoretical grasp
> of the issues. Anyone can test against a multitude of browsers -
> *that won't help anything*.
>
> Make sure the HTML is correct, the information structured, the CSS
> not harmful, and the scripts non intrusive. The rest will sort
> itself out. #[/color]

No it won't. That is clear from lots of published material.
[color=blue]
> No, it won't look the same. It never will. That isn't a goal. It
> never was.[/color]

Whose goal? And why should I care about that person's goal?

I have MY own goals. They clearly differ from those of many people who develop
for the web, including you. Although I suspect there are more people who have
my view about the importance of presentation quality in certain cases that
some web authors might admit. I would expect CSS3 to make things easier for
such people over the coming decade or two.

If I have a goal about presentation quality, and find that my target audience
shares that goal and is likely to have suitable technology, we can be a happy
"implicit community". While we are seeing things in very much the same way, we
can ignore people who don't think the web can or should work like that. For
THAT topic. (We may then have different views for other topics). Perhaps only
1% of web-users in the world have that technology, but if there is a close
enough match to my target users, that is fine. It typically doesn't stop other
people having a look - I am happy for that. But they may get a degraded view
(at least in our terms).
[color=blue][color=green]
>> - I was checking out how to do better buttons than the CSS-rollover
>> buttons I previously had. I came across what I can only call browser
>> hacks. (Eg. {[/color]
>
> Y'know, Javascript-based rollover buttons work quite nicely and
> degrade even better. CSS works too, as long as you don't expect
> things to look the same. All you *must* do is make sure the links
> never cease to work.[/color]

I got rid of my GIF buttons & the Javascript to handle them for a variety of
reasons, ncluding download-performance and ease of development. Going for a
CSS-based approach was my original reason for trying CSS. A good move. If the
only thing CSS could do was buttons, I would still use it!
[color=blue][color=green]
>> - All over the web are those matrixes of CSS-features versus
>> browser-support, with green, orange, and red boxes, or ticks &
>> crosses. Often they are out of[/color]
>
> So ignore them. They are not authoritative, and they only lead you
> believe even more firmly in the religion that is "It Must Look The
> Same!".[/color]

Gosh! Do you actually have a clue what your stuff looks like out there?

And how the heck can you say (above) things like "Use the fact that Netscape 4
only supports media="screen" to hide the styles from it", while also telling
me to ignore those matrixes about browser support? Without those matrixes, how
I am supposed to know about Netscape 4?
[color=blue][color=green]
>> date, leaving more investigation. NN4.7 is an obvious user-agent to
>> ignore, and I have noticed experts saying they now do so, along with
>> earlier IEs and[/color]
>
> Experts do not ignore Netscape's 4-series. They make sure CSS is
> hidden from it. Even NS 4 is capable of handling structured HTML.[/color]

Some people, who appear to me to be experts, have decided it is time to ignore
NN4. I have read stuff on the web that suggests the usage has dropped to the
level where it isn't worth the effort any more. I can't judge whether you know
more or less than they do. But I know what is easiest for me.
[color=blue][color=green]
>> - When I first validated some pages against "Bobby", it was like
>> running into a brick wall. I decided that if it was hard to make a
>> site that could seen[/color]
>
> Bobby never validated anything, never do, and never will. It is,
> like "Site Valet" and Greytower's siteSifter, "accessibil ity
> lints". It can make recommendations . It can tip you off to things
> you've missed.
>
> Bobby, to be even more blunt, is not the best of them. If you want
> to check your site's accessibility, run it through the W3C's
> "Preliminar y Review" list of checkpoints. It'll not take you long,
> but it'll cost you thought.[/color]

I have done. It is like the same brick wall. I assume you mean:

http://www.w3.org/WAI/eval/

[color=blue][color=green]
>> "Bobby" was, in effect, lying. Indeed, some of its advice would make
>> things worse in IBM HPR. (It was advice about links with only white
>> space between them, and hence the proposal to separate such links
>> with extra characters). (I[/color]
>
> It might make things worse in *HPR*. The world is not HPR. Don't
> disregard that advice.[/color]

Indeed. Yet another browser related complication. When in doubt, I'll have to
go with what I personally know. I based what I did on this article, and the
comparison report he identified:
http://groups.google.c om/groups?as_umsgi d=21VrB3DrwPU$E wRz@gododdin.de mon.co.uk

[snip][color=blue][color=green]
>> - I put navigational-assistance links based on invisible-GIFs across
>> much of one of my web site. How can anyone claim that isn't extra
>> effort?[/color]
>
> It is extra effort - why the bloody hell do you want to go and do
> something silly like that for ? The standard says "A method to skip
> over navigation"; not "invisible gif navigational assistance links".[/color]

I did it because someone used to using assistive technologies suggested it.
Here is just one of his articles (he wrote a number of them, including the one
above, which helped me a lot):
http://groups.google.c om/groups?as_umsgi d=pftMLhLWq3T$E wpl@gododdin.de mon.co.uk

Do I listen to you or to him? How much do you use assistive technology?
[color=blue]
> "Invisible gif skip-to-link" crap. Ditch that idea. It'll only make
> things difficult for some groups, whilst being of little or no use
> to others. Try this:
>
> (1) id="content" on the very first element in the content;
> (2) <a href="#content" >skip to content</a> before the menu.
>
> Effort ? Yes, on a very, very picky level that IS extra effort. A
> full five seconds worth.[/color]

What menu? Here is an example:

http://www.childsupportanalysis.co.uk/this_web_site/accessibility.htm

The invisible GIF is just before the "This web site" at the top.

I've been told it works in practice. Perhaps just to some people, using
certain technology, perhaps not for others. All part of the cost of trying to
make things accessible. Fortunately I'm prepared to try to navigate through
all the conflicting advice to try to get it right eventually. But I won't
sacrifice the presentation for sighted people while I'm doing so.

Note the thread (on uk.net.web.auth oring ) for the 2 articles above. I started
that to try to find out how to use alt" and "title" text for thumbnails in
photograph galleries. I now have a good view, and may write it up. But there
is little good advice on the web. And much of what there is is out of date.
Instead of a ready-made solution that can be adopted easily, much of
accessibility apears to be complicated and sometimes contradictory advice to
be navigated through.
[color=blue][color=green]
>> If you believe that widely-accessible web sites can be done without
>> extra cost, perhaps I could have a look at some of yours, to see how
>> you did it?[/color]
>
> You're free to look at ours. Do me a favour first though: don't
> tell me it looks ugly. Ugly does not come into it. Ugly is not
> interesting. Ugly has no place in this discussion.[/color]

Yes it does. For me, for some purposes, ugly is intolerable.
[color=blue]
> It does meet, to the best of my knowledge, WCAG 1.0 'AAA' though.
> I'm not going to spend my evening reviewing that once more.
>[color=green]
>> Accessibility costs effort. Anyone who says otherwise is wrong, or
>> is setting too low a standard.[/color]
>
> When it comes to accessibility, you need to decide what YOUR
> baseline is. Unless you live and do work in a jurisdiction in which
> one is decided for you - federal work and Section 508 as well as
> the EU and WCAG 1.0 springs to mind - then YOU are the one who need
> to define that baseline.[/color]

Indeed. And I appear to chosen a baseline "off the no-cost floor".
[color=blue]
> If you want to have an international standard - ie. WCAG 1.0 - as
> that base, then there are things you must do. Depending on the
> baseline, it might cost you effort. It's not all that likely,
> though, unless your methods could do with a very thorough review as
> it is.
>
> The very first thing, however, is starting to sift *very hard* the
> sources and the people you listen to.[/color]

Give me a clue - how do I judge?

How can I even judge whether anything you have said is worth listening to? I'm
guessing it is, but you are simply another, contradictory, voice. And I'm
confident that some of the things you have said are wrong (see above).

--
Barry Pearson

http://www.Barry.Pearson.name/photography/

http://www.BirdsAndAnimals.info/

http://www.ChildSupportAnalysis.co.uk/

[Barry Pearson]

Re: Font sizes - Best practice... px vs. em

William Tasso wrote:[color=blue]
> Barry Pearson wrote:[/color]
[snip][color=blue][color=green]
>> But, on the whole, accessibility costs extra.[/color]
>
> No it doesn't. Please stop saying that. It is untrue.[/color]
[snip]

All the evidence I see here and across the web says it costs extra. My own
experience says it costs extra. It costs extra in training. Extra in
validation and other checking. Extra if a sighted person able to have an
overview of aspects of a page can easily do something that someone with a more
serial perception of the page needs extra assistance with.

I believe YOU are the one saying something untrue. We may have to differ on
this. However, if you can show me research / surveys, etc, that demonstrate
that it doesn't cost extra, I will read them and comment upon them.

--
Barry Pearson

http://www.Barry.Pearson.name/photography/

http://www.BirdsAndAnimals.info/

http://www.ChildSupportAnalysis.co.uk/

[Beauregard T. Shagnasty]

Re: Font sizes - Best practice... px vs. em

Barry Pearson pounced upon this pigeonhole and pronounced:[color=blue]
>
> Here is the case concerned. This is the explanation:
> http://www.fivesevensix.com/studies/onetruefit/
> Note:[/color]

http://www.onetruefit.com/style/global.css

body { font: normal 11px ...
[color=blue]
> <quote>
> Major Accomplishments
> I'm happy to say the site looks great in:[/color]

Except the font size is forced and too small.

On this page: http://www.onetruefit.com/privacy.php
in IE6, increasing the text size to Largest only makes the bullets in the
list larger. The font is unaffected and remains too small.

Had he set the font-size to 1em or 100%, it would work. (In my preferred
browser, Firebird, I can increase it because the browser works.

--
-bts
-This space intentionally left blank.

[Alan J. Flavell]

Re: Font sizes - Best practice... px vs. em

On Mon, 29 Sep 2003, Barry Pearson wrote:
[color=blue]
> All the evidence I see here and across the web says it costs extra.[/color]

Most of the evidence I see across the web tells me that putting in
obstacles to accessibility costs extra, and taking them out again
costs even more. I think you can work out what I deduce from that.
[color=blue]
> It costs extra in training.[/color]

Would you hire a stonemason to design a new dress collection? Both are
respectable professions, but one of them is accustomed to dealing with
a medium which is hard and unyielding.[1]

Naturally, for someone accustomed to the stability of paper
publishing, it /would/ need an adjustment to deal with a medium which
has the important property of being _intended_ to adapt itself to a
wide range of sizes and situations.

I don't think anyone is trying to argue that adding _specific_
accessibility features to a page would involve no extra work. But a
large proportion of the pages that we see on the web would be
significantly more accessible if unnecessary obstacles had been left
out, and that's the sense in which some of us, at least, are saying
that basic accessibility comes with the medium, it isn't an expensive
extra as it would be in a building, a vehicle, etc.

None of this is meant to be a criticism of your own pages, and it's a
pity that you sometimes seem to react to general discussion as if you
thought that it was.

cheers

[1] which one, is left as an exercise for the student ;-)

[Jim Ley]

Re: Font sizes - Best practice... px vs. em

On Mon, 29 Sep 2003 01:26:18 GMT, Beauregard T. Shagnasty
<a.nony.nous@ex ample.invalid> wrote:
[color=blue]
>body { font: normal 11px ...
>
>Except the font size is forced and too small.[/color]

A weakness of your UA surely? and there are lots of weak UA's out
there, one of the specific problems Barry is having is that gaining
the knowledge of all these weak UA's is expensive, too expensive for
the vast majority of people.

In any case px is defined to be scaleable to the output medium - I
certainly agree that setting body to any size other than 1em is bad,
but WAI don't say anything against it (not even an until UA's
support), the W3c do it on their own new pages, so I think you need to
be clearer about what is being done wrong here.

I agree with you it's a bad choice, but I get loads wrong.

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Tina Holmboe]

Re: Font sizes - Best practice... px vs. em

"Barry Pearson" <news@childsupp ortanalysis.co. uk> exclaimed in <bUKdb.1126$ft3 .2060502@newsfe p1-win.server.ntli .net>:

[color=blue]
> I spotted this:
> http://www.greytower.net/en/archive/...customcss.html
> Gosh!
>
> "Hey ... is it worth it ? Yeah. Yeah, it's worth it" - but not to me![/color]

I see I forgot to include the source of the quote. My fault, for assuming
that noone could have missed it. Perhaps I was a little too subtle in
using that.

I do not - with emphasis - recommend the method I describe in the article
quoted above. Not at all. Avoid it like the plague - avoid it like a
giant cockroach in a brand new Edgar suit.



[color=blue]
> If you can't understand differences even in your own controlled environment,
> who knows what will happen "out there"? So: "control the controllables". It
> minimise risk and variety.[/color]

None - claims to the contrary be damned - can know what will happen to a
webpage when it reaches it's destination. The trick is to embrace that
idea and live with it.



[color=blue][color=green]
>> No, basic accessibility does not cost "extra". It's a myth.[/color]
>
> Then we differ about what "basic" means. I don't think it means sending people
> in wheelchairs to the back of the building to use the freight elevators. Or
> the web equivalent.[/color]

That makes me happy to hear - we are making progress. However, why
do you insist on making nicely accessible doorways that only work with
the latest wheelchairs - if people have slightly older, heavier, wider
chairs they can juse take your building or leave it, eh ?

Netscape 4 is an old browser; it needs a tiny amount of coddling to
get it right. But you want to send people using that wheelchair away;
not to the back to the freight elevators, but *away*.





[color=blue][color=green]
>> Make sure the HTML is correct, the information structured, the CSS
>> not harmful, and the scripts non intrusive. The rest will sort
>> itself out. #[/color]
>
> No it won't. That is clear from lots of published material.[/color]

There is alot of published material. On the web, and off it. 90% of it
is STILL crap, and there is nothing you can do about it.

Graceful degradation is a fact. Your friend with the one-size-site has
actually managed to achive it *despite* tinkering - not because of it.




[color=blue]
> for the web, including you. Although I suspect there are more people who have
> my view about the importance of presentation quality in certain cases that
> some web authors might admit. I would expect CSS3 to make things easier for[/color]

If you, by that, mean that there are lots more people that care about how
things LOOK then, yes, you are right.

I am not one of them.





[color=blue]
> THAT topic. (We may then have different views for other topics). Perhaps only
> 1% of web-users in the world have that technology, but if there is a close
> enough match to my target users, that is fine. It typically doesn't stop other[/color]

If your target users are equal to "those using a specific browser", then
that's fine. Go ahead and define your content accordingly.

But it really isn't productive. You can, with the same effort, reach so
many more. With a little more effort, you can reach ... everyone ?



[color=blue][color=green]
>> So ignore them. They are not authoritative, and they only lead you
>> believe even more firmly in the religion that is "It Must Look The
>> Same!".[/color]
>
> Gosh! Do you actually have a clue what your stuff looks like out there?[/color]

Nope. But: I am fairly certain that only a very few people, if anyone
at all, cannot get to our content. If interested, of course.



[color=blue]
> And how the heck can you say (above) things like "Use the fact that Netscape 4
> only supports media="screen" to hide the styles from it", while also telling
> me to ignore those matrixes about browser support? Without those matrixes, how
> I am supposed to know about Netscape 4?[/color]

That was a diplomatic mistake of mine - *I* would hide CSS from Netscape 4;
and it wouldn't cost any client of mine extra to do so. There is no
measurable cost involved.

If you choose not to do the same, then that IS your choice. It might not
be the most productive one.




[color=blue][color=green]
>> Bobby, to be even more blunt, is not the best of them. If you want
>> to check your site's accessibility, run it through the W3C's
>> "Preliminar y Review" list of checkpoints. It'll not take you long,
>> but it'll cost you thought.[/color]
>
> I have done. It is like the same brick wall. I assume you mean:
> http://www.w3.org/WAI/eval/[/color]

That was what I meant, yes. I'm sorry that you see it as a brick wall;
the language used by the W3C can be a little on the gritty side.



[color=blue]
> Do I listen to you or to him? How much do you use assistive technology?[/color]

Here is the gist of it: does it *matter* how much I; or he, uses technology
X ?

As with beauty, accessibility is in the eye of the beholder. There are,
however, a few theoretical ideas that can be used to anticipate how
content will be presented in a person's physical reality.




[color=blue]
> What menu? Here is an example:
> http://www.childsupportanalysis.co.u...essibility.htm
> The invisible GIF is just before the "This web site" at the top.[/color]

Yes. And this - annoyingly - is what happens to, say, a user with the
latest version Mozilla, full sight, but restricted to using the keyboard:

(1) I type the URI into the address field of my browser,
(2) I press Enter, and it loads,
(3) I press tab to navigate to the first link,
(4) The focus - the outline around links - disappear. I can't find it.

"What ... where did the focus go ? Where am I ? Oh. Invisible gif to
skip navigation. Brilliant"

The site is paying lip-service to some accessibility standard without
bothering to understand it. This says it all:

<blockquote
cite="http://www.childsuppor tanalysis.co.uk/this_web_site/accessibility.h tm">
Pages are also being tested against the "Bobby" standards for
accessibility.
</blockquote>

There is no "Bobby standard"; it is merely a lint, and it is leading
them - and you - astray.

Let's have a look at what the standard - WCAG - says on the topic:

<blockquote cite="http://www.w3.org/TR/WCAG10-HTML-TECHS/#group-bypass">
Navigation bars are usually the first thing someone encounters on a page.
For users with speech synthesizers, this means having to hear a number
of links on every page before reaching the interesting content of a page.
</blockquote>

I'll have to admit that this is poorly written - and lacks the phrase
"for example". A method for skipping over a navigational menu gives an
advantage to many users; it isn't restricted to those using a speech
browser. Everyone who need to bypass one section of a page (a menu)
can benefit. Think of it as an advanced "table of contents" - but would
you ever make a table of contents into a GIF and *hide* it ?[*]






[color=blue]
> I've been told it works in practice. Perhaps just to some people, using[/color]

It does, for a subset of users. Everyone else fails to benefit.



[color=blue]
> all the conflicting advice to try to get it right eventually. But I won't
> sacrifice the presentation for sighted people while I'm doing so.[/color]

And you don't need to. See below, please.




[color=blue]
> Note the thread (on uk.net.web.auth oring ) for the 2 articles above. I started
> that to try to find out how to use alt" and "title" text for thumbnails in
> photograph galleries. I now have a good view, and may write it up. But there
> is little good advice on the web. And much of what there is is out of date.[/color]

Since you obviously know the WDG website, did you try the emminent article
by Alan Flavell on the topic ? It is certainly the best one I know of
in the field, and it does refer to thumbnails for images.





[color=blue][color=green]
>> You're free to look at ours. Do me a favour first though: don't
>> tell me it looks ugly. Ugly does not come into it. Ugly is not
>> interesting. Ugly has no place in this discussion.[/color]
>
> Yes it does. For me, for some purposes, ugly is intolerable.[/color]

Yes - but that is a matter of taste; your personal taste. Which is
fine. I won't argue with it; I've never seen any proof that there exist
a universal taste; I wouldn't believe it if I saw it.

But: when all is said and done, the impossibility of prediction that
is a fact of life on the Web remains.

Yes, you could - and should, if it is important to you - use CSS to
create a packaging of content with which you feel comfortable. That
packaging won't last.

At some point down the line, the packaging will be stripped off and
the content laid bare - and that's where HTML and structure comes
into play. So far, so good. Let's revise my list from earlier:

- Plan your work. Look over the content you want to include on the
site, and determine how you want to organize it.

- Structure each piece physically (on disk) and logically (HTML). This
is when you create the templates you'll later use.

- Apply CSS to the structures. Many people find it useful to see the
results; so they use a reference browser. Mozilla is currently the
UA with best support for CSS.

- Add scripting if you absolutely must. Eyecandy is appreciated by
many; but forget about client-side functionality unless you have
very special needs.

- Use a server-side processing system to fill the templates with content
from files or databases.

- Publish.

A CSS aware browser will attempt to render your suggested layout, unless
the user tells it not to. A HTML agent will simply render the structure
as is, in the default fashion, or the way the user has configured it to
do.

It won't ever look exactly as you envisioned it - there will always
be differences; even with exactly the same technology as you use.

- For some, it'll look broadly as you wanted it to.

- For some, it'll look somewhat as you wanted it to.

- For quite a few others it'll look ... default.

- For many it won't "look" at all; it'll sound, or feel.

- For a number of people it won't look, sound, or feel, because their
browser mistakingly believe it knows CSS.

But most everyone will be able to get to your content - and it hasn't
cost you anything *more*.

Then you can start on the tiny details that might *enhance* the
possibility of people getting to the content; such as hiding CSS from
Netscape 4, including (textual) skip navigation links, and soforth.

But these things are also only needed once: as soon as that skip navigation
link is in place in the template, it will propagate to all the other
documents on the site. As soon as you've included the hide-from-NS-4
hack, it'll function on all pages.

When building a website from scratch is counted in the USD 85 per hour
priceclass (oh, yes, atleast here), then the extra minutes spent on
adding that textual link is neglible.

The baseline is up to you - but the basics never change; once you are
done with them you'll have met WCAG 1.0 'A' and most of 'AA'.

Yes, you'll need to learn alot - but you don't need to learn a
"special form of HTML", for instance. HTML is accessible. If you learn
HTML, and learn it right, you're well on your way. There isn't any
extra cost in learning something right, is there ?




[color=blue][color=green]
>> The very first thing, however, is starting to sift *very hard* the
>> sources and the people you listen to.[/color]
>
> Give me a clue - how do I judge?[/color]

How do you judge the information you receive in everyday life ? What you
find on the Internet is not really any different, save that it is often
in far prettier packages.


[color=blue]
> How can I even judge whether anything you have said is worth listening to? I'm[/color]

Good point. I can't convince you, and to be honest: I shouldn't. You'll
need to do that yourself.

Me, I don't think I want to continue this debate. It's pretty off topic and
I don't like it very much. But good luck in sifting through the debris that
is sure to follow.


[*]
We've hidden our textual skip-to-content link. That is one of the things
that really could be improved.

--
- Tina Holmboe Greytower Technologies
tina@greytower. net http://www.greytower.net/
[+46] 0708 557 905

[Beauregard T. Shagnasty]

Re: Font sizes - Best practice... px vs. em

Jim Ley pounced upon this pigeonhole and pronounced:[color=blue]
> On Mon, 29 Sep 2003 01:26:18 GMT, Beauregard T. Shagnasty
> <a.nony.nous@ex ample.invalid> wrote:
>[color=green]
> >body { font: normal 11px ...
> >
> >Except the font size is forced and too small.[/color]
>
> A weakness of your UA surely?[/color]

Not my UA. I notice you snipped the rest of my post, where I went on to
say: "(In my preferred browser, Firebird, I can increase it because the
browser works.)" A simple Ctrl-Plus.

I was pointing out that the millions of IE users who don't know how to
override the author's font choice will see small text.

[color=blue]
> and there are lots of weak UA's out
> there, one of the specific problems Barry is having is that gaining
> the knowledge of all these weak UA's is expensive, too expensive for
> the vast majority of people.
>
> In any case px is defined to be scaleable to the output medium - I
> certainly agree that setting body to any size other than 1em is bad,
> but WAI don't say anything against it (not even an until UA's
> support), the W3c do it on their own new pages, so I think you need to
> be clearer about what is being done wrong here.[/color]

Sorry, I thought I was clear.

"On this page: http://www.onetruefit.com/privacy.php
in IE6, increasing the text size to Largest only makes the bullets in the
list larger. The font is unaffected and remains too small."
[color=blue]
> I agree with you it's a bad choice, but I get loads wrong.
>
> Jim.
>[/color]

--
-bts
-This space intentionally left blank.

[kchayka]

Re: Font sizes - Best practice... px vs. em

Barry Pearson wrote:[color=blue]
> kchayka wrote:[color=green]
>> Barry Pearson wrote:[/color]
>
> See the following. They are described there:
> http://www.birdsandanimals.info/web_site/formats.htm
> (I use 9, not 8. One is used for the non-photograph pages).
>
> If you can think of a way of reducing the numbers of CSSs, please tell me.[/color]

I've already spent much more time on this than I intended. If you
really want assistance with this, I suggest you start a new thread.
[color=blue][color=green][color=darkred]
>>> My web sites that existed a year ago look far worse now to
>>> people who can't use CSS.[/color][/color]
>
> As someone on uk.net.web.auth oring said "We don't all choose our OS primarily
> for browsing!"
> http://groups.google.com/groups?as_u...39@v-liz.co.uk[/color]

What does OS have to do with it? The user either browses with CSS or
without it. The poster in the message you reference apparently goes
without due to system resource issues with graphical browsers, not that
it matters. The only important point is that they browse without CSS.
They still deserve access to content, don't they? BTW, I'd venture to
say that the poster probably cares less about aesthetics than you do.
[color=blue][color=green][color=darkred]
>>> http://www.barry.pearson.name/test/k..._tableless.htm[/color][/color]
>
> All the common combinations of text colour and background colour
> used there pass the thresholds for both the Colour Brightness Formula and the
> Colour Difference Formula suggested by the World Wide Web Consortium (W3C).[/color]

<URL:http://www.w3.org/TR/AERT#color>
"Requiremen t: Determine color visibility.@@ne eds work?"
"This is a suggested algorithm that is still open to change."

IOW, don't take it as gospel. I'm sure that on your high-end, carefully
calibrated monitor everything looks peachy, but not everyone has such a
configuration. Nor does everyone have perfect lighting, the perfect
work space, or perfect eyesight.

If you search a bit more, you may find some articles on using dark
backgrounds vs light ones and which is generally better for on-screen
readability.

--
To email a reply, remove (dash)un(dash). Mail sent to the un
address is considered spam and automatically deleted.

[Eric Bohlman]

Re: Font sizes - Best practice... px vs. em

"Barry Pearson" <news@childsupp ortanalysis.co. uk> wrote in
news:Ufxdb.227$ Pe7.89376@newsf ep2-gui.server.ntli .net:
[color=blue]
> But, on the whole, accessibility costs extra. I believe that those who
> say otherwise are setting the level too low. A building can be made
> accessible by directing wheel-chair users round the back where they
> can use the freight elevators. But coming through the front doors is
> likely to cost extra, even if done from the start. Builders in the UK
> believe that Part M of the Building regulations will add to
> construction costs, for example wider doors. Yet some disabled people
> feel Part M has not gone far enough and may only lead to "visitable"
> rather than liveable" housing.[/color]

I don't think that anybody would argue that *retrofitting* accessibility
doesn't cost extra. If your doors are too small for a wheelchair to get
through, there's not a builder in the world who would enlarge them for
free. But those arguments don't apply to designing accessiblity in *from
the beginning*. If you haven't built your doors yet, no builder is going
to charge you extra for making them a little wider, since it doesn't cost
them anything extra to do so.

The key here is to realize that accessibility is a form of quality, and all
forms of quality are cheap or free to build into a product or service, but
quite expensive to add after the fact. Designing a process to produce
parts that all do better than to meet spec is easy and cheap. Culling out
parts that don't meet spec because the process that produces them relies on
luck to meet spec is hard and expensive. The manufacturing world learned
this decades ago.

[Jim Ley]

Re: Font sizes - Best practice... px vs. em

On Mon, 29 Sep 2003 03:34:13 GMT, Beauregard T. Shagnasty
<a.nony.nous@ex ample.invalid> wrote:
[color=blue]
>"On this page: http://www.onetruefit.com/privacy.php
>in IE6, increasing the text size to Largest only makes the bullets in the
>list larger. The font is unaffected and remains too small."[/color]

Yes, there's just no relevance to accessible authoring in saying that,
it's just a known bug in IE, there's thousands of known bugs in
browsers and if you're saying we can't use parts of the spec because
of those browsers then how is the author supposed to know all the
bugs?

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Vincent]

Re: Font sizes - Best practice... px vs. em

Stephen Poley wrote:[color=blue]
> On Thu, 25 Sep 2003 15:48:59 -0400, "Peter Foti"
> <peterf@systoli cnetworks.com> wrote:
>
>[color=green]
>>Also, what about the differences with font sizes in relation to the actual
>>font family? For example, Verdana looks larger than Times, so perhaps
>>something that looks good in Verdana font with an em font size will look too
>>small when inherited by something with Times font. How are these issues
>>addressed in the real world... that's what I'm hoping to learn. :)[/color]
>
>
> Best bet is simply to avoid fonts which are exceptionally small or
> (especially) exceptionally large, like Verdana. In the former case I can[/color]

Maybe an other possibility would be use the font-size-adjust property in
CSS (see http://www.w3.org/TR/CSS2/fonts.html...t-size-adjust).
I use it myself with a value I chose by trial and error but the result
is very satisfying... in Gecko-based browsers, because IE ignores this
property.


--
to email me, add "poinot" before the at-sign in my
address and wanadoo after it...

[Barry Pearson]

Re: Font sizes - Best practice... px vs. em

Beauregard T. Shagnasty wrote:[color=blue]
> Barry Pearson pounced upon this pigeonhole and pronounced:[color=green]
>>
>> Here is the case concerned. This is the explanation:
>> http://www.fivesevensix.com/studies/onetruefit/
>> Note:[/color]
>
> http://www.onetruefit.com/style/global.css
>
> body { font: normal 11px ...
>[color=green]
>> <quote>
>> Major Accomplishments
>> I'm happy to say the site looks great in:[/color]
>
> Except the font size is forced and too small.[/color]
[snip]

Indeed! One thing I have done as a result of this thread is remove all
font-related "px" from all my CSSs. (I got rid of all "font" in my HTML over
the last month or so). (I hope!)

I went through every font size I found, and replaced it by a % that displayed
the same in the set of browsers I use at their default settings. (IE 6, Opera
7.2, Firebird 0.6.1). Then I tested that all those browsers' text-size
adjustment worked as expected. (I only use font size adjustment for special
purposes anyway - headings, buttons, and admin stuff).

This still leaves me with the question of best practice in the body { } rule.
In fact, it applies to all font properties. (The other main one for me being
the font-family). I'm not seeing a clear consensus about how to tackle that. A
huge proportion of sites on the web specify one or both of these. (Many of
those that don't specify them in the body rule set them by more specific
rules).

I've been confused by the following page:

http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/properties/font.asp

It is talking about the "font" property in CSS. (I use such a DOCTYPE):

"As of Internet Explorer 6, when you use the !DOCTYPE declaration to specify
standards-compliant mode, the following conditions apply to this property. The
font-size and font-family values must be declared. If font-size and
font-family are not declared, or are not in the correct order, the font
property is ignored. All specified values must appear in the correct order.
Otherwise, the font property is ignored. In standards-compliant mode, the
default font-size is small, not medium. If not explicitly set, font-size
returns a point value".

That last bit was a puzzle - it appears to say the IE 6 is not obeying the CSS
specification properly. Or it may mean something else entirely! It has led me
to specify "medium" in the body rule. I get the expected results in the
browsers I use, but I haven't a clue what it does to other cases "out there".

Is there actually a consensus on best practice for font properties in the body
rule? If there is, what are the implications for all those web sites?

--
Barry Pearson

http://www.Barry.Pearson.name/photography/

http://www.BirdsAndAnimals.info/

http://www.ChildSupportAnalysis.co.uk/

[Barry Pearson]

Re: Font sizes - Best practice... px vs. em

Jim Ley wrote:
[snip][color=blue]
> A weakness of your UA surely? and there are lots of weak UA's out
> there, one of the specific problems Barry is having is that gaining
> the knowledge of all these weak UA's is expensive, too expensive for
> the vast majority of people.[/color]
[snip]

Thanks, Jim. Yes, that is indeed my problem.

And, as you say, a problem for others. It appears to me that, given that a
huge number of web sites are developed by people who don't know what best
practice is, the web will continue to be awash with not-best-practice. (I
suspect that all the advice from experts will have approximately the same
effect as advising everyone to like one-another so that we can have
world-peace!)

That in turn probably means that the trend will be for UAs to provide ever
more user-control, and current UA limitations are a temporary glitch. I'm not
sure what conclusions can be drawn from that.

--
Barry Pearson

http://www.Barry.Pearson.name/photography/

http://www.BirdsAndAnimals.info/

http://www.ChildSupportAnalysis.co.uk/

[William Tasso]

Re: Font sizes - Best practice... px vs. em

Barry Pearson wrote:[color=blue]
> William Tasso wrote:[color=green]
>> Barry Pearson wrote:[/color]
> [snip][color=green][color=darkred]
>>> But, on the whole, accessibility costs extra.[/color]
>>
>> No it doesn't. Please stop saying that. It is untrue.[/color]
> [snip]
>
> All the evidence I see here and across the web says it costs extra.[/color]

evidence?
[color=blue]
> My own experience says it costs extra.[/color]

It only costs extra if it is broken by design.
[color=blue]
>
> I believe YOU are the one saying something untrue.[/color]

so it seems
[color=blue]
> We may have to differ on this.[/color]

yep
[color=blue]
> However, if you can show me research / surveys, etc,
> that demonstrate that it doesn't cost extra, I will read them and
> comment upon them.[/color]

Sure, I'll write any report you like. Just send over your P.O. and the
ncessary data for credit references with your commission documentation and
I'll be off. Please allow for a minimum 21 days at (£900 + £250 exes) £1150
+ VAT (if applicable in your location). Please allow extra for travel and
accommodation if you require a personal presentation to your board of
directors. I am currently available from Tuesday of next week.

toodle-pip.
--
William Tasso - http://WilliamTasso.com