Hola de nuevo.

Muy rápido que tengo que hacer una maleta, jejeje... Lo primero, un
ejemplo de lo que digo para que se vea más claramente (los títulos no
tienen por qué ser esos, claro):

<div id="cabecera">
<h1>MI PAGINITA</h1>
Logotipo, tagline, cabecera, etc.
<div id="toolbar">
<h2>Páginas comunes del sitio</h2>
Opciones de acceso al mapa web, accesibilidad, contactar, etc.
<h2>Búsqueda</h2>
Formulario buscador
</div><!--/#toolbar-->
<div id="secciones">
<h2>Secciones</h2>
Enlaces a las secciones principales del sitio
<div id="subsecc">
<h3>Subsecciones nivel 2</h3>
Enlaces a las secciones de nivel 2 (en algunos casos estas irían
anidadas, no como un h3)
</div>
</div>
</div><!--/#cabecera-->

<div id="menu">
<h2>Apartados dentro de esta sección</h2>
Enlaces a los distintos apartados
</div>
<div id="extras">
<h2>Extras</h2>
Puede tener su propia subestructura de encabezados para
patrocinadores, desatacados, publicidad, etc.
</div>
<div id="contenido">
<h1>Título del contenido de esta página</h1>
Contenidos con us propia estructura de encabezados de niveles 2-6
</div>
<div id="pie">
Pie de página. normalmente común. Incluso podría tener algún <h2> para
poder ir rápidamente a él.
</div>

Ahora veamos lo que de verdad se puede hacer con CSS y lo que no...
Supongamos que las barras superiores (niveles 1 y 2) o las herramientas
tienen un número de opciones no definido a priori, o simplemente que
pueden "caerse" en varias líneas, no necesariamente a la vez, no
necesariamente todos, pero sí que existe esa posibilidad. Como bien has
apuntado, puedo colocarlos detrás en el código, y luego "subirlos" con
position: absolute, pero lo que no es lógico es reservar un hueco tan
grande como para albergar las distintas posibilidades de que esos menús
se vayan a caer a la vez. Estropearía por completo el diseño y podría
incluso producir problemas a quienes ven bien, al bajar los contenidos
fuera de la zona visible.

Lo suyo será que esas barras "empujen" al contenido que hay debajo. La
única manera de hacer eso es colocándolos delante. Tampoco me vale el
recurso de cambiar el diseño a uno elástico, porque eso provocará nuevos
problemas, al hacer salir a las opciones fuera de la ventana por la
derecha, ya que eso obligará a un usuario que ve mal a un scroll añadido
que puede ser mucho peor.

Los menús a izquierda, derecha, etc., no son ningún problema, claro que
no, incluso es posible colocar varias columnas de muy diversas formas
independientemente de cómo esté ordenado el código. Pero con las barras
horizontals, NO se puede. Y si lo logras, me dices cómo, porque me
dejarás muy sorprendido y me solucionarás muchos problemas.

Como se puede ver, esa estructura identifica con encabezados los
diferentes elementos de la interfaz. A pesar de que tú tienes la idea de
que el "contenido" sólo es la información del sitio, creo que estás en
un error. El contenido es todo, incluidos todos los elementos de
interfaz, y cuando las pautas hacen referencia al "Web Content" no creo
que excluyan la interfaz como "cosas que nos importan un pito porque no
es la información, y por lot anto no tenemos que hacerlas accesibles".
Para mí, hay que estructurar *también* ese contenido, al que los
usuarios quieren acceder de la mejor manera posible. El contenido de un
libro incluye también el índice, la tapa y la contratapa, no creo que a
nadie le gustara que sólo le dieran las páginas interiores.

En la esencia, estoy de acuerdo contigo, por supuesto que no es la mejor
arquitectura de la información, y el árbol de encabezados no refleja
literalmente la estructura de contenidos. Pero seamos realistas, con un
árbol jerárquico simple no se puede definir todo el conjunto de
relaciones complejas que existen en el hipertexto. XML permite enlaces
de salida y de entrada, permite relacionar múltiples recursos con un
único enlace, o incluso diferentes versiones de un recurso enlazado en
función de otros parámetros. La estructura de relaciones que se pueden
dar es IMPOSIBLE de reflejar en una cosa tan simple como un árbol,
requeriría un grafo complejo tridimensional con nodos y subnodos, y con
arcos unidireccionales y bidireccionales. El problema es precisamente
que estamos tratando de encajar esa superestructura en algo que más o
menos podamos entender los humanos, y eso no es posible.

> los problemas no son "más reales" por circunscribir su alcance exclusivamente
> a la perspectiva de la "accesibilidad de los usuarios ciegos".
No, claro que no. Yo te he puesto un ejemplo que no sólo ayuda a los
ciegos, aunque es a quienes más beneficia, seguramente.

> Porque no lo previeron, seguramente. Hay tantas cosas que no previeron!
>
Puede ser, pero sería extraño, la verdad. Sí que tuvieron en cuenta que
no pudiera haber más de un thead en una tabla, por ejemplo, o más de un
input dentro de un label. A mí me parece inmediato llevar el
razonamiento del thead al h1 si eso es lo que realmente se busca.

> ¿Y para qué querrías hacer ese experimento? Qué ganas de complicarte el
> diseño, jaja! Es que sin dudas, y esto lo creo con absoluta certeza, el
> éxito de un diseño con CSS depende del dominio del marcado (HTML o
> XHTML). Si marcamos mal el contenido, mal podremos "dominarlo" con CSS.
>
Pues vale, pero ese "experimento", como tú lo llamas, es algo bastante
común de ver, qué quieres que te diga.

> De todos modos, si tienes previsto que el menú deba ir antes del
> contenido... ¡por qué no marcarlo así!
>
Porque, como ya he comentado, si hago eso el h1 queda después, y rompo
la jerarquía.

> Además, sería conveniente evitar que un menú horizontal tenga un exceso
> de opciones, que llegue a caer a dos líneas: en ese caso, pues coloca
> primero el menú en el marcado, y que sean dos divs estáticos que crecen
> automáticamente! Para cada problema, busquemos la mejor solución...
>
Lo dicho, menús que, o no tendrán encabezados, o romperán la jerarquía.

> Por supuesto que sí!! Te agradezco por obligarme a poner en duda mis
> supuestos, y a percibir muchas ideas que tenía latentes y que solo del
> debate surgen con claridad.
>
Lo mismo digo, y ahora a mi maleta...

Saludos,
Ramón.