Herramientas para medir el riesgo de epilepsia por fotosensibilidad de un vídeo

El criterio 2.3.1 de WCAG 2.1 dice:

2.3.1 Umbral de tres destellos o menos: Las páginas web no contienen nada que destelle más de tres veces en un segundo, o el destello está por debajo del umbral de destello general y de destello rojo. (Nivel A)

Nota: En la medida en que cualquier contenido que no satisfaga este criterio puede interferir con la capacidad del usuario para emplear la página en su conjunto, todo contenido de la página web (tanto si satisface o no otros criterios de conformidad) debe satisfacer este criterio.

En Comprender 2.3.1: Umbral de tres destellos o menos se explica la razón de este criterio:

La intención de este Criterio de Conformidad es permitir a los usuarios un acceso completo al sitio sin provocarle convulsiones a causa de la fotosensibilidad. 

Los usuarios que sufren de desórdenes convulsivos por fotosensibilidad pueden sufrir ataques debido al contenido que destella varias veces con cierta frequencia. Algunas personas son aún más sensibles a los destellos rojos que a otros colores, por lo tanto se proporciona una prueba especial para los destellos con rojo saturado. Estas pautas estan basadas en la pautas para la industria televisiva adaptada a las pantallas de computadoras, donde el contenido es observado desde una menor distancia (con un mayor ángulo de visión).

Dos herramientas para medir el riesgo por fotosensibilidad y comprobar si un vídeo cumple con este criterio:

• Harding test.
• Photosensitive Epilepsy Analysis Tool (PEAT).

Primera versión borrador de WCAG 2.2

El pasado 27 de febrero se publicó Web Content Accessibility Guidelines (WCAG) 2.2 - W3C First Public Working Draft 27 February 2020.

La nota de prensa First Public Working Draft: WCAG 2.2 dice:

The Accessibility Guidelines Working Group (AG WG) has published a First Public Working Draft of Web Content Accessibility Guidelines (WCAG) 2.2. WCAG provides recommendations for making web content more accessible to people with disabilities. It addresses accessibility of web content on desktops, laptops, tablets, and mobile devices. Following these guidelines also makes your web content more usable to all users in a variety of situations. Please see the blog post for information on what’s new in this draft and upcoming work: Web Content Accessibility Guidelines (WCAG) 2.2 in Development.

¿Cómo usa Visual Studio un desarrollador ciego?

En How A Blind Developer Uses Visual Studio:

Saqib Shaikh, a developer who happens to be blind, shows how he uses Visual Studio 2017 with screen reader software for writing and debugging code.

¿Cómo programa un desarrollador ciego?

Muy interesante el vídeo How does a blind developer code? Plus start of react firebase starter project:

I am a totally blind coder and thought I would post this video of me doing some coding to let others know how I do it. Part of me wants to totally edit this video but I am leaving it as is. This is my first video. 

Cómo una persona ciega usa el ordenador

¿Cuántos estudiantes con discapacidad hay en la universidad española?

En el artículo Así se examinan los militares de la UNED que participan en misiones internacionales se puede leer:

Los números sirven también para definir los diferentes aspectos de la labor de la UNED, que no solo es la universidad con mayor número de estudiantes (140.000 en estudios oficiales y más de 200.000 si se incluyen los cursos de formación continua e idiomas), sino también el campus más internacional (con 7.000 estudiantes de 121 nacionalidades). Pero más allá, “está formando a 8.075 estudiantes con discapacidad, lo que supone el 33 % de todos los estudiantes de grado con discapacidad en España, y el 40 % de los que cursan un máster”, recuerda Mairal, que señala la proyección social de la UNED como una de sus grandes fortalezas. “En los últimos años, se han graduado o licenciado 2.032 estudiantes con discapacidad, una prueba inequívoca del éxito de este colectivo”. 

Para los alumnos con necesidades especiales, como la lectura en Braille, lengua de signos o diversas adaptaciones motoras, la UNED cuenta con el equipo de UNIDIS (el Centro de Atención a Universitarios con Discapacidad), que en esta convocatoria ha modificado más de un millar de ejercicios, además de contar con 4.424 asignaturas que incorporan alguna adaptación. “Realizamos exámenes en hospitales e incluso en domicilios privados... Adaptamos el examen, pero sin bajar el nivel de exigencia. Si viene un alumno invidente, no puede estar en la misma aula, porque necesita grabar el examen oralmente, o hacerlo en un teclado Braille. Puede haber incluso gente con agorafobia que necesitan examinarse solos u otros que, por una discapacidad motora, requieran de más tiempo”, sostiene Rebeca de Juan. “La casuística es muy amplia”.

Borrador de WCAG

En Web Content Accessibility Guidelines (WCAG) 2.2 se encuentra el borrador de la próxima versión de WCAG.

El objetivo de WCAG 2.2 es:

WCAG 2.2 was initiated with the goal to continue the work of WCAG 2.1: Improving accessibility guidance for three major groups: users with cognitive or learning disabilities, users with low vision, and users with disabilities on mobile devices. Many ways to meet these needs were proposed and evaluated, and a set of these were refined by the Working Group. Structural requirements inherited from WCAG 2.0, clarity and impact of proposals, and timeline led to the final set of success criteria included in this version. The Working Group considers that WCAG 2.2 incrementally advances web content accessibility guidance for all these areas, but underscores that not all user needs are met by these guidelines.

Y la compatibilidad hacia atrás se mantiene:

WCAG 2.2 builds on and is backwards compatible with WCAG 2.1, meaning web pages that conform to WCAG 2.2 also conform to WCAG 2.1, which would also conform to WCAG 2.0. Authors that are required by policy to conform with WCAG 2.0 or 2.1 will be able to update content to WCAG 2.2 without losing conformance with previous versions. 

En la versión actual de 2.2 solo hay un criterio nuevo, 2.4.11 Focus Visible (Enhanced):

When a User Interface Component displays a visible keyboard focus, all of the following are true:

• Minimum area: The focus indication area is greater than or equal to the longest side of the bounding rectangle of the focused control, times 2 CSS pixels.

• Focus contrast: Color changes used to indicate focus have at least a 3:1 contrast ratio with the colors changed from the unfocused control.

• Contrast or thickness: The focus indication area has a 3:1 contrast ratio against all adjacent colors for the minimum area or greater, or has a thickness of at least 2 CSS pixels.

Historial de locuciones en NVDA

Muy interesante el addon Speech History para NVDA:

An updated version of the Clip Copy add-on, initially created by Tyler Spivey.  The add-on allows you to review the most recent 100 items spoken by NVDA, as well as copy the selected item to the clipboard.  By default, use Shift+F11 to move back through the history, Shift+F12 to move forwards and F12 on its own to copy the selected item.  These hotkeys can be updated from within the Speech category of NVDA's Input gestures dialog.

Tenemos que hablar sobre la accesibilidad web

Interesante vídeo que explica el modelo social de la discapacidad:

No transmitas información solo con el color

Un buen ejemplo de cumplimiento del criterio de éxito 1.4.1 Use of Color:

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

Accesibilidad para las personas con problemas de visión

El artículo Accessibility - beyond the screen reader explica que normalmente los esfuerzos para lograr un sitio web accesible se centran en los usuarios ciegos que utilizan un lector de pantallas, dejando de lado los usuarios con baja visión:

For most people, Web accessibility means making content compatible with screen readers. As a designer, what first comes to mind might be providing alt text for images. As a developer, it might be adding WAI-ARIA roles and properties to the source code. As a content strategist, it might be unambiguous link text that makes sense on its own. All of these are good starting points, but ultimately, who truly benefits from these things? Blind people using screen readers, but who else? 

The needs of blind users are obviously important. But until we invest at least 6.3 times as much effort making content accessible to low vision users as we spend making content compatible to screen readers, it will be safe to say we are missing what it means to create content that is truly accessible to the widest possible range of users.

Cuando se diseña para las personas con discapacidad todos nos beneficiamos

En TED he encontrado el vídeo When we design for disability, we all benefit:

"I believe that losing my hearing was one of the greatest gifts I've ever received," says Elise Roy. As a disability rights lawyer and design thinker, she knows that being Deaf gives her a unique way of experiencing and reframing the world — a perspective that could solve some of our largest problems. As she says: "When we design for disability first, you often stumble upon solutions that are better than those when we design for the norm."



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

Una buena colección de libros sobre accesibilidad web gratuitos

Los libros son:

• Digital Accessibility as a Business Practice
• Introduction to Web Accessibility
• Professional Web Accessibility Auditing Made Easy
• Understanding Document Accessibility
• Web Accessibility for Developers

El lenguaje del tacto

El mundo en tres sentidos es un especial del periódico lainformacion.com que dedicó a la sordoceguera.

El segundo vídeo, El lenguaje del tacto:

Las manos son los ojos y los oídos de un sordociego. Se comunican con el mundo gracias a dos sistemas básicos: el dactilológico y la lengua de signos apoyada.

Libro Designing with progressive enhacement

Acabo de leer el libro Designing with progressive enhancement. La descripción del libro dice:

Progressive enhancement is an approach to web development that aims to deliver the best possible experience to the widest possible audience — whether your users are viewing your sites on an iPhone, a high-end desktop system, a Kindle, or hearing them on a screen-reader, their experience should be as fully featured and functional as possible.

Traducido al castellano:

La mejora progresiva es un enfoque para el desarrollo web que tiene como objetivo ofrecer la mejor experiencia posible a la mayor audiencia posible, ya sea que los usuarios están viendo sus sitios web en un iPhone, en un ordenador de gama alta, o en un Kindle, o escucharlos con un lector de pantallas (screen reader), su experiencia debería incluir todas las características y funciones como sea posible.

Recomiendo este libro porque muestra un interés especial por la accesibilidad web. Por ejemplo:

But this bounty of Internet riches has downside: while advanced interactions tend to work beautifully on the newest browsers that support advanced CSS and JavaScript, there's a whole universe of web-enabled devices -from the newest Kindle or Wii gaming system to a wide range of older computers and mobile phones- that have limited or no support for these features, and can be left with a broken and unusable experience. And even with a modern browser, sites can exclude blind or vision-impaired users if web developers don't take care to support keyboard interaction and layer in specific accessibility features required by screen-reader software and other assistive devices.

Traducido al castellano:

Pero esta abundancia de las riquezas de Internet tiene inconveniente: mientras que las interacciones avanzadas tienden a trabajar muy bien en los más nuevos navegadores que soporten CSS avanzado y JavaScript, hay todo un universo de dispositivos-desde la web habilitada la nueva coleccion de juegos Kindle o Wii a una amplia gama de los equipos más antiguos y los teléfonos móviles-que no tienen soporte para estas características limitadas o, y pueden resultar con alguna experiencia roto e inservible. E incluso con un navegador moderno, los sitios pueden excluir a los usuarios ciegos o con problemas de visión, si los desarrolladores web no cuidan para apoyar la interacción del teclado y de la capa en las características específicas de accesibilidad que precisa el software lector de pantalla y otros dispositivos de asistencia.

Consejos para que el audio y el vídeo sea accesible

En Making Audio and Video Media Accessible del W3C se explica cómo crear contenido multimedia accesible:

Accessible audio and video is essential for people with disabilities, and benefits organizations. Depending on the content of your media, it might need captions/subtitles (a text version of the audio that is shown synchronized in the media player), a transcript (a separate text version of the audio), audio description of visual information (usually an additional audio stream that describes important visual content), or other accessibility functionality/features.

La semántica lo es todo para la accesibilidad web

En Semantics to Screen Readers se explica:

Assistive technologies (ATs), which are hardware and software that help us perceive and interact with digital content, come in diverse forms. ATs can use a whole host of user input, ranging from clicks and keystrokes to minor muscle movements. ATs may also present digital content in a variety of forms, such as Braille displays, color-shifted views, and decluttered user interfaces (UIs). 

One more commonly known type of AT is the screen reader. Programs such as JAWS, Narrator, NVDA, and VoiceOver can take digital content and present it to users through voice output, may display this output visually on the user’s screen, and can have Braille display and/or screen magnification capabilities built in. 

If you make websites, you may have tested your sites with a screen reader. But how do these and other assistive programs actually access your content? What information do they use? We’ll take a detailed step-by-step view of how the process works.

El artículo incluye estas figuras:

Cómo hacer accesible el típico menú de la hamburguesa

El ejemplo de Accessible Slide Menu es totalmente accesible mediante teclado.

Cómo hacer botones de radio y casillas de verificación accesibles

En Under-Engineered Custom Radio Buttons and Checkboxen:

I keep seeing overly-complex controls with additional elements as style hooks, scripting to make up for non-semantic replacements, images that need to be downloaded, and so on.

This is silly. Here are some really simple styles to make radio buttons and checkboxes look unlike native controls (which seems to be the main goal from these over-engineered attempts).

Propósito de año nuevo: NO USES PLACEHOLDER

En este año nuevo, por favor, no uses el atributo placeholder. O si lo usas, úsalo correctamente.

Ya he escrito sobre placeholder varias veces, por ejemplo, Cómo joder a la gente con el placeholder. Sí, cuando usas placeholder, normalmente lo usas mal y le estás jodiendo la vida a un montón de personas.

¿No me crees? Lee Don’t Use The Placeholder Attribute:

The placeholder attribute contains a surprising amount of issues that prevent it from delivering on what it promises. Let’s clarify why you need to stop using it.