> cuando encuentran dos de nivel 1
> no me dicen que haya el más mínimo problema de accesibilidad.


Seguro que no lo hay. Tampoco lo habría si todos los párrafos del sitio
fueran marcados como "h6". No estamos frente a un problema de
accesibilidad, sino más bien de estructuración de contenidos; lo que
algunos llaman "arquitectura de la información" aplicada a nivel de "un"
solo documento.


> Entienden
> rápidamente que uno de ellos identifica al sitio y el otro a los
> contenidos, y santas pascuas. No tienen 18 encabezados de nivel 1, sólo
> dos, lo que me permite crear estructuras mejores para la navegación.


No entiendo cuáles serían esas "estructuras mejores para la navegación"
que mencionas, ¿puedes poner un ejemplo en código? No creo que por
repetir el h1 obtengas ninguna mejora en la estructura, pero si veo tu
ejemplo tal vez te dé la razón (o confirme mi suposición) <guiño>.


>
> Todavía no sé cuál es exactamente el problema de tener dos encabezados
> de nivel 1, o incluso 3, 4 o más.


Depende desde qué contexto definimos el "problema":

a) Si nos limitamos a mirarlo desde la accesibilidad, no hay problemas
en poner un "h1" o veinte "h1".

b) Si nos limitamos a mirarlo desde el Diseño CSS, tampoco es problema
la cantidad de "h1" del documento. Como bien dice Camilo, todo puede
acomodarse con CSS, comparto esa postura de que el orden de los grandes
bloques (divisiones, "divs") dentro del código es indistinto.

c) Pero si hablamos de "h1", que es una etiqueta de un lenguaje de
"marcado", es porque estamos hablando de etiquetar contenidos, estamos
hablando de HTML o XHTML (o XML), que son lenguajes cuyo objetivo es dar
una "jerarquía" a los contenidos marcados. Estamos hablando de
estructurar información. Desde ese punto de vista es que veo la
incongruencia de usar más de un "h1", aun cuando no haya "leyes" que lo
digan explícitamente (aunque Emmanuelle citó más de una referencia de peso).

Todos los lenguajes de marcado que usamos comparten el organizar sus
elementos (etiquetas de una página) en forma de "árbol", donde hay un
elemento raíz (la etiqueta "html"), que se va dividiendo en elementos
"ramas" (las etiquetas "head" y "body"), dentro de las cuales aparecen
"sub-ramas", que en el caso del "body" serían las divisiones de bloque
(etiquetas "div" y similares de bloque, entre ellas los encabezados), y
en último lugar dentro de esa estructura de árbol, quedan los contenidos
textuales y otros, que serían las "hojas" del árbol.

Es lo que en lenguajes de script se conoce como "DOM" (Document Object
Model, o Modelo de Objetos del Documento).

Para ser gráfico, colocar un "h1" fuera de una división me parece tan
extraño como colocar una hoja de roble colgando de la raíz, sin pasar
antes por la rama... No digo que esté taxativamente mal, ya que no hay
una "normativa", pero sí que va contra mi razonamiento.

Y si el menú es una "rama" y el contenido es otra "rama", aunque ambas
podrían tener un "h1" dentro, no veo la necesidad de ponerlo dentro del
menú, o del encabezado.

Creo que solo tiene sentido el "h1" dentro del contenido, de la
información, del cuerpo, de la noticia (vamos, ya no sé cómo explicar
esto, que los menúes no son la información, el mapa no es el territorio,
sino una herramienta para ir por él, y por lo tanto "no es parte" de
él!). No veo el sentido de anteponer un "h" de ningún nivel a un menú,
ni a un banner, ni a un logo, ni a un pie de página. Son todos elementos
"accesorios" del contenido principal. Son la cubierta y la solapa del
libro, son un señalador, un folleto que pones dentro del libro, pero no
son "la novela". Son ajenos a ella.


> Sigo sin saber qué problema *real* puede causar que haya dos encabezados
> de nivel 1. Mis usuarios no me dicen que lo haya, de verdad. Ni uno.
> Pero si lo hay, me gustaría saber *cuál* es ese problema.


Hombre, los problemas no son "más reales" por circunscribir su alcance
exclusivamente a la perspectiva de la "accesibilidad de los usuarios
ciegos". La web no es solo accesibilidad, también hay otros aspectos a
considerar, como el de la Arquitectura de la Información (que no tiene
por qué afectar la accesibilidad, todo lo contrario, tiende a
mejorarla). Yo creo que el "problema REAL" que estamos discutiendo se
define como "problema" solo si lo miramos desde la arquitectura de la
información. Para las demás especialidades no es problema.


>
>> 4) Uno (y solo uno) de esos bloques, contendrá sin duda el "Título MAS
>> importante" del documento. El que le da nombre, el que dice de qué va la
>> cosa.
>>
> Nadie discute eso. Pero eso no impide que podamos ser prácticos para
> mejorar la accesibilidad, sin estar atados por una restricción que, en
> realidad, es meramente filosófica y que, desde mi punto de vista, causa
> más problemas de los que pretende arreglar.


Muéstrame un ejemplo de cómo "mejoras" la accesibilidad (no que la
"mantienes", sino que haya "mejoras" notorias) usando dos "h1" en vez de
uno, y te daré la razón.


>
>> Da igual. Algunos colocan este "Título MAS importante" como texto,
>> y otros como texto alternativo de una imagen. Da igual.
>>
> No da igual. Como usuario con pdificultades visuales, si el encabezado
> es exclusivamente una imagen, puedo llegar a no percibirlo como tal
> encabezado.

Cierto. Tienes toda la razón. No da igual. El encabezado "h1" debería
ser siempre un texto.

>
>> Me pregunto: ¿tiene sentido que haya más de un "Título MAS importante"
>> de la página? En todo caso, habrá varios "Títulos bastante importantes",
>> pero UNO, y solo un "Título MAS importante" que todos los demás.
>>
> Me pregunto: si no tiene ningún sentido que haya más de un H1, ¿por qué
> en ninguna especificación de HTML/XHTML se ha incluido una restricción
> para que pueda haber más de un H1 en una página?


Porque no lo previeron, seguramente. Hay tantas cosas que no previeron!
jaja! Demasiadas!! Nadie es perfecto... pero preveámoslo nosotros mismos
con algún criterio.


> Casi. Hay muchas situaciones en las que eso no es posible. CSS no lo
> puede todo, y mucho menos si contamos con las implementaciones que de
> CSS hacen algunos navegadores. Prueba esto: un diseño líquido con dos
> divs horizontales seguidos; el contenido de ambos puede crecer de forma
> independiente. Ahora, colócalos en el orden inverso al que están en el
> código, de forma que el segundo se vea por encima del primero, y sin
> solapamientos. Y que sea multinavegador. ¡Suerte!

¿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.

A ver: no estoy de acuerdo con el desafío que propones, simplemente
porque no tiene sentido. Si tienes dos "div", uno para el menú y otro
para el contenido, puedes decidir básicamente que colocas el menú:
1) a la izquierda,
2) a la derecha,
3) antes o
4) después del contenido. No se me ocurre más (sí, encima del contenido,
pero no sería muy práctico que digamos...)

Si el div "contenido" viene primero en el código y luego el "menú", la
forma respectiva de acomodar eso con CSS sería:

1) #contenido {float: right;} #menu {float: right;}

2) #contenido {float: left;} #menu {float: left;}

3) (esta es la que te preocupa): depende de haber creado un CONTENEDOR
para ambos, definido con "position: relative;" y luego usas "position:
absolute" para ubicar el menú antes que el contenido, previendo dejar un
espacio libre suficiente para el caso de que se "caiga" el menú a una
segunda línea. Pides a tus usuarios con dificultades visuales que te
digan a qué nivel de zoom llevan la página como máximo, y tomas nota. De
todos modos, si tienes previsto que el menú deba ir antes del
contenido... ¡por qué no marcarlo así!

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...

4) es la que se da espontáneamente, no hay nada que especificar.

Entonces, pregunto: ¿qué problema hay con que el "div" del menú esté
antes o después en el código que el "div" del contenido? Si el "h1"
estará dentro del div "contenido", ¿qué relación tiene esto con la
ubicación del div menú? Ninguna... son dos piezas independientes, dos
"bloques" o "divisiones" (divs) distintos.

>
>> A los únicos que les importa que el "Título MAS importante" de la página
>> quede al principio del código es a los que hacen posicionamiento web
> A mí lo que me importa es que haya una buena estructura, y poner ese
> primer H1 al principio, aunque no me guste desde el punto de vista
> semántico o filosófico, es lo que necesito para lograrlo sin saltarme la
> jerarquía.

¿A qué te refieres con "primer h1"? ¿Estás hablando de un logo, de un
menú, en fin, dónde podrías ese primer "h1"? Danos un ejemplo a ver si
logramos entender la ventaja.

>
>> En fin, solo unas ideas como para aportar al debate.
>>
> Todas las ideas son bienvenidas (espero que las mías también) <guiño>
>

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.

Saludos!

Hernán Beati
www.saberweb.com.ar