Pronunciación de abreviaturas y acrónimos

La pronunciación de abreviaturas y acrónimos puede suponer un problema para los lectores de pantalla. En ZIP, Z I P, or Z.I.P.? Forcing Correct Pronunciation in Screen Readers explican varias soluciones que se pueden aplicar para que un lector de pantallas lea lo que queremos que lea:

• Space It Out
• Aural CSS
• ARIA Labels
• The Better Solution: definir la abreviatura o acrónimo la primera vez que aparezca, pero no usar la etiqueta abbr, ya que la mayoría de los lectores de pantalla no la reconocen.

aXe

aXe es un sistema desarrollado por Deque para programar pruebas de accesibilidad automáticas. En Accessibility Testing with aXe and WebdriverJS se explica con detalle:

Why automated accessibility testing?
Automated testing can free up 30% of your manual testing effort, making it a valuable tool for software development. By scripting a browser to programmatically open web pages and perform user tasks, you can validate features without having to open each page yourself. By integrating axe-core into your tests, you can add coverage for accessibility without having to become an expert. In addition, you can benchmark accessibility support and catch regressions in your builds, preventing broken code from going to production.

Este sistema es similar a gulp-accessibility.

Soporte de HTML en los lectores de pantalla

Aural UI of the Elements of HTML es un trabajo en progreso que intenta explicar el soporte de HTML que tienen los principales lectores de pantalla (JAWS, VoiceOver, NVDA, Window Eyes, ORCA y Chromevox).

Es un trabajo impresionante que incluye grabaciones sonoras de lo que "hablan" los lectores de pantalla.

Consejos para hacer enlaces accesibles

En Making Accessible Links: 15 Golden Rules For Developers se proporcionan consejos para hacer que los enlaces sean accesibles:

1. Don’t use the word “link” in your links
2. Don’t capitalize links
3. Avoid ASCII characters
4. Avoid using URLs as link text
5. Keep link text concise
6. Restrict the number of text links on a page
7. Don’t link directly to downloads
8. Always alert the user when opening new windows
9. Be aware of pagination and alphabetized links
10. Be mindful when using anchor links
11. The case for underlining links
12. Design with keyboard-only users in mind
13. Be mindful when using images as links
14. Eliminate broken or empty links
15. Make your links consistent
16. Test your color contrast

Sí, el artículo anuncia 15 consejos, pero parece que son 16.

Siteimprove Accessibility Checker

Un nuevo complemento para evaluar páginas web en Google: Siteimprove Accessibility Checker.

Y en Siteimprove launches free Google Chrome Accessibility Checker se explican sus características:

Siteimprove continues to establish itself as a leader in digital accessibility with the release of its free Accessibility Checker for Google Chrome. The browser extension enables anyone to perform on-the-go compliance checks, with or without a Siteimprove subscription.
Using Web Content Accessibility Guidelines (WCAG 2.0), the new Accessibility Checker highlights errors on a single web page, providing clear explanations of how they affect website visitors and recommendations on how to fix them. WCAG 2.0 has been adopted as the internet standard by countries around the world, including European Union Member States, the United States, Australia, and more.

PAVE: crea documentos PDF accesibles

PAVE es una herramienta gratuita que analiza la accesibilidad de los documentos PDF. En algunos casos es capaz de corregir automáticamente los problemas encontrados.

Listas de verificación de WCAG 2.0

Algunas listas que ayudan a verificar WCAG 2.0:

• WCAG 2.0 checklists
• WebAIM's WCAG 2.0 Checklist
• How to Meet WCAG 2.0

Prevención de errores de accesibilidad en el diseño de prototipos

La presentación Early prevention of accessibility issues with mockup & wireframe reviews plantea algo muy interesante, tener en cuenta la accesibilidad desde las primeras fases de desarrollo de un sitio web:

A mockup or wireframe review is an opportunity to identify interaction design elements which are not fully accessible and will require changes. It's also the best time to identify any items that will need additional requirements to avoid becoming accessibility defects later on. After demonstrating the technique we will practice on a sample mockup. You'll leave this session with skills to apply on your next sprint.

Discapacidad y envejecimiento activo. Soportes tecnológicos.

El 20 de marzo se inicia el curso de tipo MOOC (Massive Open Online Course) Discapacidad y envejecimiento activo. Soportes tecnológicos. En este curso participo como profesor en el Módulo 2. Accesibilidad Web y Nuevas Tecnologías.

El vídeo de presentación del curso:

Accesibilidad web (conferencia completa)

Lista de verificación de WCAG 2.0

En WCAG 2.0 checklists se puede encontrar una lista más de verificación de las pautas de accesibilidad web.

Herramienta para medir la legibilidad de un texto en inglés

Readability Grader es una herramienta que mide la legibilidad de un texto en inglés. Por ejemplo:

My tailor is rich and I am happy because I am poor.

Es un texto muy sencillo, su nivel de lectura es muy bajo, 2.36.

Sin embargo, este texto:

This theory rapidly became a significant and necessary tool for theorists and experimentalists in the new fields of atomic physics, nuclear physics, and quantum mechanics.

No lo entiende nadie, su nivel de lectura es 11.41.

Lo imposible está en la mente de los cómodos

Pablo Fernández sufrió un lesión medular cuando jugaba al rugby y se quedó tetrapléjico. Es decir, su cuerpo quedó paralizado del cuello hacia abajo.

Sin embargo... Pablo es diseñador gráfico.

¿Cómo es posible?

En el siguiente vídeo de TEDx nos explica su experiencia:



Y en el siguiente vídeo explica cómo desarrollo el ratón de nuca que emplea:

Dos and don'ts: Designing for users with dyslexia

Do

• use images and diagrams to support text
• align text to the left and keep a consistent layout
• consider producing materials in other formats (for example, audio and video)
• keep content short, clear and simple
• let users change the contrast between background and text

Don't

• use large blocks of heavy text
• underline words, use italics or write capitals
• force users to remember things from previous pages - give reminders and prompts
• rely on accurate spelling - use autocorrect or provide suggestions
• put too much information in one place

Fuente: Dos and don'ts on designing for accessibility

Dos and don'ts: Designing for users who are deaf or hard of hearing

Do

• write in plain English
• use subtitles or provide transcripts for video
• use a linear, logical layout
• break up content with sub-headings, images and videos
• let users ask for their preferred communication support when booking appointments

Don't

• use complicated words or figures of speech
• put content in audio or video only
• make complex layouts and menus
• make users read long blocks of content
• don't make telephone the only means of contact for users

Fuente: Dos and don'ts on designing for accessibility

Dos and don'ts: Designing for users with physical or motor disabilities

Do

• make large clickable actions
• give form fields space
• design for keyboard or speech only use
• design with mobile and touch screen in mind
• provide shortcuts

Don't

• demand precision
• bunch interactions together
• make dynamic content that requires a lot of mouse movement
• have short time out windows
• tire users with lots of typing and scrolling

Fuente: Dos and don'ts on designing for accessibility

Dos and don'ts: Designing for users with low vision

Do

• use good contrasts and a readable font size
• publish all information on web pages (HTML)
• use a combination of colour, shapes and text
• follow a linear, logical layout -and ensure text flows and is visible when text is magnified to 200%
• put buttons and notifications in context

Don't

• use low colour contrasts and small font size
• bury information in downloads
• only use colour to convey meaning
• spread content all over a page -and force user to scroll horizontally when text is magnified to 200%
• separate actions from their context

Fuente: Dos and don'ts on designing for accessibility

Dos and don'ts: Designing for users of screen readers

Do

• describe images and provide transcripts for video
• follow a linear, logical layout
• structure content using HTML5
• build for keyboard use only
• write descriptive links and heading - for example, Contact us

Don't

• only show information in an image or video
• spread content all over a page
• rely on text size and placement for structure
• force mouse or screen use
• write uninformative links and heading - for example, Click here

Fuente: Dos and don'ts on designing for accessibility

Dos and don'ts: Designing for users on the autistic spectrum

Do

• use simple colours
• write in plain English
• use simple sentences and bullets
• make buttons descriptive - for example, Attach files
• build simple and consistent layouts

Don't

• use bright contrasting colours
• use figures of speech and idioms
• create a wall of text
• make buttons vague and unpredictable - for example, Click here
• build complex and cluttered layouts

Fuente: Dos and don'ts on designing for accessibility

Conferencia de Stephen Hawking en TED

Me ha sorprendido descubrir una conferencia de Stephen Hawking en TED. ¿Cómo la hizo? Parece que la hizo en directo, pero todo lo que dijo lo tenía escrito, porque tal como explica el presentador, para contestar una pregunta tardó 7 minutos en escribir la respuesta.



En las siguientes fotografías podemos ver el sistema de barrido que utiliza:

Este sistema es el antiguo, ahora utiliza otro sistema, aunque conserva la voz robótica que le identifica.

En la siguiente fotografía se puede ver la respuesta que tardó 7 minutos en escribir: