accessibility - the use of <P>

[Chris Goldie]

From an accessibility point of view, is there any advange in using <P>
over <br>?

eg, whats the difference between these two examples, are they both
accessible?

Eg. 1
<p>My first paragraph.</p>
<p>My second paragraph.</p>

Eg. 2
<br><br>My first paragraph.
<br><br>My second paragraph.

Thanks

Chris
--

Interaction Designer - SplashMedia
http://splashmedia.co.nz

[Eric Jarvis]

Chris Goldie wrote:

From an accessibility point of view, is there any advange in using <P>
over <br>?

eg, whats the difference between these two examples, are they both
accessible?

Eg. 1
<p>My first paragraph.</p>
<p>My second paragraph.</p>

Eg. 2
<br><br>My first paragraph.
<br><br>My second paragraph.

the latter MEANS "My first paragraph My second paragraph

the former MEANS "My first paragraph

My second paragraph"

a screen reader should render them as such, so your intended meaning will
be lost

for non visual usage of the site the latter could be confusing and should
therefore not be used...<p></p> shows the content to be a single
paragraph...this is a conceptual idea not merely a matter of how the text
is visually represented on the page

--
eric
www.ericjarvis.co.uk
"Hey Lord don't ask me questions
There ain't no answer in me"

[Owen Jacobson]

Chris Goldie wrote:

Eg. 1
<p>My first paragraph.</p>
<p>My second paragraph.</p>

Eg. 2
<br><br>My first paragraph.
<br><br>My second paragraph.

I'm not overly knowledgable about website accessibility issues, but I
do have to say that while both will visually appear to be paragraphs,
by default, the former is generally better practice than the latter.

HTML elements exist to describe to the computer what the contents of
them are. In your first example, you have two "paragraph" elements,
which tells the computer some things about the structure of the
document. In the second example, you have some arbitrary text with
line break elements, which doesn't provide any useful information about
the text.

In certain contexts the latter may even be invalid code -- HTML 4.01
Strict and XHTML do not permit character data in the BODY element, so
you'd end up wrapping the text in other elements anyways. Why not use
the right ones?

[Alan J. Flavell]

On Sat, Sep 13, Chris Goldie inscribed on the eternal scroll:

Eg. 2
<br><br>My first paragraph.
<br><br>My second paragraph.

Er, no. You have told HTML they aren't paragraphs. Now you're trying
to tell _us_ that they _are_ paragraphs.

There's an old dictum, attributed to Henry Spencer: "If you lie to the
compiler, it will get its revenge"; and that has to apply even more
strongly to HTML, where you have even _less_ control over which HTML
rendering agent your users will be applying to your markup, than you
would have had over which compilers you used on your program source
code.

For many years it's been the case that although popular browsers
(a.k.a "Mosaic-spawn") treated <br> as a sort of command "move down by
one line", there were other browsers which understood it to be a
line-break as defined in HTML specifications. And once a line has
been broken, it's broken, so stuffing-in additional <br> tags had no
effect on them: no matter how many successive <br> they got, they
simply produced one line break, and continued rendering on the
immediately following line.

Take for example the definition in HTML4.01:

| The BR element forcibly breaks (ends) the current line of text.

With the second "br" in <br><br> there _is_ no "current line of text"
to be broken, so I think it's fair to state that the behaviour is
undefined.

[C A Upsdell]

"Alan J. Flavell" <fl*****@mail.cern.ch> wrote in message
news:Pi******************************@lxplus078.ce rn.ch...

On Sat, Sep 13, Chris Goldie inscribed on the eternal scroll:

Eg. 2
<br><br>My first paragraph.
<br><br>My second paragraph.

Er, no. You have told HTML they aren't paragraphs. Now you're trying
to tell _us_ that they _are_ paragraphs.

There's an old dictum, attributed to Henry Spencer: "If you lie to the
compiler, it will get its revenge"; and that has to apply even more
strongly to HTML, where you have even _less_ control over which HTML
rendering agent your users will be applying to your markup, than you
would have had over which compilers you used on your program source
code.

For many years it's been the case that although popular browsers
(a.k.a "Mosaic-spawn") treated <br> as a sort of command "move down by
one line", there were other browsers which understood it to be a
line-break as defined in HTML specifications. And once a line has
been broken, it's broken, so stuffing-in additional <br> tags had no
effect on them: no matter how many successive <br> they got, they
simply produced one line break, and continued rendering on the
immediately following line.

Take for example the definition in HTML4.01:

| The BR element forcibly breaks (ends) the current line of text.

With the second "br" in <br><br> there _is_ no "current line of text"
to be broken, so I think it's fair to state that the behaviour is
undefined.

Which is why I would do <br>&nbsp;<br>

[Stan Brown]

In article
<L3******************@news04.bloor.is.net.cable.ro gers.com> in
comp.infosystems.www.authoring.html, C A Upsdell <cupsdell0311XXX@->
wrote:

"Alan J. Flavell" <fl*****@mail.cern.ch> wrote in message
news:Pi******************************@lxplus078.c ern.ch...

With the second "br" in <br><br> there _is_ no "current line of text"
to be broken, so I think it's fair to state that the behaviour is
undefined.

Which is why I would do <br>&nbsp;<br>

This reminds me of the Ptolemaic astronomers and their epicycles.
When they found that the orbits calculated from circles didn't match
the observed positions of the planets, they added more circles.

Instead, the answer was to get rid of the multiple circles per orbit
and use a single ellipse, because that's what the planet was
actually doing.

In the same way, if you have a paragraph you shouldn't be adding
other stuff to non-paragraph markup in hopes that a browser will
render it like a paragraph. You should just mark it up as a
paragraph, if that's what it is.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/

[Lauri Raittila]

In article <2k******************@news02.tsnz.net>, Chris Goldie wrote:

From an accessibility point of view, is there any advange in using <P>
over <br>?
Yes, many.
are they both accessible?
No. If you have paragraph, mark it as paragraph. No exeptions.

In fact there is zero reason to use <br><br> for paragraphs

(Also, if you don't have paragraph, dont mark it as one - I have been
cursing those many idiots that think marking their menu as paragraph is
good idea.)
Eg. 1
<p>My first paragraph.</p>
<p>My second paragraph.</p>
I get my paragraphs short enaugh, and with best possible font.
Eg. 2
<br><br>My first paragraph.
<br><br>My second paragraph.

I will often get text that requires horizontal scrolling for each line.
And font is sometimes suboptimal, or unreadable.

These are the ones I notice on everyday surfing. Others have mentioned
others.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

[Shawn K. Quinn]

Chris Goldie wrote:

From an accessibility point of view, is there any advange in using <P>
over <br>?

eg, whats the difference between these two examples, are they both
accessible?

Eg. 1
<p>My first paragraph.</p>
<p>My second paragraph.</p>
This is good structural HTML.
Eg. 2
<br><br>My first paragraph.
<br><br>My second paragraph.

This is garbage, and does not always do what you think it does. If these are
contained directly in <body> this is invalid HTML 4.01 Strict (Transitional
let you get away with this but you shouldn't be using it anymore).

--
Shawn K. Quinn

[Shawn K. Quinn]

C A Upsdell wrote:

"Alan J. Flavell" <fl*****@mail.cern.ch> wrote in message
news:Pi******************************@lxplus078.ce rn.ch...

Take for example the definition in HTML4.01:

| The BR element forcibly breaks (ends) the current line of text.

With the second "br" in <br><br> there _is_ no "current line of text"
to be broken, so I think it's fair to state that the behaviour is
undefined.

Which is why I would do <br>&nbsp;<br>

And why the heck would you do this instead of suggesting a margin or padding
in CSS?

We've moved beyond this kind of ridiculous hackery. It was (maybe) state of
the art in 1996 (though I'd still say it was poor practice then as much as
now).

--
Shawn K. Quinn

[Juha Häikiö]

Lauri Raittila wrote:

(Also, if you don't have paragraph, dont mark it as one - I have been
cursing those many idiots that think marking their menu as paragraph
is good idea.)

Damn! Just the other day I considered starting to use div's for
TOC entries, but didn't dignose myself an idiot for using p's... :-)

Then I wondered if I should use an ol-structure for TOC: the entries
do form an ordered, hierarchical list. Also the menu list has been
deprecated in favor for ul.

But how about <table> -- for a Table of Contents?
--
Juha Häikiö

[Kris]

In article <bk**********@newsread2.funet.fi>,
"Juha Häikiö" <ju*********@stuk.fi> wrote:

But how about <table> -- for a Table of Contents?

Essentially, yes:

Chapter: Title: Pagenumber:
Chapter 1 --> The origin of sliced pizza --> Page 3
Chapter 2 --> Why Mario thought alt.pizza wasn't helping --> Page 5

--
Kris
kr*******@xs4all.netherlands (nl)

[Jukka K. Korpela]

"Juha Häikiö" <ju*********@stuk.fi> wrote:

Then I wondered if I should use an ol-structure for TOC: the entries
do form an ordered, hierarchical list. Also the menu list has been
deprecated in favor for ul.
The essential difference between <ol> and <ul> is that items in <ol> are
to be presented as numbered, items in <ul> are not. The difference is
mostly presentational only, though it might be regarded as semi-
structural.

But in practice, the choice can be based on a simple question: are the
available numbering schemes for <ol> suitable for your needs? For simple
numbered lists, the answer is mostly "yes", since you can affect the type
of numbering in HTML or in CSS (or both). However, _fine_ tuning the
numbering style gets impossible if you use <ol>. For example, most
browsers use periods ("1.", "2.", ...), which violates e.g. the Finnish
orthography standard (SFS 4175) as well as the international standard
ISO 2145. Whether you should apply those standards is a different issue,
but if you decide to, or need to, then <ol> isn't really for you.

For _nested_ lists, which are very common in tables of content, <ol> is
rather questionable. There is no effective way of making the numbering
reflect the nesting.

So for quite a many purposes, <ul> is the practical choice even if you
want the items numbers. It's best to include numbers into the items
themselves and use ul { list-style-type: none; } to suppress the bullets.
For an example of what I mean, see
http://www.cs.tut.fi/~jkorpela/rfc/2396/toc.html
But how about <table> -- for a Table of Contents?

Possible, but mostly unnessarily complicated. Any list can be trivially
regarded as a special case of a table, but in most cases list markup is
more natural and easier to style.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Juha Häikiö]

Jukka K. Korpela wrote:

The essential difference between <ol> and <ul> is that items in <ol>
are to be presented as numbered, items in <ul> are not. The
difference is mostly presentational only, though it might be regarded
as semi- structural.

With 'semi-structural', do you mean the numeric presentation or
semantic difference between <ol> and <ul>?

Consider this:

<ol style="list-style-type:none">
<li>Abstract
<li>Introduction
</ol>

<ul style="list-style-type:decimal;">
<li>Abstract
<li>Introduction
</ul>
In the first example, the order of the list items matters.
List markers are suppressed as efficiently as with <ul>.

In the second example, the order of the list items has no
significance. Numbering is purely presentational, like in
listing of a computer code.

--
Juha Häikiö

[Jukka K. Korpela]

"Juha Häikiö" <ju*********@stuk.fi> wrote:

With 'semi-structural', do you mean the numeric presentation or
semantic difference between <ol> and <ul>?

I mean the view that in <ol>, the order in which the items appear is
essential whereas in <ul> it is casual. For example, for a food recipe,
the list of ingredients would be <ul> in this sense while the description
of the preparation procedure, describing actions to be taken in
succession, is <ol>. But you might still want to have the ingredients
numbered, for easy reference or for other reasons.

This seems to correspond pretty well what you present as an example.
But in practice, making <ol> bulleted or <ul> numbered could be confusing.
This however depends on the numbering scheme. We might regard
"1.", "2.", ... as indications of a relevant order, whereas
"a.", "b.", ... could more easily be understood just as labels comparable
to bullets.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html