DOCTYPE for general public - when will accessibility override browser compatibility?

[Simon Shutter]

Forgive me if I am posting to wrong newsgroup and for a couple of loaded
questions.

First, from what I understand, one of the advantages of XHTML/CSS is the
ability of screen readers/braille agents to provide an improved experience
than HTML with table layout. Notwithstanding the leadership of Chevrolet,
Amnesty International and others, at what point do you think XHTML/CSS will
become the preferred approach? Will it be when the number of IE5.x users
drops below the number of users who rely on screen readers/braille agent?

Second, if one is forced to use HTML with table layout, is there a best
practice of coding that facilitates migration to XHTML/CSS when the web site
owner can be convinced of its advantages?

tx

[Andreas Prilop]

On Wed, 31 Aug 2005, Simon Shutter wrote:

First, from what I understand, one of the advantages of XHTML/CSS is the
ability of screen readers/braille agents to provide an improved experience
than HTML with table layout.

No. Why is it that so many people speak of
"'XHTML with CSS' vs. 'HTML with tables'"?

I don't get it!

--
Top-posting.
What's the most irritating thing on Usenet?

[Michael Winter]

On 31/08/2005 17:14, Simon Shutter wrote:

[snip]

First, from what I understand, one of the advantages of XHTML/CSS is
the ability of screen readers/braille agents to provide an improved
experience than HTML with table layout.
It isn't the combination of XHTML and CSS that might provide any
improvement, but rather the use of semantic markup. The markup language
involved is irrelevant; HTML is just as good as XHTML (better,
possibly). After all, one can still author bloated documents using
Transitional XHTML 1.0, and indeed the vast majority of XHTML documents
probably are written this way (certainly from what I've seen).

There is nothing intrinsically inaccessible about HTML, and even
table-based layouts can be accessible (but WYSIWYG-authored documents
rarely will be).
[...] at what point do you think XHTML/CSS will become the preferred
approach?
When the overwhelming majority of user agents support XHTML properly.
Until then, use HTML with CSS.
Will it be when the number of IE5.x users drops below the number of
users who rely on screen readers/braille agent?
IE5 isn't the issue; IE in general is as no current versions support
XHTML (and I don't believe IE7 will, either). Poor CSS support is
usually manageable.
Second, if one is forced to use HTML with table layout, is there a best
practice of coding that facilitates migration to XHTML/CSS [...]

You will undoubtedly be rewriting the markup from scratch, so it isn't a
concern. A HTML to XHTML transformation can be performed mechanically,
which is why HTML is preferable until XHTML is feasible. Even when using
XML-based tools, the output should be transformed to HTML (unless there
are some overriding reasons not to).

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

[Simon Shutter]

Michael,

Thank you for your considered response.

You're right that I'm looking at fixing an old site that has inappropriate
use of HTML tags and has not leveraged CSS. So, an update to HTML/CSS would
solve most problems. I just thought that XHTML would be more accessible.
Having seen that some major corporate sites like chevrolet.com are migrating
to XHTML Strict with CSS for layout, I thought this might be a sign of a
threshold being reached. If, by writing clean HTML, I can automatically
convert to XHTML, then perhaps that is what I should do. But, rightly or
wrongly, I have influenced by alistapart and webstandards org who appear to
advocate XHTML where possible.

With regard to your comment about IE7 and XHTML, the following article
suggests that MS VS Web Developer and ASP.NET 2.0 will support XHTML so I
hope they aren't going to let IE7 languish - that would be embarrassing.

http://msdn.microsoft.com/asp.net/de...pnetusstan.asp

Simon
"Michael Winter" <m.******@blueyonder.co.uk> wrote in message
news:Gi******************@text.news.blueyonder.co. uk...

On 31/08/2005 17:14, Simon Shutter wrote:

[snip]

First, from what I understand, one of the advantages of XHTML/CSS is
the ability of screen readers/braille agents to provide an improved
experience than HTML with table layout.

It isn't the combination of XHTML and CSS that might provide any
improvement, but rather the use of semantic markup. The markup language
involved is irrelevant; HTML is just as good as XHTML (better,
possibly). After all, one can still author bloated documents using
Transitional XHTML 1.0, and indeed the vast majority of XHTML documents
probably are written this way (certainly from what I've seen).

There is nothing intrinsically inaccessible about HTML, and even
table-based layouts can be accessible (but WYSIWYG-authored documents
rarely will be).

[...] at what point do you think XHTML/CSS will become the preferred
approach?

When the overwhelming majority of user agents support XHTML properly.
Until then, use HTML with CSS.

Will it be when the number of IE5.x users drops below the number of
users who rely on screen readers/braille agent?

IE5 isn't the issue; IE in general is as no current versions support
XHTML (and I don't believe IE7 will, either). Poor CSS support is
usually manageable.

Second, if one is forced to use HTML with table layout, is there a best
practice of coding that facilitates migration to XHTML/CSS [...]

You will undoubtedly be rewriting the markup from scratch, so it isn't a
concern. A HTML to XHTML transformation can be performed mechanically,
which is why HTML is preferable until XHTML is feasible. Even when using
XML-based tools, the output should be transformed to HTML (unless there
are some overriding reasons not to).

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

[Benjamin Niemann]

Simon Shutter wrote:

Will it be when the number of IE5.x users drops below the number of
users who rely on screen readers/braille agent?

IE5 isn't the issue; IE in general is as no current versions support
XHTML (and I don't believe IE7 will, either). Poor CSS support is
usually manageable.

With regard to your comment about IE7 and XHTML, the following article
suggests that MS VS Web Developer and ASP.NET 2.0 will support XHTML so I
hope they aren't going to let IE7 languish - that would be embarrassing.

http://msdn.microsoft.com/asp.net/de...pnetusstan.asp

They are just jumping on the XHTML-as-text/html train as everyone else with
an unhealthy addiction to buzzwords.

The document says:
<quote>
There is one glaring problem with the W3C's recommendation: not all browsers
recognize application/xhtml+xml. In particular, Internet Explorer (the most
popular Web browser in the history of the world) does not recognize the
application/xhtml+xml MIME type. Therefore, serving your XHTML pages using
the recommended application/xhtml+xml MIME type is not a viable option.
</quote>

And they do not mention IE7 at all....

--
Benjamin Niemann
Email: pink at odahoda dot de
WWW: http://www.odahoda.de/

[Alan J. Flavell]

On Wed, 31 Aug 2005, Simon Shutter wrote:

Forgive me if I am posting to wrong newsgroup and for a couple of
loaded questions.
I suspect a troll, but I'll try one response before reaching a
conclusion...
First, from what I understand, one of the advantages of XHTML/CSS is
the ability of screen readers/braille agents to provide an improved
experience than HTML with table layout.
That's a very narrow outlook on the concept. It's about separation of
content from presentation (something which the web does anyway, but by
making that separation explicit it's possible to capitalise on it).
Notwithstanding the leadership of Chevrolet, Amnesty International
and others,
Was there any reason to suppose that these organisations would be
experts on web authoring techniques? (Many big organisations
outsource to graphic design houses, who understand even less how to
translate their glossy paper designs to the adaptable web...)
at what point do you think XHTML/CSS will become the preferred
approach?
The use of a stylesheet *was* the preferred approach *before* the
early Netscape folks started down the road of "presentational"
quasi-HTML. But it never got a chance to be fully implemented before
the fans of instant gratification rushed off to do visual design with
their presentational HTML attributes. Now, many years later, we're
just recovering the original position.

The use of tables as a tool for achieving a presentational layout was,
and is, really a rather small part of that general philosophy.

The worst part of tables-for-layout is that it works - and works - and
persists in working, no matter how unreasonable that turns out to be
in browsing situations which are far from what the original designer
had in mind. And that, then, is ingrained into the HTML itself,
instead of being a presentation proposal in an optional stylesheet.

I'm far from clear why you think XHTML might be opposed to HTML in
this/these respect(s). The dichotomy is really between (X)HTML strict
on the one hand, and (X)HTML transitional on the other. It's a great
pity that the W3C ever bothered to prove that HTML4.* transitional
coulde be expressed in XHTML/1.0: I'm not sure whether they ever
expected XHTML/1.0 Transitional to be taken seriously, rather than
dismissed as a mere proof of concept, unfit for practical deployment.
Second, if one is forced to use HTML with table layout, is there a
best practice of coding that facilitates migration to XHTML/CSS when
the web site owner can be convinced of its advantages?

Not really. It's not something that can be done by feeding the old
markup into some kind of black box, and expecting sensible
strict-(X)HTML and CSS to come out the other side! That's why
presentational quasi-HTML was such a waste of everyone's effort. To
do the job properly, with strict HTML marking-up the logical structure
without reference to presentation, and stylesheet(s) proposing
optional presentation(s) for various client-agent situation(s), means
basically starting again from the original content, and re-engineering
the site from scratch.

What's more likely to happen in practice IMHO is that /existing/ pages
will remain as they are, because it's just not worth re-engineering
them to remove the ingrained presentational stuff from their
"transitional" HTML. But new sites have already started exploiting
the benefits of the other approach - and browsing situations are
getting *more* diverse with time.

As time goes by, the differences between the two approaches are likely
to show more and more, especially in those diverse browsing situations
- of which, disability access is an important part, but not by any
means the only browsing situation that differs from the assumed
regular desktop with the assumed regular resolution and window size.

IMHO and YMMV, natch.

[Simon Shutter]

Alan,

Thanks for the well written response. I may be ignorant but I am not a
troll. I'm actually half-Glaswegian.

Simon

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote in message
news:Pi*******************************@ppepc56.ph. gla.ac.uk...

On Wed, 31 Aug 2005, Simon Shutter wrote:

Forgive me if I am posting to wrong newsgroup and for a couple of
loaded questions.

I suspect a troll, but I'll try one response before reaching a
conclusion...

First, from what I understand, one of the advantages of XHTML/CSS is
the ability of screen readers/braille agents to provide an improved
experience than HTML with table layout.

That's a very narrow outlook on the concept. It's about separation of
content from presentation (something which the web does anyway, but by
making that separation explicit it's possible to capitalise on it).

Notwithstanding the leadership of Chevrolet, Amnesty International
and others,

Was there any reason to suppose that these organisations would be
experts on web authoring techniques? (Many big organisations
outsource to graphic design houses, who understand even less how to
translate their glossy paper designs to the adaptable web...)

at what point do you think XHTML/CSS will become the preferred
approach?

The use of a stylesheet *was* the preferred approach *before* the
early Netscape folks started down the road of "presentational"
quasi-HTML. But it never got a chance to be fully implemented before
the fans of instant gratification rushed off to do visual design with
their presentational HTML attributes. Now, many years later, we're
just recovering the original position.

The use of tables as a tool for achieving a presentational layout was,
and is, really a rather small part of that general philosophy.

The worst part of tables-for-layout is that it works - and works - and
persists in working, no matter how unreasonable that turns out to be
in browsing situations which are far from what the original designer
had in mind. And that, then, is ingrained into the HTML itself,
instead of being a presentation proposal in an optional stylesheet.

I'm far from clear why you think XHTML might be opposed to HTML in
this/these respect(s). The dichotomy is really between (X)HTML strict
on the one hand, and (X)HTML transitional on the other. It's a great
pity that the W3C ever bothered to prove that HTML4.* transitional
coulde be expressed in XHTML/1.0: I'm not sure whether they ever
expected XHTML/1.0 Transitional to be taken seriously, rather than
dismissed as a mere proof of concept, unfit for practical deployment.

Second, if one is forced to use HTML with table layout, is there a
best practice of coding that facilitates migration to XHTML/CSS when
the web site owner can be convinced of its advantages?

Not really. It's not something that can be done by feeding the old
markup into some kind of black box, and expecting sensible
strict-(X)HTML and CSS to come out the other side! That's why
presentational quasi-HTML was such a waste of everyone's effort. To
do the job properly, with strict HTML marking-up the logical structure
without reference to presentation, and stylesheet(s) proposing
optional presentation(s) for various client-agent situation(s), means
basically starting again from the original content, and re-engineering
the site from scratch.

What's more likely to happen in practice IMHO is that /existing/ pages
will remain as they are, because it's just not worth re-engineering
them to remove the ingrained presentational stuff from their
"transitional" HTML. But new sites have already started exploiting
the benefits of the other approach - and browsing situations are
getting *more* diverse with time.

As time goes by, the differences between the two approaches are likely
to show more and more, especially in those diverse browsing situations
- of which, disability access is an important part, but not by any
means the only browsing situation that differs from the assumed
regular desktop with the assumed regular resolution and window size.

IMHO and YMMV, natch.

[Andy Dingley]

On Wed, 31 Aug 2005 16:22:22 -0700, "Simon Shutter" <[e-mail]> wrote:

I am not a troll. I'm actually half-Glaswegian.

Lots of bridges, an underground railway system
and they like a "soft drink" made from girders.

You're no convincing me, Jimmy.

[Chris Morris]

"Simon Shutter" <[e-mail]> writes:

First, from what I understand, one of the advantages of XHTML/CSS is the
ability of screen readers/braille agents to provide an improved experience
than HTML with table layout.
Well, as already said the HTML/XHTML distinction is irrelevant.

The CSS/table -layout distinction is the important one, but why it's
an advantage isn't quite what you say. There are two ways of setting
out a layout - linearising and non-linearising.

A linearising layout (CSS or tables), if viewed in a situation where
the feature producing the layout is absent, will still display the
content in a sensible order.
A non-linearising layout does not.

For example, the (poor quality) table layout:
<table><tr><td>News headline 1</td><td>News headline 2</td></tr>
<tr><td>News article 1</td><td>News article 2</td></tr></table>
is not a linearising layout, as if tables are not supported the two
headlines will be first, then the two articles.

To be friendly to screen readers/braille it is vital that the layout
(whether CSS or table-based) is linearising. There are then secondary
smaller advantages for screen readers/braille when tables are only
used for data and not for layout as well (some audio user-agents have
sophisticated table-rendering modes) but these are much smaller
differences than the linearising/non-linearising difference.

Additionally, good linearisation will help in a wide range of other
circumstances.

Nevertheless, table layout is a bad idea because it does give a big
disadvantage in other areas. Accessibility isn't solely about
visually-impaired users.

Table layout causes massive usability and accessibility problems when
the browser supports tables, but doesn't have the display width to
display them well. Examples include browsers on mobile phones or PDAs,
and text-mode browsers such as w3m or links 2. On these, a table
layout can give columns a single character wide, or require horizontal
scrolling back and forth twenty times just to read a paragraph. So can
a CSS layout, of course, but it is easier to avoid this problem with
those.

For a data table these restrictions on width are unavoidable and
bearable, because of the column-by-column or row-by-row way in which
these tables are read. For a layout table it makes the pages
incredibly difficult to use.
Second, if one is forced to use HTML with table layout, is there a best
practice of coding that facilitates migration to XHTML/CSS when the web site
owner can be convinced of its advantages?

Use a preprocessor, server-side scripting, or other appropriate
templating system, so that the page content is stored separately from
the navigation structure and the template design. That way you can
switch the template without interfering with anything else.

In theory, anyway - in practice you may have bits of content code that
need tidying up as well - make sure all the HTML code is valid and you
probably greatly reduce the amount you'll need to do this.

--
Chris

[Andreas Prilop]

On Thu, 1 Sep 2005, Benjamin Niemann wrote:

http://msdn.microsoft.com/asp.net/de...pnetusstan.asp

They are just jumping on the XHTML-as-text/html train as everyone else with
an unhealthy addiction to buzzwords.

The document says:

The stylesheet says:

| font-size: 80%

[Martin Honnen]

Simon Shutter wrote:

With regard to your comment about IE7 and XHTML, the following article
suggests that MS VS Web Developer and ASP.NET 2.0 will support XHTML so I
hope they aren't going to let IE7 languish - that would be embarrassing.

http://msdn.microsoft.com/asp.net/de...pnetusstan.asp

Yes, ASP.NET 2.0 has features to generate XHTML markup and that article
even claims you can serve as text/html to browsers like IE but also as
application/xhtml+xml to browsers like Mozilla or Opera. However some
days ago I have looked into that and discovered that it breaks horribly
if you serve the stuff as application/xhtml+xml. The reason is that lots
of the .NET controls you use on the server that then emit XHTML also
need script to work and emit that script inline in the XHTML document.
But .NET does that in the following way
<script type="text/javascript">
<!--
script code goes here
//-->
</script>
which is fine (or at least possible) when being served as text/html but
means that an XML parser parsing the XHTML document doesn't see the
script code as it it the content of an XML comment inside of the
<script> element.
Thus I filed a bug on ASP.NET 2.0
<http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=9060983f-d910-48d4-8791-f39a323b9e8c>
but the response is "behavior is by design" and "we do this to comply
with XHTML standards".
Not sure what XHTML standards they have in mind but my bug report points
to <http://www.w3.org/TR/xhtml1/#C_4> and that clearly states
"Note that XML parsers are permitted to silently remove the contents of
comments. Therefore, the historical practice of "hiding" scripts and
style sheets within "comments" to make the documents backward compatible
is likely to not work as expected in XML-based user agents."
Thus the XHTML 1.0 standard explictly warns not to do what they claim to
do "to comply with XHTML standards".

So ASP.NET 2.0 as a platform to create XHTML makes those mistakes people
have warned for a long time:
<http://www.hixie.ch/advocacy/xhtml>

--

Martin Honnen
http://JavaScript.FAQTs.com/

[Simon Shutter]

Chris,

Those are very helpful comments. Thank you for your patience and clarity.

Simon
"Chris Morris" <c.********@durham.ac.uk> wrote in message
news:87************@dinopsis.dur.ac.uk...

"Simon Shutter" <[e-mail]> writes:

First, from what I understand, one of the advantages of XHTML/CSS is the
ability of screen readers/braille agents to provide an improved
experience
than HTML with table layout.

Well, as already said the HTML/XHTML distinction is irrelevant.

The CSS/table -layout distinction is the important one, but why it's
an advantage isn't quite what you say. There are two ways of setting
out a layout - linearising and non-linearising.

A linearising layout (CSS or tables), if viewed in a situation where
the feature producing the layout is absent, will still display the
content in a sensible order.
A non-linearising layout does not.

For example, the (poor quality) table layout:
<table><tr><td>News headline 1</td><td>News headline 2</td></tr>
<tr><td>News article 1</td><td>News article 2</td></tr></table>
is not a linearising layout, as if tables are not supported the two
headlines will be first, then the two articles.

To be friendly to screen readers/braille it is vital that the layout
(whether CSS or table-based) is linearising. There are then secondary
smaller advantages for screen readers/braille when tables are only
used for data and not for layout as well (some audio user-agents have
sophisticated table-rendering modes) but these are much smaller
differences than the linearising/non-linearising difference.

Additionally, good linearisation will help in a wide range of other
circumstances.

Nevertheless, table layout is a bad idea because it does give a big
disadvantage in other areas. Accessibility isn't solely about
visually-impaired users.

Table layout causes massive usability and accessibility problems when
the browser supports tables, but doesn't have the display width to
display them well. Examples include browsers on mobile phones or PDAs,
and text-mode browsers such as w3m or links 2. On these, a table
layout can give columns a single character wide, or require horizontal
scrolling back and forth twenty times just to read a paragraph. So can
a CSS layout, of course, but it is easier to avoid this problem with
those.

For a data table these restrictions on width are unavoidable and
bearable, because of the column-by-column or row-by-row way in which
these tables are read. For a layout table it makes the pages
incredibly difficult to use.

Second, if one is forced to use HTML with table layout, is there a best
practice of coding that facilitates migration to XHTML/CSS when the web
site
owner can be convinced of its advantages?

Use a preprocessor, server-side scripting, or other appropriate
templating system, so that the page content is stored separately from
the navigation structure and the template design. That way you can
switch the template without interfering with anything else.

In theory, anyway - in practice you may have bits of content code that
need tidying up as well - make sure all the HTML code is valid and you
probably greatly reduce the amount you'll need to do this.

--
Chris