No nos damos cuenta pero la accesibilidad tiene un amplió mercado, vamos siempre detras de los avances y hasta que no demos un paso adelante siempre seremos del furgon de cola, este es un video de promoción del evento CES 2017 en el se tratará sobre el coche autónomo. Pues las grandes empresas se han percatado de que el numero de personas con algún tipo de discapacidad esta creciendo y es un mercado cada vez más grande.
viernes, 30 de diciembre de 2016
Cómo crear formularios accesibles
Los formularios son una de las partes más atractivas de su sitio web. Se utilizan para la recopilación de datos e interactuar directamente con tu visitante. Lo más practico de ellos, es que permiten que tu sitio es que puede comercio electrónico. Naturalmente lo que se desea es que esté se pueda rellenar por tantos usuarios como sea posible, y así no excluir a ningún grupo particular de usuarios tengan acceso a estas áreas de generación de ingresos de su sitio web.
HTML 5 está bien para la accesibilidad y, de hecho, los lectores de pantalla están preparados para los nuevos elementos. Vamos a repasar los puntos de partida básicos para cualquier estructura formulario.
<Label for = "nombre"> Nombre </ label>
<Input id = "nombre">
es muy accesible, siempre y cuando se respete que la etiqueta "for" se vincula con el atributo "id" de la entrada.
Suele ocurrir que en el desarrollo se elimina el input y usan placeholder esto no es aconsejable pues placeholder tiene un contraste muy liviano otra desventaja es que los lectores de pantalla no leerán su contenido.
<input id="nombre" aria-label="Introduce tu nombre">
<label for = "fecha"> Fecha </ label>
<input id = "fecha" /> <span> (año / mes / día) </ span>
El ejemplo anterior arroja luz sobre uno de los problemas de los formularios y la accesibilidad
Muchos de estos usuarios emplean el teclado como el único medio para desplazarse por sitios Web. Esto se hace usando las teclas de tabulación, abajo, arriba y las teclas de flecha para leer a través de su contenido. Las teclas de flecha con bastante usadas pues permiten al usuario acceder a todo el contenido con el teclado. Cuando se trata de formularios, las teclas de flecha no bastan, ya que no puede desplazarse dentro de una entrada de texto, área de texto, o una lista, y por lo tanto el usuario se puede quedar atrapado.
Para ayudar se use ARIA exactamente ARIA-LABEL.
<label for="date">Date</label>
<input id="date" aria-label="Introduce tu año, mes y dia"><span>(año/mes/dia)</span>
Cómo hemos dicho anteriormente muchos usuarios rellenan los formularios con el teclado por eso es recomendable usar un orden lógico de tabulación, para ello usa la etiqueta tabindex, tén en cuenta que si pones tabindex = "0" al comienzo dejaras el orden de tabulación sin un orden.
asegúrese de que todas las instrucciones se colocan por delante de donde más se necesitan.:
<form>
...
<div tabindex = "0"> Rellene el formulario </ div>
<input type = "submit" value = "Enviar formulario">
...
</ form>
Los mensajes de error se debe realizar en tiempo real, antes que los usuarios completen el formulario. Es decir, no se debe basar en la espera de que el usuario envía el formulario, sino que el usuario debe ser informado inmediatamente si cometió un error. Este mensaje debe hacerse de tal manera que un lector de pantalla pueda recoger el error. Esto se puede lograr por tener un div de error designado que tiene el atributo "aria-live" y que se actualiza a través de JavaScript:
<Div id = "mensaje_error" aria-live = "polite"> Su mensaje de error aquí </ div>
Típicamente, estos elementos deben tener disabled="true" incluido en sus atributos. Es bastante común que los formularios utilicen un sistema pasivo para asegurar que todos los campos requeridos se han completado correctamente. El botón de envío permanecerá desactivado hasta que el usuario complete todos los campos obligatorios. Este tipo de interfaz es muy probable que pierda a los usuarios que dependen de los lectores de pantalla, o los usuarios que tienen problemas para distinguir el color.
HTML 5 está bien para la accesibilidad y, de hecho, los lectores de pantalla están preparados para los nuevos elementos. Vamos a repasar los puntos de partida básicos para cualquier estructura formulario.
Etiquetas
Cada entrada o grupo de entradas en el formulario deben tener su etiqueta.<Label for = "nombre"> Nombre </ label>
<Input id = "nombre">
es muy accesible, siempre y cuando se respete que la etiqueta "for" se vincula con el atributo "id" de la entrada.
Suele ocurrir que en el desarrollo se elimina el input y usan placeholder esto no es aconsejable pues placeholder tiene un contraste muy liviano otra desventaja es que los lectores de pantalla no leerán su contenido.
<input id="nombre" aria-label="Introduce tu nombre">
Instrucciones
Es común que un sitio web para incluir instrucciones de entrada para un campo. Por ejemplo, un campo de fecha puede tener ayuda de formato:<label for = "fecha"> Fecha </ label>
<input id = "fecha" /> <span> (año / mes / día) </ span>
El ejemplo anterior arroja luz sobre uno de los problemas de los formularios y la accesibilidad
Muchos de estos usuarios emplean el teclado como el único medio para desplazarse por sitios Web. Esto se hace usando las teclas de tabulación, abajo, arriba y las teclas de flecha para leer a través de su contenido. Las teclas de flecha con bastante usadas pues permiten al usuario acceder a todo el contenido con el teclado. Cuando se trata de formularios, las teclas de flecha no bastan, ya que no puede desplazarse dentro de una entrada de texto, área de texto, o una lista, y por lo tanto el usuario se puede quedar atrapado.
Para ayudar se use ARIA exactamente ARIA-LABEL.
<label for="date">Date</label>
<input id="date" aria-label="Introduce tu año, mes y dia"><span>(año/mes/dia)</span>
Cómo hemos dicho anteriormente muchos usuarios rellenan los formularios con el teclado por eso es recomendable usar un orden lógico de tabulación, para ello usa la etiqueta tabindex, tén en cuenta que si pones tabindex = "0" al comienzo dejaras el orden de tabulación sin un orden.
asegúrese de que todas las instrucciones se colocan por delante de donde más se necesitan.:
<form>
...
<div tabindex = "0"> Rellene el formulario </ div>
<input type = "submit" value = "Enviar formulario">
...
</ form>
Mensajes de error
Los mensajes de error se debe realizar en tiempo real, antes que los usuarios completen el formulario. Es decir, no se debe basar en la espera de que el usuario envía el formulario, sino que el usuario debe ser informado inmediatamente si cometió un error. Este mensaje debe hacerse de tal manera que un lector de pantalla pueda recoger el error. Esto se puede lograr por tener un div de error designado que tiene el atributo "aria-live" y que se actualiza a través de JavaScript:
<Div id = "mensaje_error" aria-live = "polite"> Su mensaje de error aquí </ div>
Elementos deshabilitados
Típicamente, estos elementos deben tener disabled="true" incluido en sus atributos. Es bastante común que los formularios utilicen un sistema pasivo para asegurar que todos los campos requeridos se han completado correctamente. El botón de envío permanecerá desactivado hasta que el usuario complete todos los campos obligatorios. Este tipo de interfaz es muy probable que pierda a los usuarios que dependen de los lectores de pantalla, o los usuarios que tienen problemas para distinguir el color.
jueves, 29 de diciembre de 2016
Aplicación para conocer el aire de Madrid
Yo cómo madrileño y ciudadano de Madrid apruebo la medida de restringir la circulación a vehiculos con matricula par pero no puedo aprobar la aplicación que tiene el ayuntamiento para conocer el estado de la contaminación.
Cómo yo digo la accesibilidad web es pensar en los demás, yo no tengo discapacidad visual grave pero otra persona si y si necesita conocer o tiene curiosidad por conocer el estado del aire en Madrid, el escuchar enlace aquí se puede preguntar ¿aquí?, ya sé que la asignatura de usabilidad y accesibilidad es un Maria en la carrera pero existe gente que precisa la accesibilidad.
Suscribirse a:
Entradas (Atom)