Evaluación de la accesibilidad web mediante lectores de pantalla

En An Intro To Screen Reader Testing for Sighted Developers se explica:

Why You Should Know How a Screen Reader Works If You Are Sighted 

With a near perfect (either corrected or not) vision, you might never feel the need to use a screen reader when browsing the internet. So obviously, there's no need for you to understand how screen readers work or how to use one, is there? 

As a person who develops sites and applications on the web, it might already be second nature to you to make sure that the websites that you're building work as expected for your users. Checking that a web app runs fine for different user flows or that its design looks as expected across a range of browsers is crucial and might already be part of your daily routine at work when delivering a feature. Now imagine how difficult it would be to deliver a bug fix for a misaligned navigation bar on a site without having a single glance at your screen. The visual check turns out to be important to confirm that your fix for this styling bug addresses the issue, is functional and works fine in different browsers. 

Thinking about bugs that concern accessibility, is there any valid reason why a functional check would not be needed to address issues and provide valid bug fixes? Manually testing the accessibility of the websites you're building is insightful and can be the most valuable confirmation that the patches you deliver to improve its usability actually work just as expected. 

To be able to manually test websites for accessibility concerns, getting familiar with the basics of screen readers is essential to understand how users of assistive technology experience your site.

Las etiquetas flotantes son un problema

Una interesante explicación en Float labels are problematic:

The float label pattern works by having the label start off inside the input (just like placeholders do). But onfocus or when the user starts typing, the label moves above the input.
While this is better than supplanting labels with placeholders, this seductive, novel and space-saving technique is problematic for a number of reasons.

Errores de accesibilidad web por una sobreingeniería

Muy bueno el artículo Uncanny A11y en el que se presentan errores de accesibilidad web por una sobreingeniería, cuando se intenta hacer las cosas demasiado bien:

There are generally two things that contribute to this:

• thinking that using code, all the code, is the best way to make something accessible, and

• not testing with users who have disabilities.

Los ejemplos tratados son:

• Just tabindex Everything.
• Using aria-label As a Hint.
• Unhelpful alt Text.
• Overriding Default Pronunciation.

Opciones de accesibilidad en un sitio web de Naciones Unidas

Interesante el panel de opciones que posee un sitio web de Naciones Unidas. El usuario puede elegir un perfil de usuario específico:

Pero también puede realizar una configuración manual:

Una nueva forma de esconder contenido accesible

En A new (and easy) way to hide content accessibly se explica una nueva forma de esconder visualmente un contenido, pero que siga siendo accesible. Después de un largo análisis, la mejor solución es:

.visuallyhidden {
    border: 0;
    clip: rect(0 0 0 0);
    height: auto; /* new - was 1px */
    margin: 0; /* new - was -1px */
    overflow: hidden;
    padding: 0;
    position: absolute;
    width: 1px;
    white-space: nowrap; /* 1 */
}

Técnicas para la discapacidad cognitiva y las personas con problemas de aprendizaje

El documento Techniques for the The Cognitive and Learning Disabilities Accessibility Task Force (COGA) es solo un borrador, pero es un buen inicio a algo que hacía falta desde hace mucho tiempo.

ARC Toolkit

ARC Toolkit es una nueva herramienta de evaluación de la accesibilidad web, está disponible en forma de extensión para Google Chrome.

Aplicación móvil AudescMobile

Parece que esta aplicación ya tiene un tiempo, pero la acabo de descubrir y la idea es muy interesante, Aplicación móvil AudescMobile:

La ONCE y la Fundación Vodafone España lanzan la aplicación móvil AudescMobile que permite a las personas con discapacidad visual acceder a la audiodescripción de las películas, series, etc., y en general facilitar la accesibilidad a cualquier producción audiovisual. 

La aplicación ha sido desarrollada por la empresa S-Dos con el apoyo del Centro de Investigación, Desarrollo y Aplicación Tiflotécnica (CIDAT) de la ONCE y la Fundación Vodafone España. 

La solución ofrece de forma fácil y ubicua la audiodescripción en un dispositivo móvil y permite su reproducción de forma sincronizada con un vídeo en curso independientemente del medio audiovisual: cine, televisión, Internet, DVD, etc. Esta sincronización se realiza basándose únicamente en el audio del título que se está reproduciendo, independientemente de la plataforma física sobre la que se emite. 

Por otro lado, desde el punto de vista del usuario final, es de especial relevancia el hecho de que el acceso a la audiodescripción se pueda realizar desde su dispositivo móvil, sin necesidad de proveer al usuario de ningún otro dispositivo adicional para disfrutar de manera accesible a las producciones audiovisuales.

Cómo crear botones accesibles

En Accessible Icon Buttons se explica cómo crear botones accesibles:

An icon button is an icon that triggers some sort of action on the page. More accurately, technically speaking, an icon button is a button that contains an icon and no (visible) accompanying text. These buttons can be found in the majority of app and user interfaces today. The infamous hamburger menu button is a great example of such buttons when not visually labelled “Menu”. 

Putting aside the UX side of the coin and whether or not an icon alone is enough to convey meaning and functionality to users, many implementations of these buttons today lack the proper accessibility that makes them meaningful to users of assistive technologies. 

While the seemingly popular aria-label is a perfectly valid way to add an accessible name to a button (and/or other components), it is certainly not the only way, let alone the best. You could always just put text in it, for example. But what if the designer or the UI enforces the absence of visual text next to an icon? 

There is a handful of ways that an icon button can be implemented accessibly. This article is an overview of them all.

Diferentes formas de seleccionar una fecha y su accesibilidad

En Collecting dates in an accessible way se realiza un análisis de las diferentes formas de seleccionar una fecha:

1. Single date input text boxes.
2. Three input boxes – one for each of day, month, year.
3. Using JavaScript-driven date picker functionality.
4. Using HTML5’s input type="date"

Quizás no necesites un control específico para seleccionar una fecha

Muy interesante el artículo Maybe You Don’t Need a Date Picker:

Calendar controls, date pickers, date widgets, whatever you call them, however they are described, they follow the same basic principle — present the user with a calendar to enter a date (and sometimes a time).
The native implementations come from browsers when authors use <input type="date">. Usually a calendar grid, but sometimes built to look like a broken slot-machine or configurable date rubber stamp that your accountant uses.
Frameworks and libraries offer their own take on date pickers, with many more options from third-party developers. These appeal to developers who want control over the visual style, and sometimes function, of the date picker. Particularly developers who want to avoid a different experience across browsers.
The problem is that nearly every implementation of a date picker is a barrier for some set of users. I can comfortably say every one that I have seen is a problem, though perhaps there is a wonderfully robust one somewhere. Even the ARIA Authoring Practices, which is more comfortable with imperfect patterns, has not deigned to create a date picker.

Denunciar la falta de accesibilidad web en España te puede salir muy caro

En El Tribunal Supremo y la Audiencia Nacional dejan impune la vulneración de derechos fundamentales de las personas ciegas y sentencian a favor de RENFE podemos leer lo que le ha pasado a la Associació Catalana per a la Integració del Cec (ACIC).

El resumen corto es que, en vez de sancionar a RENFE por la falta de accesibilidad de su sitio web, se ha condenado a la ACIC a pagar 4000 euros en concepto de costas por presentar una denuncia. Vale la pena leer toda la historia porque es sorprendente que puedan pasar estas cosas.

Por supuesto, después de esto, pocos valientes se volverán a atrever a denunciar la falta de accesibilidad web en España.

En los siguientes enlaces, algo más de información:

• Denuncia por falta de accesibilidad en el sitio web de Renfe (1)
• Denuncia por falta de accesibilidad en el sitio web de Renfe (2)
• Denuncia por falta de accesibilidad en el sitio web de Renfe (3)

Los tipos de letra para personas con dislexia parece que no son muy útiles

En Typefaces for Dyslexia:

I’ve been writing this post in fits, so it may be a bit disjointed. I started it on my flight home from CSUN, and continued to work on it on subsequent flights. Apologies if it’s a bit chaotic.

TL;DR: Typefaces designed to help dyslexics have no effect.

I’ll list information about the two typefaces that I am aware of (which are designed explicitly for readers with dyslexia), as well as notes from the talk at CSUN and a couple other examples.

The latest study to suggest that typefaces designed to aid reading for dyslexics had little to no effect was presented at CSUN this past week. As I noted on Twitter, I already had an idea what the results would be, and I came away feeling validated.

The study hasn’t been pubished yet and I saw its first general presentation. The study was conducted at Mount Allison University, a 2,500 student college with 215 full-time students with disabilities. 50% of those students are classified as having a learning disability.

General Tip

For those of us who build applications and sites with content of any length (whether instructions for shopping carts or rant-laden long-form articles), I have found a few techniques are generally agreed upon by the community (feedback is welcome!):

• Avoid justified text.
• Use generous line spacing / leading.
• Use generous letter spacing.
• Avoid italics.
• Generally use sans serif faces.
• Use larger text.
• Use good contrast.
• Use clear, concise writing.

This generally follows rules for good typography.

You may have heard that Comic Sans is easier for readers with dyslexia to understand, but so far that evidence appears to be anecdotal. Certainly not enough to warrant punishing all your other users.

Landmarks

Landmarks es una fantástica extensión para varios navegadores web que permite navegar por las áreas de una página web.

Accesibilidad de documentos PDF con PhantomPDF de Foxit

En Foxit and PDF Accessibility se explica cómo analizar la accesibilidad de un PDF mediante el programa PhantomPDF de Foxit:

When people talk about "accessible" PDF files, they are usually referring to "tagged" PDF files. PDF tags provide a hidden, structured representation of the PDF content that is presented to screen readers. They exist for accessibility purposes only and have no visible effect on the PDF file. There is more to an accessible PDF file than tags, but an untagged PDF would not be considered "accessible". 

HTML tags and PDF tags often use similar tag names (e.g., both have tags named h1) and organization structures. If you are comfortable with HTML, you will probably have an easier time creating and editing tagged PDF files, but knowledge of HTML is not necessary.

Accessibility Insights

Accessibility Insights es una herramienta automática de evaluación de la accesibilidad web de Microsoft:
Accessibility Insights for Web is an extension for Chrome and Microsoft Edge Insider that helps developers find and fix accessibility issues in web apps and sites.

The tool supports two primary scenarios:

• FastPass is a lightweight, two-step process that helps developers identify common, high-impact accessibility issues in less than five minutes.
• Automated checks - the tool automatically checks for compliance with approximately 50 accessibility requirements.
• Tab stops - the tool provides clear instructions and a visual helper that makes it easy to identify critical accessibility issues related to keyboard access, such as missing tab stops, keyboard traps, and incorrect tab order.
• Assessment allows anyone with HTML skills to verify that a web app or web site is 100% compliant with Web Content Accessibility Guidelines (WCAG) 2.0 Level AA.
• Automated checks - the tool automatically checks for compliance with approximately 50 accessibility requirements.
• Manual tests - the tool provides step-by-step instructions, examples, and how-to-fix guidance for approximately 20 tests; many tests are "assisted", which means that the tool identifies the test instances or provides a visual helper.

Accesibilidad de documentos PDF

PDF Accessibility de WebAIM es seguramente la mejor guía sobre la accesibilidad de los documentos PDF.

Una ley para prohibir la reproducción automática y el scroll infinito

Hace unos días se publicó New bill would ban autoplay videos and endless scrolling, lo cual estará muy bien para evitar algunos problemas de accesibilidad. Al leer el titular pensaba que esa era la razón de esta ley, pero no, la razón es que produce adicción:

Snapstreaks, YouTube autoplay, and endless scrolling are all coming under fire from a new bill, which is sponsored by Sen. Josh Hawley (R-MO), targeting the tech industry’s “addictive” design. 

Hawley’s Social Media Addiction Reduction Technology Act, or the SMART Act, would ban these features that work to keep users on platforms longer, along with others, like Snapstreaks, that incentivize the continued use of these products. If approved, the Federal Trade Commission and Health and Human Services could create similar rules that would expire after three years unless Congress codified them into law. 

“Big tech has embraced a business model of addiction,” Hawley said. “Too much of the ‘innovation’ in this space is designed not to create better products, but to capture more attention by using psychological tricks that make it difficult to look away.”

Norma UNE 153010 "Subtitulado para personas sordas y personas con discapacidad auditiva"

La Norma UNE 153010 "Subtitulado para personas sordas y personas con discapacidad auditiva", de mayo 2012, explica cómo se deben crear los subtítulos para este grupo de personas. Define cosas como:

• Los subtítulos deben ocupar como máximo dos o excepcionalmente tres líneas de texto.
• El límite máximo de caracteres por línea debería ser de 37.
• El tamaño máximo de los caracteres debe ser aquél que permita presentar en pantalla un subtítulo con 37 caracteres.
• La relación de contraste entre un carácter y su contorno o caja debe tener un valor mínimo de 4.5.
• Las técnicas para identificación de personajes deben elegirse según el siguiente orden de prioridad: uso de color, uso de etiquetas, uso de guiones.

Y así un montón de cosas más que se deben tener en cuenta.

Octava encuesta del WebAIM sobre el uso de lectores de pantalla

El WebAIM ha lanzado la octava encuesta del WebAIM sobre el uso de lectores de pantalla: Screen Reader User Survey #8.

La encuesta estará disponible hasta el 13 de septiembre de 2019 y la pueden contestar todos los usuarios de lectores de pantalla, incluso los que los usan únicamente para evaluación y pruebas.