Revisando uno de los mejores blogs canarios que conozco, el de José Ramón Quevedo Santana, echo un vistazo a los resúmenes de las ponencias celebradas en el pasado Fundamentos Web 2005, en una de las cuales se presentaban los mitos actuales en torno a la accesibilidad. Con permiso de José Ramón (y de Shawn Lawton Henry, la ponente en cuestión), voy a exponerlos aquí:
Las versiones "sólo texto" son suficientes para garantizar la accesibilidad.
Falso. No son suficientes ni válidas para todos los usuarios con discapacidad, no son tan ricas y, generalmente, no se encuentran igual de actualizadas que las páginas con "contenido visual".
La accesibilidad es sólo para deficientes visuales.
Falso. Es para todos, hay muchos tipos de discapacidades e, incluso, podemos, sin ser discapacitados, actuar temporalmente como tales.
La accesibilidad implica tener que hacer diseños aburridos y restrictivos.
Falso. Hay muchos ejemplos que demuestran lo contrario, normalmente este problema se debe al desconocimiento de los desarrolladores de las herramientas y posibilidades que tienen a su alcance.
La accesibilidad es cara.
Falso (en parte). No debiera ser más cara que cualquier otro desarrollo Web, lo que si está demostrado es que desarrollar teniendo la accesibilidad en mente desde el principio de los proyectos ayuda a que su aplicación sea mucho menos costosa.
La accesibilidad es compleja y difícil.
Falso (en parte). Comprender la accesibilidad Web puede ser complicado, pero no más que cualquier otra disciplina implicada en el desarrollo Web.
Fundamentos Web | qweos | w3c | Shawn Lawton Henry | accesibilidad
servido por tresonce
1 comentario
compártelo
HTML bien formado simplemente significa HTML conforme a las reglas de XML.
La industria se mueve hacia los documentos bien formados como una vía de incrementar la robustez de la www, mientras simplifica y acelera el procesamiento de los datos y documentos bien formados. Los documentos bien-formados tienen grandes ventajas para las herramientas y pueden beneficiar a sus autores asegurando que el marcado no es ambiguo. Las expectativas de la industria son que el futuro del HTML estándar serán aplicaciones XML.
El precio a pagar por estos beneficios es que se tendrá que usar una sintáxis menos indulgente.
Escribir HTML bien formado es simple. A continuación, algunas reglas básicas a seguir para crear o convertir HTML en documentos de calidad.
Todas las etiquetas deben cerrarse.
HTML permite que ciertos finales de etiquetas sean opcionales, como son <p>, <li>, <tr> y <td>. XML requiere que todas las etiquetas sean cerradas de forma explícita.
Algunas etiquetas deben ser cerradas colocando una barra dentro de la propia etiqueta. Los ejemplos más comúnes son <br>, <hr>, <input> o <img>.
La intercalación de etiquetas no está permitida.
XML no permite que etiquetas de inicio y fin se solapen, ya que hace incluir una estricta estructura jerárquica dentro del documento.
Las mayúsculas importan.
Use las mayúsculas/minúsculas de forma coherente para el inicio y fin de las etiquetas. Los ejemplos normalmente usan mayúsculas para los elementos HTML.
Ojo. Según XML y XHTML no se pueden usar mayúsculas, pero bueno, esto es HTML.
Es obligatorio entrecomillar los atributos.
Todos los atributos deben estar enmarcados por comillas, ya sean simples o dobles.
Utilice una sola raíz.
Los atajos que eliminan el elemento <HTML> como el elemento raíz del documento no están permitidos.
Pocas entidades incorporadas.
XML sólo define un mínimo conjunto de entidades de caracteres incorporados.
Aún así, las entidades de caracteres numéricós están soportados.
Utilice caracteres de escape para los comandos de script.
Los bloques de script en HTML pueden contener caracteres no interpretables, como < y &. Estos deben ser escapados en HTML bien-formado usando entidades de caracter, o enmarcándolos dentro de un bloque de script en una sección CDATA.
El siguiente bloque de script HTML contiene ambos caracteres no interpretables y un comentario en JScript. El bloque bien formado usa CDATA para encapsular el script.
No todos los scripts fallarán si no son "escapados" de esta manera. Sin embarque, es altamente recomendable que se tome esta manera de proceder como un hábito. Así se asegurará de que, no sólo el script trabajará trabajará si contiene los caracteres de escape o comentarios ahora, sino que continuarán funcionando si esos caracteres son añadidos en el futuro.
html | xml | reglas | well formed
servido por tresonce
sin comentarios
compártelo
Leo en barrapunto que el navegador Safari de apple ha conseguido pasar el Acid2 Test, el cual debo reconocer que desconocía hasta la fecha.
Pues bien, resulta que se trata de una prueba (bastante dura por lo que parece, ya que esta versión del Safari es el primer navegador no-beta que lo pasa, aunque el Opera está cerca) que evalúa el nivel de accesibilidad de los diferentes navegadores.
Como curiosidad, podemos ver el resultado del test en el/los navegador/es que tengamos instalados en nuestro equipo y ver cómo reaccionan.
safari | test | acid2 | navegadores
servido por tresonce
sin comentarios
compártelo
Tres Once pretende contener mis reflexiones, opiniones y puntos de vista acerca de la usabilidad web en Canarias, sobre todo en páginas web creadas en las islas.
Aunque el tema central sea ese, habrá días en los que me permitiré alguna licencia para tratar sobre cualquier otra cosa, como una de mis grandes aficiones, la fotografía, que pa' eso el blog es mío. ;)
