29/11/2008, 17:41
|
| Colaborador | | Fecha de Ingreso: octubre-2006 Ubicación: K-pax
Mensajes: 7.228
Antigüedad: 18 años, 1 mes Puntos: 280 | |
Respuesta: Votaciones Duelo Aresillo vs. CaLiZzZ Bueno, lo cierto es que ya se han dicho muchas de las cosas que podría decir en mi análisis, que he dejado para el final para como árbitro, no influir en las votaciones.
Procuraré no ser muy redundante, aunque habrá alguna cosa repetida.
Comienzo con unas cuantas cosas para los dos, porque se repiten en ambos trabajos:
- Los accesskey, aunque vienen muy bien para superar la validación de accesibilidad, no tienen ninguna utilidad si no se informa de alguna manera de su existencia. De la misma manera, hay que tener cuidado al elegir las teclas, porque muchas podrían coincidir con comandos del propio navegador y por tanto quedarían anuladas. Es preferible usar los números de 0 al 9 (como sí ha hecho CaLiZzZ).
- Con los headers, debemos pensar como la estructura de un libro:
título del libro: h1
capítulos: h2
secciones: h3
subsecciones: h4, etc.
Nunca pondrías una subsección sin estar dentro de un capítulo (en un libro no tiene sentido). Debemos procurar mantener ese concepto de anidamiento y jerarquía (anidamiento no de etiquetas, pero sí de concepto, supongo que se entiende).
- Debemos usar los elementos de párrafo para separarlos, pero en las nuevas líneas sin ser punto y aparte no creo que haya ningún problema en usar el <br/> (como justo acabo de ver que ha aclarado alvlin).
- Generalmente usando el charset ISO-8859-1 y guardando el archivo como ANSI no necesitamos usar las entidades html, pudiendo poner tildes o eñes sin problema.
- Efectivamente como se ha dicho, si usamos el concepto de anidamiento nos podemos ahorrar muchas clases, porque poner la misma clase a todos los span dentro de p dentro de un div concreto, se soluciona mucho más fácil con algo como #imgblog p span {...}, en e caso de Aresillo, o #kers div {...} y #kers p {...} en el de CaLiZzZ.
- Me parece correcta la estructura del flujo de que primero salga el menú, después el contenido y luego los accesorios.
- Debería proporcionarse una manera de saltarse el menú e ir al contenido (con un enlace interno). Se pone un primer elemento del menú que dice "saltar menú" o "saltar al contenido", que a veces se oculta (aunque no es muy buena práctica), en el que se pone un enlace interno (href="#id"), al ID del bloque principal del contenido. Así, en un navegador de texto o en la navegación con teclado podemos saltar todo el menú de golpe e ir al contenido.
- En general hay que recordar que los analizadores automáticos de accesibilidad no pueden examinarlo todo, y hay que pensar en la accesibilidad con medidas proactivas, como lo que he comentado de los accesskey, que el texto conserve su legibilidad al aumentar o disminuir el tamaño o que las imágenes importantes sean reemplazadas por texto alternativo. La imagen principal, al ser un fondo desaparece sin dejar rastro al desactivar las imágenes o la css (en ambos trabajos).
- También es importante recordar que hay gente que navega sin ratón, por lo que es bueno que el mismo efecto que le damos a hover se lo demos a active y focus, de manera que siempre se vea claramente dónde estamos.
En conclusión, aun con cosas a mejorar, el código es diez veces más limpio que muchos trabajos profesionales. Me encanta que muchos estemos ya pensando en todas estas cuestiones a la hora de diseñar como algo importante; se nota un cambio radical.
Para mi que estos dos trabajos no están nada lejos de lo que en teoría sabemos algo más de xhtml y css; me parecen estupendos.
A continuación algunas puntualizaciones de cada trabajo. |