Hola gentes, tras varias horas mirando leyendo y releyendo las pautas de accesibilidad, técnicas,... hay ciertos puntos que no acaban de quedarme del todo claros.
<fieldset>3.1 Cuando exista un marcador apropiado, use marcadores en vez de imágenes para transmitir la información.</fieldset>
En las técnicas css habla de before y :after y la propiedad "content , "cue", "cue-before", y "cue-after". y no acabo de entender mucho el sentido.
<fieldset>6.4 Para los scripts y applets, asegúrese de que los manejadores de evento sean independientes del dispositivo de entrada.Técnicas HTML: Applets directamente accesibles à Si un applet (creado con OBJECT o con APPLET) precisa una interacción con el usuario (por ejemplo, la capacidad de manipular un experimento físico) que no se puede reproducir en un formato alternativo, se debe hacer el applet accesible directamente.
Si un applet causa movimiento, el diseñador debe proporcionar un mecanismo para parar este movimiento (por ejemplo, véase [TRACE]). También, consúltese el apartado siguiente para aprender cómo hacer accesibles las presentaciones de audio y vídeo.</fieldset>
<fieldset>Pauta 7. Asegure al usuario el control sobre los cambios de contenidos tempo-sensibles.</fieldset> ¿Y los gif animados/flash?
<fieldset>10.2 Hasta que las aplicaciones de usuario soporten explícitamente la asociación entre control de formulario y etiqueta, para todos los controles de formularios con etiquetas asociadas implícitamente, asegúrese de que la etiqueta está colocada adecuadamente. [Prioridad 2]</fieldset>
<fieldset>13.6 Agrupe los vínculos relacionados, identifique el grupo (para las aplicaciones de usuario) y, hasta que las aplicaciones de usuario lo hagan, proporcione una manera de evitar el grupo. [Prioridad 3] (Punto de revisión 13.6)</fieldset>
Cuando tengo alguna duda de como afontar algún tema "delicado" miro a ver como lo han solucionado en http://www.inditex.es/, uno de mis sitios accesibles de referencia.
<fieldset><blockquote>3.1 Cuando exista un marcador apropiado, use marcadores en vez de imágenes para transmitir la información.</blockquote></fieldset>
En las técnicas css habla de before y :after y la propiedad "content , "cue", "cue-before", y "cue-after". y no acabo de entender mucho el sentido.
No te líes, este es sencillo (al menos las cosas más comunes luego hay cosas raras que hay que estudiar), te dice por ejemplo que NO metas imágenes para meter textos, cosa que se da de frente con todas las tipos personalizadas metidas hasta ahora como imágenes (menús, titulares...) por eso es interesante utilizar reemplazo de imágenes, al menos guarda la semántica y es sencillo de cambiar si por casualidad te lo tiran para atrás en una auditoría.
También te dice que si metes una ecuación u otra cosa para la que existen lenguajes particulares (MathML o similares) trates de utilizar los marcadores en lugar de una imagen.
demssite
<fieldset><blockquote>6.4 Para los scripts y applets, asegúrese de que los manejadores de evento sean independientes del dispositivo de entrada.Técnicas HTML: Applets directamente accesibles à Si un applet (creado con OBJECT o con APPLET) precisa una interacción con el usuario (por ejemplo, la capacidad de manipular un experimento físico) que no se puede reproducir en un formato alternativo, se debe hacer el applet accesible directamente.
Si un applet causa movimiento, el diseñador debe proporcionar un mecanismo para parar este movimiento (por ejemplo, véase [TRACE]). También, consúltese el apartado siguiente para aprender cómo hacer accesibles las presentaciones de audio y vídeo.</blockquote></fieldset>
<fieldset><blockquote>Pauta 7. Asegure al usuario el control sobre los cambios de contenidos tempo-sensibles.</blockquote></fieldset> ¿Y los gif animados/flash?
Pues ahora ya sabes por qué se desaconseja Flash... En la práctica la cosa se resumen en que hagas lo que hagas con Flash (o javascript) tengas una alternativa que haga lo mismo sin ambas tecnologías.
Si hablamos de flash lo suyo es meterlo a través de JS, y que debajo de él haya HTML con botones, etc... que te ofrezcan la misma funcionalidad.
Si hablamos de JS habrá que hacerlo todo de manera no intrusiva.
Por supuesto todo controlable mediante teclado, subtítulos en los vídeos, etc...
En general este punto merece análisis especial en cada proyecto, dependiendo de lo que se quiera meter hay que hacerlo de una manera u otra.
demssite
<fieldset><blockquote>10.2 Hasta que las aplicaciones de usuario soporten explícitamente la asociación entre control de formulario y etiqueta, para todos los controles de formularios con etiquetas asociadas implícitamente, asegúrese de que la etiqueta está colocada adecuadamente. [Prioridad 2]</blockquote></fieldset>
Asociación explícita de elementos de formulario:
<code>[label for="nombre"]Nombre[/label]
[input type="text" id="nombre" name="nombre" value="Nombre" /]</code>
Asociación explícita e implícita de elementos de formulario:
<code>[label for="nombre"]Nombre
[input type="text" id="nombre" name="nombre" value="Nombre"
[/label]</code>
¿Te das cuenta de la diferencia?. En la explicita vale con asociar el FOR con el ID del formulario (Ojo!! -> no vale NAME) en la implícita además hay que meter el INPUT dentro del LABEL.
demssite
<fieldset><blockquote>13.6 Agrupe los vínculos relacionados, identifique el grupo (para las aplicaciones de usuario) y, hasta que las aplicaciones de usuario lo hagan, proporcione una manera de evitar el grupo. [Prioridad 3] (Punto de revisión 13.6)</blockquote></fieldset>
Si los vínculos ya están agrupados (UL, OL, DL o lo que sea) con el JAWS ya pueden saltarse el grupo entero (es decir lo pueden evitar). Si aún así crees interesante utilizar un enlace para saltárselo también puedes (como el archiconocido enlace de "Ir al contenido" al comienzo de las páginas)
** He cambiado algunos < > por [ ] en las etiquetas para que el foro mostrara todo el código
big+
Cuando tengo alguna duda de como afontar algún tema "delicado" miro a ver como lo han solucionado en http://www.inditex.es/, uno de mis sitios accesibles de referencia.
Sinceramente, yo preferiría investigar en las especificaciones o preguntar en algún foro o lista de correo. No me fiaría demasiado de ninguna web para contrastar según qué cosas.
Pues ahora ya sabes por qué se desaconseja Flash... En la práctica la cosa se resumen en que hagas lo que hagas con Flash (o javascript) tengas una alternativa que haga lo mismo sin ambas tecnologías.
Si hablamos de flash lo suyo es meterlo a través de JS, y que debajo de él haya HTML con botones, etc... que te ofrezcan la misma funcionalidad.
Si hablamos de JS habrá que hacerlo todo de manera no intrusiva.
Por supuesto todo controlable mediante teclado, subtítulos en los vídeos, etc...
En general este punto merece análisis especial en cada proyecto, dependiendo de lo que se quiera meter hay que hacerlo de una manera u otra.
Si tengo que meter flash (que tengo que hacerlo), tengo que hacer lo mismo pero en html y ponerlo debajo ¿no?
Ya miraré a ver si veo algún ejemplo por ahi...
orange
¿Te das cuenta de la diferencia?. En la explicita vale con asociar el FOR con el ID del formulario (Ojo!! -> no vale NAME) en la implícita además hay que meter el INPUT dentro del LABEL.
Osea que de momento hasta que todos los navegadores lo reconozcan bien lo adecuado es hacerlo de la segunda forma (implícita y explícita) ¿es así no?
Borja muchas gracias me estás sirviendo de mucha ayuda.
En cuanto me baje por Madrid(ya no vivo allí) te pego un toque y te invito a unas cerves...
Si tengo que meter flash (que tengo que hacerlo), tengo que hacer lo mismo pero en html y ponerlo debajo ¿no?
Ya miraré a ver si veo algún ejemplo por ahi...
swfobject, ufo, flaccess ...
Si tengo que meter flash (que tengo que hacerlo), tengo que hacer lo mismo pero en html y ponerlo debajo ¿no?
Ya miraré a ver si veo algún ejemplo por ahi...
Sergi te ha puesto algunos ejemplos de SCRIPTs para incluir Flash por javascript. Yo utilizo su Flaccess que está muy bien.
Dependiendo de lo que haga el flash habrás de poner una cosa u otra debajo de él. Puede ser necesario dividirlo en partes.
demssite
Osea que de momento hasta que todos los navegadores lo reconozcan bien lo adecuado es hacerlo de la segunda forma (implícita y explícita) ¿es así no?
Olvídate de lo de "de momento" y emplea esa estructura siempre. No hace daño y acertarás "ad eternum"
;)
básicamente, estos scripts hacen lo siguiente, sustituyen el contenido de una capa HTML por un object/embed <em>si</em> el navegador soporta cierta version del flash, en caso contrario dejan el contenido como está. esto es cojonudo, porque la accesibilidad al contenido es 100%. por tanto, si vas a hacer un menú en flash, en el html yo pondria una lista de enlaces. cómo los muestres (CSS, desplegable, etc) es otro tema.
<blockquote>Osea que de momento hasta que todos los navegadores lo reconozcan bien lo adecuado es hacerlo de la segunda forma (implícita y explícita) ¿es así no?</blockquote>
</div>
Olvídate de lo de "de momento" y emplea esa estructura siempre. No hace daño y acertarás "ad eternum"
;)
ahi Borja y yo tenemos ciertas desavenencias, a mi me gusta más la implicita :)
<blockquote>Osea que de momento hasta que todos los navegadores lo reconozcan bien lo adecuado es hacerlo de la segunda forma (implícita y explícita) ¿es así no?</blockquote>
</div>
Olvídate de lo de "de momento" y emplea esa estructura siempre. No hace daño y acertarás "ad eternum"
;)</blockquote>
</div>ahi Borja y yo tenemos ciertas desavenencias, a mi me gusta más la implicita :)
La implícita que es sin el for y con el input dentro del label ¿no Sergi?
a mi lo que no me gusta es esto
[label for="nombre"][strong]Nombre[/strong]
[input type="text" id="nombre" name="nombre" value="Nombre" /][/label]
o
[label for="nombre"][span]Nombre[/span]
[input type="text" id="nombre" name="nombre" value="Nombre" /][/label]
pudiendo hacer esto otro:
[label for="nombre"]Nombre[/label]
[input type="text" id="nombre" name="nombre" value="Nombre" /]
:P
Esto es lo que utilizo yo. A mi modo de ver es la solución más semántica, práctica para maquetar por CSS y que cumple todos los puntos de accesibilidad.
Pero siempre caben opiniones. En esto de la accesibilidad te verás muchas veces caminando por el filo de la navaja.
Esto es lo que utilizo yo. A mi modo de ver es la solución más semántica, práctica para maquetar por CSS y que cumple todos los puntos de accesibilidad.
Es la más accesible, en eso estoy de acuerdo. Siempre es mejor meter el input dentro de su correspondiente label. Lo que no tengo tan claro es meter un 'strong', que significa 'más fuerte', 'más destacado', donde no es necesario dar 'más fuerza'. Si por cuestiones de la maquetación necesitamos marcado extra, yo casi prefiero el que no aporta contenido semántico al código: span.
Lo que no tengo tan claro es meter un 'strong', que significa 'más fuerte', 'más destacado', donde no es necesario dar 'más fuerza'. Si por cuestiones de la maquetación necesitamos marcado extra, yo casi prefiero el que no aporta contenido semántico al código: span.
Efectivamente es por cuestiones de maquetación. Yo prefiero "destacarlo" porque las etiquetas de un formulario me parecen palabras a destacar dentro de una página, pero pasan 2 cosas: que eso va a gustos y que nos la cogemos con papel de fumar
Hola gentes, tras unos días pegándome y no sin vuestra ayuda he logrado preparar el xhtml de una plantilla, pero antes de ponerme a saco con el css me molaría que le echaséis un ojo y me comentáseis.
Le he echado un vistazo muy por encima. Tiene muy buena pinta, pero hay algunas cosas sobre la estructura que no me parecen muy finas (o al menos no entiendo por qué son así).
¿Por qué 'Artículo 4' los marcas como un encabezado de tercer nivel (h3) y el resto de 'Artículo X' los marcas como párrafos?
A ver ahí reside mi duda. Están 2 artículos, en este caso el Ultimo Articulo y el Articulo Mejor Valorado que están destacados, luego dentro del Ultimo Articulo al pie de el salen Otros artículos recientes, y dentro de Articulo Mejor Valorado al pie salen Otros artículos valorados positivamente.
La cosa es que la importancia de estos dos ha de ser superior a la de los otros que son más antiguos en el primer caso o menos valorados en el segundo.
La cosa es que un h3 no se puede poner pòrque no tienen la misma importancia.
¿Quizá conmvendría poner un h4?
Otra duda que tengo es que bajo la cabecera y el menu principal, tengo una noticia destacadacon un banner y el cuadro de login que hacen un bloque, lo que llamo <Sub> porque no se me ocurre un nombre más semantico... o correcto, ¿cómo podría llamarse eso?
Una cosilla más, ahora que ya casi tengo el xhtml, a la hora de ponerse con el css, le estoy dando bastantes vueltas de como empezar. ¿Cómo soléis hacerlos vosotros?
Estoy empezando con la hoja de estilos y tras leer varias referencias y mirar por posts del foro he llegado a lo que creo es lo mejor para empezar, sobre todo en cuanto al tema de medidas relativas y fuentes. Os pongo el codigo:
He definido el texto por defecto x-small, es decir lo que equivale a 10px para que sea más cómodo hacer cuentas, pèro si la mayoría del texto del cuerpo es de 12 px sigue compensando ponerlo a x-small por defecto y poner en el del cuerpo a 1.2em, o por el contrario es mejor definir el el body el tamaño por defecto a small (12 px aprox)?
He definido el texto por defecto x-small, es decir lo que equivale a 10px para que sea más cómodo hacer cuentas, pèro si la mayoría del texto del cuerpo es de 12 px sigue compensando ponerlo a x-small por defecto y poner en el del cuerpo a 1.2em, o por el contrario es mejor definir el el body el tamaño por defecto a small (12 px aprox)?
Yo voto por ponerlo siempre como x-small. Facilita las cuentas, no sólo para tamaños tipográficos, sino también para poder utilizar medidas relativas en los tamaños de las 'cajas'.
Aunque si os soy sincero (y sé que me voy a ganar alguna crítica), cada vez estoy volviendo más a la teoría de utilizar pixels para definir todos los tamaños.... pero ya lo hablaremos, que hoy no estoy para discutir :)
demssite
Hola gentes, tras varias horas mirando leyendo y releyendo las pautas de accesibilidad, técnicas,... hay ciertos puntos que no acaban de quedarme del todo claros.
<fieldset>3.1 Cuando exista un marcador apropiado, use marcadores en vez de imágenes para transmitir la información.</fieldset>
En las técnicas css habla de before y :after y la propiedad "content , "cue", "cue-before", y "cue-after". y no acabo de entender mucho el sentido.
<fieldset>6.4 Para los scripts y applets, asegúrese de que los manejadores de evento sean independientes del dispositivo de entrada.Técnicas HTML: Applets directamente accesibles à Si un applet (creado con OBJECT o con APPLET) precisa una interacción con el usuario (por ejemplo, la capacidad de manipular un experimento físico) que no se puede reproducir en un formato alternativo, se debe hacer el applet accesible directamente.
Si un applet causa movimiento, el diseñador debe proporcionar un mecanismo para parar este movimiento (por ejemplo, véase [TRACE]). También, consúltese el apartado siguiente para aprender cómo hacer accesibles las presentaciones de audio y vídeo.</fieldset>
<fieldset>Pauta 7. Asegure al usuario el control sobre los cambios de contenidos tempo-sensibles.</fieldset> ¿Y los gif animados/flash?
<fieldset>10.2 Hasta que las aplicaciones de usuario soporten explícitamente la asociación entre control de formulario y etiqueta, para todos los controles de formularios con etiquetas asociadas implícitamente, asegúrese de que la etiqueta está colocada adecuadamente. [Prioridad 2]</fieldset>
<fieldset>13.6 Agrupe los vínculos relacionados, identifique el grupo (para las aplicaciones de usuario) y, hasta que las aplicaciones de usuario lo hagan, proporcione una manera de evitar el grupo. [Prioridad 3] (Punto de revisión 13.6)</fieldset>
Gracias gentes y un saludo
scuain
Cuando tengo alguna duda de como afontar algún tema "delicado" miro a ver como lo han solucionado en http://www.inditex.es/, uno de mis sitios accesibles de referencia.
orange
demssite
<fieldset><blockquote>3.1 Cuando exista un marcador apropiado, use marcadores en vez de imágenes para transmitir la información.</blockquote></fieldset>
En las técnicas css habla de before y :after y la propiedad "content , "cue", "cue-before", y "cue-after". y no acabo de entender mucho el sentido.
No te líes, este es sencillo (al menos las cosas más comunes luego hay cosas raras que hay que estudiar), te dice por ejemplo que NO metas imágenes para meter textos, cosa que se da de frente con todas las tipos personalizadas metidas hasta ahora como imágenes (menús, titulares...) por eso es interesante utilizar reemplazo de imágenes, al menos guarda la semántica y es sencillo de cambiar si por casualidad te lo tiran para atrás en una auditoría.
También te dice que si metes una ecuación u otra cosa para la que existen lenguajes particulares (MathML o similares) trates de utilizar los marcadores en lugar de una imagen.
demssite
<fieldset><blockquote>6.4 Para los scripts y applets, asegúrese de que los manejadores de evento sean independientes del dispositivo de entrada.Técnicas HTML: Applets directamente accesibles à Si un applet (creado con OBJECT o con APPLET) precisa una interacción con el usuario (por ejemplo, la capacidad de manipular un experimento físico) que no se puede reproducir en un formato alternativo, se debe hacer el applet accesible directamente.
Si un applet causa movimiento, el diseñador debe proporcionar un mecanismo para parar este movimiento (por ejemplo, véase [TRACE]). También, consúltese el apartado siguiente para aprender cómo hacer accesibles las presentaciones de audio y vídeo.</blockquote></fieldset>
<fieldset><blockquote>Pauta 7. Asegure al usuario el control sobre los cambios de contenidos tempo-sensibles.</blockquote></fieldset> ¿Y los gif animados/flash?
Pues ahora ya sabes por qué se desaconseja Flash... En la práctica la cosa se resumen en que hagas lo que hagas con Flash (o javascript) tengas una alternativa que haga lo mismo sin ambas tecnologías.
Si hablamos de flash lo suyo es meterlo a través de JS, y que debajo de él haya HTML con botones, etc... que te ofrezcan la misma funcionalidad.
Si hablamos de JS habrá que hacerlo todo de manera no intrusiva.
Por supuesto todo controlable mediante teclado, subtítulos en los vídeos, etc...
En general este punto merece análisis especial en cada proyecto, dependiendo de lo que se quiera meter hay que hacerlo de una manera u otra.
demssite
<fieldset><blockquote>10.2 Hasta que las aplicaciones de usuario soporten explícitamente la asociación entre control de formulario y etiqueta, para todos los controles de formularios con etiquetas asociadas implícitamente, asegúrese de que la etiqueta está colocada adecuadamente. [Prioridad 2]</blockquote></fieldset>
Asociación explícita de elementos de formulario:
<code>[label for="nombre"]Nombre[/label]
[input type="text" id="nombre" name="nombre" value="Nombre" /]</code>
Asociación explícita e implícita de elementos de formulario:
<code>[label for="nombre"]Nombre
[input type="text" id="nombre" name="nombre" value="Nombre"
[/label]</code>
¿Te das cuenta de la diferencia?. En la explicita vale con asociar el FOR con el ID del formulario (Ojo!! -> no vale NAME) en la implícita además hay que meter el INPUT dentro del LABEL.
demssite
<fieldset><blockquote>13.6 Agrupe los vínculos relacionados, identifique el grupo (para las aplicaciones de usuario) y, hasta que las aplicaciones de usuario lo hagan, proporcione una manera de evitar el grupo. [Prioridad 3] (Punto de revisión 13.6)</blockquote></fieldset>
Vínculos relacionados pero NO agrupados:
<code>[div id="menu"]
<a href="loquesea">Opcion</a> <a href="loquesea">Opcion</a> <a href="loquesea">Opcion</a>
[/div]</code>
Vínculos relacionados Y agrupados:
<code>[ul id="menu"]
<li><a href="loquesea">Opcion</a></li>
<li><a href="loquesea">Opcion</a></li>
<li><a href="loquesea">Opcion</a></li>
[/ul]</code>
Si los vínculos ya están agrupados (UL, OL, DL o lo que sea) con el JAWS ya pueden saltarse el grupo entero (es decir lo pueden evitar). Si aún así crees interesante utilizar un enlace para saltárselo también puedes (como el archiconocido enlace de "Ir al contenido" al comienzo de las páginas)
** He cambiado algunos < > por [ ] en las etiquetas para que el foro mostrara todo el código
big+
Cuando tengo alguna duda de como afontar algún tema "delicado" miro a ver como lo han solucionado en http://www.inditex.es/, uno de mis sitios accesibles de referencia.
Sinceramente, yo preferiría investigar en las especificaciones o preguntar en algún foro o lista de correo. No me fiaría demasiado de ninguna web para contrastar según qué cosas.
demssite
orange
Pues ahora ya sabes por qué se desaconseja Flash... En la práctica la cosa se resumen en que hagas lo que hagas con Flash (o javascript) tengas una alternativa que haga lo mismo sin ambas tecnologías.
Si hablamos de flash lo suyo es meterlo a través de JS, y que debajo de él haya HTML con botones, etc... que te ofrezcan la misma funcionalidad.
Si hablamos de JS habrá que hacerlo todo de manera no intrusiva.
Por supuesto todo controlable mediante teclado, subtítulos en los vídeos, etc...
En general este punto merece análisis especial en cada proyecto, dependiendo de lo que se quiera meter hay que hacerlo de una manera u otra.
Si tengo que meter flash (que tengo que hacerlo), tengo que hacer lo mismo pero en html y ponerlo debajo ¿no?
Ya miraré a ver si veo algún ejemplo por ahi...
orange
¿Te das cuenta de la diferencia?. En la explicita vale con asociar el FOR con el ID del formulario (Ojo!! -> no vale NAME) en la implícita además hay que meter el INPUT dentro del LABEL.
Osea que de momento hasta que todos los navegadores lo reconozcan bien lo adecuado es hacerlo de la segunda forma (implícita y explícita) ¿es así no?
Borja muchas gracias me estás sirviendo de mucha ayuda.
En cuanto me baje por Madrid(ya no vivo allí) te pego un toque y te invito a unas cerves...
Un saludo.
Diego
zigotica
demssite
Si tengo que meter flash (que tengo que hacerlo), tengo que hacer lo mismo pero en html y ponerlo debajo ¿no?
Ya miraré a ver si veo algún ejemplo por ahi...
swfobject, ufo, flaccess ...
orange
demssite
Si tengo que meter flash (que tengo que hacerlo), tengo que hacer lo mismo pero en html y ponerlo debajo ¿no?
Ya miraré a ver si veo algún ejemplo por ahi...
Sergi te ha puesto algunos ejemplos de SCRIPTs para incluir Flash por javascript. Yo utilizo su Flaccess que está muy bien.
Dependiendo de lo que haga el flash habrás de poner una cosa u otra debajo de él. Puede ser necesario dividirlo en partes.
demssite
Osea que de momento hasta que todos los navegadores lo reconozcan bien lo adecuado es hacerlo de la segunda forma (implícita y explícita) ¿es así no?
Olvídate de lo de "de momento" y emplea esa estructura siempre. No hace daño y acertarás "ad eternum"
;)
zigotica
básicamente, estos scripts hacen lo siguiente, sustituyen el contenido de una capa HTML por un object/embed <em>si</em> el navegador soporta cierta version del flash, en caso contrario dejan el contenido como está. esto es cojonudo, porque la accesibilidad al contenido es 100%. por tanto, si vas a hacer un menú en flash, en el html yo pondria una lista de enlaces. cómo los muestres (CSS, desplegable, etc) es otro tema.
zigotica
orange
<div class="quote">
demssite
<blockquote>Osea que de momento hasta que todos los navegadores lo reconozcan bien lo adecuado es hacerlo de la segunda forma (implícita y explícita) ¿es así no?</blockquote>
</div>
Olvídate de lo de "de momento" y emplea esa estructura siempre. No hace daño y acertarás "ad eternum"
;)
ahi Borja y yo tenemos ciertas desavenencias, a mi me gusta más la implicita :)
demssite
zigotica
<div class="quote">
orange
<blockquote>
<div class="quote">
demssite
<blockquote>Osea que de momento hasta que todos los navegadores lo reconozcan bien lo adecuado es hacerlo de la segunda forma (implícita y explícita) ¿es así no?</blockquote>
</div>
Olvídate de lo de "de momento" y emplea esa estructura siempre. No hace daño y acertarás "ad eternum"
;)</blockquote>
</div>ahi Borja y yo tenemos ciertas desavenencias, a mi me gusta más la implicita :)
La implícita que es sin el for y con el input dentro del label ¿no Sergi?
zigotica
demssite
La implícita que es sin el for y con el input dentro del label ¿no Sergi?
esta:
[label for="nombre"]Nombre[/label]
[input type="text" id="nombre" name="nombre" value="Nombre" /]
PD: que hioputa el foro, con las tags... (cambia el [ y tal por menor que...)
orange
A Sergi le gusta la explícita, pero yo digo que utilizar la implícita nos aporta ventajas de accesibilidad y no cuesta nada
:x
zigotica
a mi lo que no me gusta es esto
[label for="nombre"][strong]Nombre[/strong]
[input type="text" id="nombre" name="nombre" value="Nombre" /][/label]
o
[label for="nombre"][span]Nombre[/span]
[input type="text" id="nombre" name="nombre" value="Nombre" /][/label]
pudiendo hacer esto otro:
[label for="nombre"]Nombre[/label]
[input type="text" id="nombre" name="nombre" value="Nombre" /]
:P
orange
jajaja
zigotica
[label for="nombre"][strong]Nombre[/strong]
[input type="text" id="nombre" name="nombre" value="Nombre" /][/label]
Esto es lo que utilizo yo. A mi modo de ver es la solución más semántica, práctica para maquetar por CSS y que cumple todos los puntos de accesibilidad.
Pero siempre caben opiniones. En esto de la accesibilidad te verás muchas veces caminando por el filo de la navaja.
txuma
orange
jajaja
<div class="quote">
zigotica
<blockquote>[label for="nombre"][strong]Nombre[/strong]
[input type="text" id="nombre" name="nombre" value="Nombre" /][/label]</blockquote>
</div>
Esto es lo que utilizo yo. A mi modo de ver es la solución más semántica, práctica para maquetar por CSS y que cumple todos los puntos de accesibilidad.
Es la más accesible, en eso estoy de acuerdo. Siempre es mejor meter el input dentro de su correspondiente label. Lo que no tengo tan claro es meter un 'strong', que significa 'más fuerte', 'más destacado', donde no es necesario dar 'más fuerza'. Si por cuestiones de la maquetación necesitamos marcado extra, yo casi prefiero el que no aporta contenido semántico al código: span.
orange
txuma
Lo que no tengo tan claro es meter un 'strong', que significa 'más fuerte', 'más destacado', donde no es necesario dar 'más fuerza'. Si por cuestiones de la maquetación necesitamos marcado extra, yo casi prefiero el que no aporta contenido semántico al código: span.
Efectivamente es por cuestiones de maquetación. Yo prefiero "destacarlo" porque las etiquetas de un formulario me parecen palabras a destacar dentro de una página, pero pasan 2 cosas: que eso va a gustos y que nos la cogemos con papel de fumar
XD
txuma
orange
... y que nos la cogemos con papel de fumar
En eso sí que estoy de acuerdo al 100% xD
zigotica
txuma
<div class="quote">
orange
<blockquote>... y que nos la cogemos con papel de fumar</blockquote>
</div>
En eso sí que estoy de acuerdo al 100% xD
jaja, y yo también :P
demssite
Hola gentes, tras unos días pegándome y no sin vuestra ayuda he logrado preparar el xhtml de una plantilla, pero antes de ponerme a saco con el css me molaría que le echaséis un ojo y me comentáseis.
Aquí os dejo el enlace:
Enlace a xhtml
Ahh, debido a temas de confidencialidad he sustituido algun texto.
Un saludo y gracias de antemano.
Diego
txuma
Le he echado un vistazo muy por encima. Tiene muy buena pinta, pero hay algunas cosas sobre la estructura que no me parecen muy finas (o al menos no entiendo por qué son así).
¿Por qué 'Artículo 4' los marcas como un encabezado de tercer nivel (h3) y el resto de 'Artículo X' los marcas como párrafos?
demssite
A ver ahí reside mi duda. Están 2 artículos, en este caso el Ultimo Articulo y el Articulo Mejor Valorado que están destacados, luego dentro del Ultimo Articulo al pie de el salen Otros artículos recientes, y dentro de Articulo Mejor Valorado al pie salen Otros artículos valorados positivamente.
La cosa es que la importancia de estos dos ha de ser superior a la de los otros que son más antiguos en el primer caso o menos valorados en el segundo.
La cosa es que un h3 no se puede poner pòrque no tienen la misma importancia.
¿Quizá conmvendría poner un h4?
Otra duda que tengo es que bajo la cabecera y el menu principal, tengo una noticia destacadacon un banner y el cuadro de login que hacen un bloque, lo que llamo <Sub> porque no se me ocurre un nombre más semantico... o correcto, ¿cómo podría llamarse eso?
Gracias gentes
Un saludo.
Diego
demssite
Una cosilla más, ahora que ya casi tengo el xhtml, a la hora de ponerse con el css, le estoy dando bastantes vueltas de como empezar. ¿Cómo soléis hacerlos vosotros?
Un saludo y gracias!!!!
Diego
demssite
Estoy empezando con la hoja de estilos y tras leer varias referencias y mirar por posts del foro he llegado a lo que creo es lo mejor para empezar, sobre todo en cuanto al tema de medidas relativas y fuentes. Os pongo el codigo:
<code>/* ESTILOS GENERALES */
* { margin: 0; padding: 0; }
body {
font-size: x-small; /* 1EM=10px */
font-family: Arial, Verdana, Helvetica, sans-serif;
color: #333333;
}
h1 {
font-size: 4em;
color: #d71c1a;
}
h2 {
font-size: 3em;
color: #000099;
}
h3 {
font-size: 1.4em;
font-weight: bold;
color: #000099;
}
h4 {
font-size: 1.2em;
font-weight: bold;
color: #000099;
}
</code>
He definido el texto por defecto x-small, es decir lo que equivale a 10px para que sea más cómodo hacer cuentas, pèro si la mayoría del texto del cuerpo es de 12 px sigue compensando ponerlo a x-small por defecto y poner en el del cuerpo a 1.2em, o por el contrario es mejor definir el el body el tamaño por defecto a small (12 px aprox)?
Un saludo y muchas gracias.
Diego
txuma
demssite
He definido el texto por defecto x-small, es decir lo que equivale a 10px para que sea más cómodo hacer cuentas, pèro si la mayoría del texto del cuerpo es de 12 px sigue compensando ponerlo a x-small por defecto y poner en el del cuerpo a 1.2em, o por el contrario es mejor definir el el body el tamaño por defecto a small (12 px aprox)?
Yo voto por ponerlo siempre como x-small. Facilita las cuentas, no sólo para tamaños tipográficos, sino también para poder utilizar medidas relativas en los tamaños de las 'cajas'.
Aunque si os soy sincero (y sé que me voy a ganar alguna crítica), cada vez estoy volviendo más a la teoría de utilizar pixels para definir todos los tamaños.... pero ya lo hablaremos, que hoy no estoy para discutir :)
zigotica
uy como te oiga el naranjo... :)
txuma
Sé de buena tinta que hoy esta ocupado, así que lo mismo se le pasa por alto mi comentario :P