"Personas", con comillas, para evaluar la accesibilidad

En experiencia de usuario se emplea el término persona (así se usa en inglés) para representar un usuario concreto. Se intenta que sea lo más realista posible e incluso se le da un nombre:

The purpose of personas is to create reliable and realistic representations of your key audience segments for reference. These representations should be based on qualitative and some quantitative user research and web analytics. Remember, your personas are only as good as the research behind them. Effective personas:

• Represent a major user group for your website

• Express and focus on the major needs and expectations of the most important user groups

• Give a clear picture of the user's expectations and how they're likely to use the site

• Aid in uncovering universal features and functionality

• Describe real people with backgrounds, goals, and values

En Understanding disabilities and impairments: user profiles se describe un conjunto de "personas" (aquí lo llaman "user profiles") para discapacidad:

These profiles outline:

• the sorts of barriers some users face when they use digital services

• best practice advice on how to design services that everyone can use

Simuladores en línea de daltonismo (ceguera de color)

Hace un par de meses se publicó en microsiervos el artículo Simuladores en línea de ceguera de colores. En el artículo se comentan dos simuladores:

• Vischeck
• Coblis

Y también un simulador de visión de bebé, Tiny Eyes.

Versión accesible de Twitter

EasyChirp es una versión accesible de Twitter. Las principales características que anuncia son:

• Tweet an image with a caption and long description.
• A built-in shorten URL tool with choice of service.
• Search, user search, and saved searches.
• View, subscribe, and create Twitter Lists.
• Works great with or without JavaScript.
• Fully keyboard accessible.
• Inline threading of tweets; displays reply "conversation".
• In addition to old and new desktop browsers, I work on virtually any user-agent (even Lynx, a text-only browser), with screen readers and Braille displays, and tablets and mobile devices.

Cómo realizar un estudio de usabilidad para analizar la accesibilidad

Nielsen Norman Group, la empresa de los dos guruses de la usabilidad, ofrece la guía How to Conduct Usability Studies for Accessibility. Lástima que sea de pago, la licencia individual cuesta $82.

Los temas que cubre son:

• Learn how to adapt standard usability testing practices to accommodate people with disabilities
• Testing for accessibility and usability throughout the project lifecycle
• How we conducted our accessibility studies
• Supplement the general guidelines with empirical tests of your own design with your own users
• Trust, consent forms, pictures, and video
• Using video and still cameras
• Conducting studies at the user's home or office
• Screen reader and braille sessions
• Motor skill assistive technology sessions
• Recruiting and preparing participants
• Quantitative and qualitative study tips
• Metrics to collect
• Sample documents for accessibility studies
• Recruiting screener used in the quantitative part of the study
• Checklist used in the quantitative part of the study
• Facilitation notes used in the quantitative part of the study
• Question sheet used in the quantitative part of the study
• Consent forms

CSS puede influir negativamente en la accesibilidad de los usuarios de lectores de pantalla

El artículo Screen Readers and CSS: Are We Going Out of Style (and into Content)? analiza cómo algunas propiedades de CSS influyen en la interpretación de las páginas web por parte de los lectores de pantalla.

La conclusión es que los resultados son diferentes según la combinación de lector de pantalla y navegador que se utilice, así que toca probar, probar y probar:

All of this really highlighted the value of accessibility-minded development and pre-launch testing—in a wide variety of browser-screen reader combinations—to ensure that all website visitors enjoy a consistent, equivalent experience.

Accesibilidad web y autismo

El pasado 2 de abril se celebró el día mundial del autismo.

En How web accessibility affects people with autism explican:

The Web Content Accessibility Guidelines (WCAG) 2.0 are the most popular standard for web accessibility, and have been cited by the U.S. Department of Justice as an acceptable metric for compliance  with the Americans with Disabilities Act. WCAG 2.0 contains several guidelines to help people with four different classes of disabilities: vision, hearing, motor, and cognitive. 

People on the autism spectrum have a wide range of conditions, and many of them can face difficulties with cognition when using the internet. Some of the most relevant WCAG 2.0 recommendations for people with autism are:

• Navigation and layout should be consistent across the entire site. Performing the same or similar actions on similar user interface elements should produce similar results.

• The site should still be usable at larger text sizes and should still function with images and styles disabled. However, images, icons, and graphics that help with comprehension can be included.

• Clutter and distractions should be minimized. Style and white space should separate content and direct the user’s attention as appropriate.

• The text should be as simple as possible, while providing definitions for any non-standard terms, such as idioms, jargon, and abbreviations and acronyms. Correct grammar and spelling are important.

• Users should have as much control as possible over the site’s behavior. Avoid time limits on content or automatic refreshes whenever possible. Provide clear instructions and error messages when filling out forms.

Comparecencia de José Ángel Carrey en el Congreso de los Diputados

José Ángel Carrey, presidente de la Associació Catalana per a la Integració del Cec (ACIC), varias veces ha denunciado públicamente la falta de accesibilidad de la web de Renfe:

• Cuando navegar de oídas es una odisea: la internet española no es para ciegos
• La web de Renfe

Hace unas pocas semanas, José Ángel Carrey realizó una comparecencia en el Congreso de los Diputados:



En el instante 1:03:19 le preguntan por la accesibilidad de Renfe:


Y empieza diciendo "Renfe tiene muchos problemas de accesibilidad"... Vale la pena escucharlo.

Cómo usar los encabezados correctamente

Muy fácil de entender el artículo How to structure headings for web accessibility que incluye varios ejemplos:

When is a heading not a heading? Serious question, the answer lies behind one of the most common accessibility problems on the web.
Headings are much more than a big bold title, they provide a solid structure to the webpage. Think of headings as an outline of your webpage.
The structure should be portrayed both in a visual and technical manner, so people can see the structure, and screen readers are able to identity the structure in order to read it out.
Users who can see the page decide within seconds whether or not the content is relevant to them by skimming through headings, glancing over sub-headings keeping an eye out for significant keywords. Breaking up content with headings allows the page to be easily scanned by the user
Without a heading structure, you force users to do extra work to find the information they’re looking for, who has the time and luxury?
From an accessibility point of view the structure in the code should align with the visual presentation and make sense as a “table of contents” for the page.
Use headings to introduce content, they are labels not statements.

Dos buenos ejemplos:

Y un mal ejemplo:

Subtítulos automáticos en las emisiones en directo en YouTube

En YouTube live streams will soon include automatic captions explican que YouTube ya incorpora la posibilidad de crear subtítulos en tiempo real para las emisiones en directo (live stream). Por ahora solo está disponible en inglés.

En Use automatic captioning se dan algunos consejos para su uso:

If the live stream doesn't show automatic captions, it could be due to one or more of the following reasons:

• The feature hasn’t been enabled for the channel, as we are slowly rolling out to channels with more than 10k subscribers.

• Channel is streaming in ultra low or low latency (such as a mobile live stream). Live automatic captions are only available for normal latency streaming.

• The language in the video is not yet supported by automatic captions.

• The video has poor sound quality or contains speech that YouTube doesn't recognize.

• There are multiple speakers whose speech overlaps or multiple languages at the same time. 

Inclusive Design at Microsoft

En Inclusive Design at Microsoft se puede encontrar información sobre el compromiso de Microsoft con el desarrollo inclusivo.

El manual es muy interesante por dos cosas. Por un lado, porque el documento está publicado con una licencia  Creative Commons AttributionNonCommercial-NoDerivatives (CC BY-NC-ND).

Por otro lado, y gracias a lo anterior, significa que los elementos gráficos del manual se pueden emplear de forma gratuita, siempre que se respete la licencia anterior. Por ejemplo, los siguientes elementos:

La Web y las personas sordociegas (2): Entrevista a Sonnia Margarita Villacrés

Segunda encuesta para profesionales de la accesibilidad web

En junio de 2014, el WebAIM lanzó la primera encuesta para profesionales de la accesibilidad web. Los resultados de la primera encuesta del WebAIM para profesionales de la accesibilidad web mostraron algunos datos curiosos. Por ejemplo, en la pregunta sobre los lectores de pantalla se observó una disparidad respecto a los resultados obtenidos en la encuesta a usuarios de lectores de pantalla.

Ahora el WebAIM ha lanzado Survey of Web Accessibility Practitioners #2, que estará abierta hasta el 30 de abril de 2018.

La Web y las personas sordociegas (1): Entrevista a Sonnia Margarita Villacrés

Las novedades de WCAG 2.1

Muy interesante el artículo The new guidelines in WCAG 2.1 explained, que explica las novedades que tendrá la nueva versión de Web Content Accessibility Guidelines que seguramente se aprobará este próximo verano.

Construcción de menús accesibles

Muy interesante el artículo Building Accessible Menu Systems de Smashing Magazine.

Ejemplos de vídeos con audiodescripción

La página Web Accessibility Perspectives: Explore the Impact and Benefits for Everyone tiene vídeos sobre accesibilidad web y discapacidad. Cada vídeo aparece con dos versiones, normal y con audiodescripción.

Algunos ejemplos:

La accesibilidad web beneficia a todo el mundo

En el artículo Quality ⊃ Good Design ⊃ Inclusive Interface he encontrado la siguiente definición:

Universal web accessibility helps us create sites that are usable by the widest, most diverse audience, rather than creating bolt-on solutions that might benefit one group at the expense of another.

Y algunos ejemplos de cómo la accesibilidad web nos beneficia a todos:

I can't easily see low-contrast web content
- a user with cataracts
- any user accessing your web page on a mobile phone in bright sunlight

I can't easily manipulate your web page
- a user with a hand amputation
- any user standing in a crowded train, holding on to a bar for balance

I can't listen to your web content
- a user with hearing loss
- any user without headphones, accessing a web page in quiet restaurant

I can't easily manipulate small or fiddly UI controls
- a user with loss of fine motor control
- any user accessing a web page while also walking

I can't make sense of long complicated text passages on your web page
- a user with an attention deficit disorder
- any user reading web content while distracted by a crying child

Cómo silenciar JAWS para que solo funcione con los navegadores web

Un truco muy útil para los que usamos un lector de pantallas para revisar la accesibilidad de las páginas web: Shut up JAWS.

Cómo automatizar las pruebas de accesibilidad

En el artículo Automating Your Accessibility Tests se explica un método para automatizar las pruebas de accesibilidad:

Accessibility is one of those things we all wish we were better at. It can lead to a bunch of questions like: how do we make our site better? How do we test what we have done? Should we spend time each day going through our site to check everything by hand? Or just hope that everyone on our team has remembered to check their changes are accessible?
This is where automated accessibility tests can come in. We can set up automated tests and have them run whenever someone makes a pull request, and even alongside end-to-end tests, too.
Automated tests can’t cover everything however; only 20 to 50% of accessibility issues can be detected automatically. For example, we can’t yet automate the comparison of an alt attribute with an image’s content, and there are some screen reader tests that need to be carried out by hand too. To ensure our site is as accessible as possible, we will still need to carry out manual tests, and I will cover these later.

Nuevos criterios para discapacidad cognitiva en WCAG 2.1

En WCAG 2.1: Success Criteria for Cognitive Disabilities han recopilado los nuevos criterios de éxito que se refieren a la discapacidad cognitiva:

In particular, eleven of the new Success Criteria will result in making the web more inclusive and adaptable for a broader range of human memory, problem solving, and attention abilities.  They also expand the spectrum of human reading, linguistic, verbal, math, and visual comprehension necessary to enjoy a rich, productive experience.

• Success Criterion 2.5.1 Pointer Gestures (Level A)
• Success Criterion 2.6.1 Motion Actuation (Level A)
• Success Criterion 1.3.4 Identify Common Purpose (Level AA)
• Success Criterion 1.4.10 Reflow (Level AA)
• Success Criterion 1.4.12 Text Spacing (Level AA)
• Success Criterion 1.4.13 Content on Hover or Focus (Level AA)
• Success Criterion 2.5.4 Concurrent Input Mechanisms (Level AA)
• Success Criterion 2.6.2 Orientation (Level AA)
• Success Criterion 1.3.5 Identify Purpose (Level AAA)
• Success Criterion 2.2.6 Timeouts (Level AAA)
• Success Criterion 2.2.7 Animation from Interactions (Level AAA)