Buscador

lunes, 29 de agosto de 2016

Sitio web con características accesibles

El sitio web Trace Research and Development Center ofrece algunas características para mejorar la accesibilidad de la página web.


Permite seleccionar un estilo de alto contraste:


Cuando se selecciona el estilo de alto contraste además aparece un enlace de "skip to main content".

Y también permite modificar el tamaño del texto:



viernes, 26 de agosto de 2016

Cambio de idioma en un lector de pantallas

El atributo lang se debe emplear para indicar el idioma principal de una página y los cambios de idioma que se produzcan. Esta técnica está explicada en el principio 3 comprensible de WCAG 2.0:

Guideline 3.1 Readable: Make text content readable and understandable.

3.1.1 Language of Page: The default human language of each Web page can be programmatically determined. (Level A)

3.1.2 Language of Parts: The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. (Level AA)

Como no todos los desarrolladores cumplen lo anterior, algunos navegadores de pantalla pueden aplicar técnicas para detectar los cambios de idioma. En el siguiente vídeo se muestra el comportamiento de SuperNova:

miércoles, 24 de agosto de 2016

Las 10 de reglas de oro para el diseño web accesible (según la Comisión Europea)

En 10 golden rules in accessible Web design encontramos:


  1. Provide text alternatives
    1. Non-text content (images, audio and video…)
    2. Equivalent purpose
    3. Multiple ways of providing alternatives
    4. CAPTCHA needs accessible alternatives
    5. Decorative content
    6. Images of text
  2. Structure contents
    1. Headings
    2. Lists
    3. Data tables
    4. Markup vs. style sheets
    5. Resize text
    6. Bypass blocks
  3. Avoid dependence on a single sense
    1. Captions and audio descriptions
    2. Use of colour
    3. Sensory characteristics
    4. Contrast
    5. Background audio
  4. Make all functionalities keyboard accessible
    1. Keyboard access
    2. No keyboard trap
    3. Focus order and visibility
    4. Unexpected behaviour
    5. Drop down menus, accordions, carousels…
  5. Give users enough time
    1. Timing adjustable
    2. Automatic redirections
    3. Long processes
    4. Banners
  6. Avoid interferences
    1. Seizures and flashes
    2. Audio control
    3. Blinking, moving, auto-updating
    4. Opening new windows
    5. Unexpected behaviour
  7. Identify hyperlinks and contents
    1. Link purpose
    2. Page titles
    3. Language of page and parts
    4. Form labels
    5. Section headings
    6. Opening new windows
  8. Make navigation interfaces consistent
    1. Consistent navigation
    2. Consistent identification
    3. Multiple ways
    4. Information architecture
  9. Help users avoid mistakes
    1. Labels and instructions
    2. Error identification
    3. Error suggestion
    4. Error prevention
    5. Good information architecture
  10. Ensure compatibility
    1. Web standards and code validation
    2. Accessible use of technologies
    3. User tests
    4. JavaScript, PDF and Flash
    5. WAI-ARIA: Accessible Rich Internet Applications

martes, 23 de agosto de 2016

Sitio web con vídeos con lengua de signos (o de señas)

Curioso el sitio web los Testigos de Jehová. Dispone de 835 idiomas:


Entre los idiomas se pueden elegir aquellos que se basen en la utilización de la lengua de signos:


Y también dispone de un modo accesibilidad que parece que activa o desactiva el subrayado de los enlaces:








lunes, 22 de agosto de 2016

Mejoras en Narrator

Narrator es el lector de pantallas de Microsoft que está disponible por defecto en su sistema operativo Windows.

Nunca ha sido un serio competidor frente a otros lectores de pantalla como JAWS, Window-Eyes, VoiceOver o NVDA, pero esto parece que está cambiando.

En Improvements to Narrator in Windows 10 explican que están mejorando sus características y su funcionamiento con Microsoft Edge en Windows 10.

jueves, 18 de agosto de 2016

Herramienta para automatizar análisis de accesibilidad

TheA11yMachine es una herramienta automática de evaluación de la accesibilidad web que rastrea y evalúa las páginas de un sitio web para generar un informe detallado.

miércoles, 17 de agosto de 2016

Enlaces accesibles sin el subrayado

Quitarle el subrayado a los enlaces no es una buena práctica, ni desde el punto de vista de la usabilidad ni desde el punto de vista de la accesibilidad. Sin embargo, es algo que todos hemos hecho, hacemos y seguiremos haciendo.

En Accessible links without underlines se explica lo que se debe tener en cuenta para garantizar que los enlaces seguirán siendo accesibles aunque se elimine el subrayado.

lunes, 15 de agosto de 2016

Perfil para personas con discapacidad

Global Public Inclusive Infrastructure (GPII) es una propuesta de desarrollo de un perfil de usuario para la Web y para cualquier tipo de dispositivo que incorpore el perfil de discapacidad del usuario. De este modo, cuando un usuario acceda a un dispositivo que no sea el suyo, al identificarse con su perfil el dispositivo se adaptará a sus necesidades.

Una gran solución a un problema actual. Esperemos que sea adoptado, aunque lo veo difícil por las inercias que suele tener la industria a este tipo de propuestas.

viernes, 12 de agosto de 2016

Controla el ordenador con la mente

En TED he encontrado el vídeo A headset that reads your brainwaves:

Tan Le's astonishing new computer interface reads its user's brainwaves, making it possible to control virtual objects, and even physical electronics, with mere thoughts (and a little concentration). She demos the headset, and talks about its far-reaching applications.



Más vídeos en TED sobre discapacidad: Designing for disability

miércoles, 10 de agosto de 2016

El uso del atributo title

El atributo title, ese atributo que se puede utilizar para añadir información a cualquier cosa de una página web suele causar bastante confusión.

Ya he escrito sobre su uso anteriormente:


El atributo title realiza unas funciones especiales en los elementos abbr, dfn, input, link y style. En el resto de elementos su función es proporcionar advisory information (3.2.5.2 The title attribute), que se traduce por "información de asesoramiento", lo cual no se entiende muy bien. Quizás sea mejor decir "información adicional o complementaria".

"Información adicional o complementaria" deja bien claro que debe ser usado para añadir información a alguna información que ya se ha proporcionado previamente. Si no se ha hecho, como por ejemplo cuando se usa el atributo title en vez del atributo alt, se está haciendo muy mal.

El W3C ya avisa de ello con una advertencia:

Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g. requiring a pointing device such as a mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).


Como me siguen preguntando por su uso, ahí van algunos consejos:

  • No se debe emplear para proporcionar información vital o necesaria para la accesibilidad. Por tanto, no se debe emplear como sustituto del texto alternativo (alt), de las etiquetas de los controles de formulario (label), de los encabezados de tabla (th), etc.
  • No se debe emplear para proporcionar la misma información que esté disponible como texto o texto alternativo.
  • No se debe emplear para presentar información obvia.
  • Se debe usar con cuidado en los enlaces y botones pequeños, porque al mostrarse el tooltip puede cubrir el elemento asociado.
  • Siempre se debe emplear en la etiqueta frame para definir el propósito de un marco en una página web (aunque el uso de los marcos está desaconsejado desde hace tiempo).
  • La regla básica para su uso es sencilla: la página web se debe emplear sin ningún problema si el atributo se elimina.

martes, 9 de agosto de 2016

Podcasts sobre accesibilidad web (2)

El segundo podcast de Rob Dodson publicado hasta ahora:

lunes, 8 de agosto de 2016

Podcasts sobre accesibilidad web (1)

Rob Dodson, desarrollador de Google, ha iniciado una serie de podcasts sobre accesibilidad web:

viernes, 5 de agosto de 2016

La accesibilidad de reCAPTCHA

El artículo reCAPTCHA Accessibility reVISTED analiza la accesibilidad de reCAPTCHA, el sistema de captcha de Google.

Las conclusiones son que tiene problemas y no es accesible:
  1. People who are deaf-blind cannot complete the secondary CAPTCHA. Neither the visual nor audio CAPTCHA is accessible to them. The only hope for them is if they never have to proceed beyond the simple checkbox. The checkbox itself is accessible.
  2. The secondary CAPTCHA is language and culture-specific. Take, for example, the visual CAPTCHA shown above which asks users to identify the sandwiches. Users must understand English well enough to understand the question, and they must be familiar with sandwiches. (And anyone who attended HighEdWeb 2015 knows that sandwich is not an indisputable concept).
  3. Keyboard users with eyesight can't access the visual challenge. They can access the audio challenge, but how would they know to pursue that option? It's not at all intuitive, plus visible keyboard focus is dubious.

jueves, 4 de agosto de 2016

Accesibilidad web para autores de contenido

El artículo How to Convince Writers to Write for Accessibility proporciona los siguientes consejos dirigidos a los autores o escritores de contenido:

  • Write a Unique Title for Every Page
  • Use True Headings and Use Them in Order
  • Highlight Key Information with Lists
  • Use Keywords in Image File Names
  • Write a Meaningful Text Equivalent for Images
  • Write Link Text That Makes Sense Out of Context and the Destination Clear

miércoles, 3 de agosto de 2016

martes, 2 de agosto de 2016

Lista de verificación para diseñadores, ingenieros, gestores de proyectos, aseguradores de calidad y creadores de contenido

Muy interesante el recurso The Checklist, que plantea diferentes listas de verificación según el perfil del implicado en un desarrollo web:

Designers
Make sure there is enough contrast between text and its background color
Don't indicate important information using color alone
Pair values of colors together (not only hues) to increase contrast
Don't rely on sensory characteristics as the sole indicator for understanding and operating content
Design focus states to help users navigate and understand where they are
Help users understand inputs, and help them avoid and correct mistakes
Write good alt text for your images
If an experience cannot be made accessible, create another route for users to get that information
Be as consistent and clear as possible in layout and copy

Engineers
Use the correct HTML element for your content
Support keyboard navigation
Understand and use HTML landmarks
Write good alt text for your images
Design focus states to help users navigate and understand where they are
Help users understand inputs, and help them avoid and correct mistakes
Use ARIA attributes when applicable
Give users a way to skip top level navigation to access main content
Make links descriptive
Avoid text in pseudo elements
Make SVGs accessible to assistive technology
Hide decorative elements from screen readers
Create alternate routes for users to access information
Links should be visually identifiable and have clear :focus and :active states

Project Managers
Familiarize yourself with the work associated with making content accessible
Build in time for accessibility during project planning and sprint planning
When sharing good work done by your team, praise efforts to increase accessibility
The tools and products that you create should make accessibility easier to achieve
Be an advocate for accessibility

Quality Assurance
Run through each page with the WAVE Chrome Extension
Users should be able to navigate through content using their keyboard
Users should be able to navigate content using a screen reader
The general architecture and hierarchy of the content should make sense
Charts and images should all have alt-text so that users with screen readers or users on a slow connection will still be able to understand the images
Decorative images should not be visible to screen readers

Editorial
Write good alt text for your images
Editorial Engineers: think about how custom experiences can be made accessible
Be as consistent and clear as possible
Links should be descriptive
Important information should not be conveyed through images, color, or sensory characteristics alone