Lista de cursos sobre accesibilidad web

En Accessibility Courses hay una lista muy completa de cursos sobre accesibilidad web:

University (Paid)

• Central Washington University (CWU) Program dedicated to increasing awareness for accessibility issues
• Georgia Institute of Technology: Information and Communication Technology (ICT) Accessibility Verified Certificate
• Media Access Australia (W3C Member): Professional Certificate in Web Accessibility
• Mohawk College: Ontario College Graduate Certificate in Accessible Media Production
• University of Illinois DRES IT Accessibility Badging Program
• University of Illinois Information Accessibility Design and Policy (IADP): Certificate Program
• University of South Australia: Professional Certificate in Web Accessibility
• Ryerson University: The Chang School: Web Accessibility Auditing and Reporting
• Ryerson University: The Chang School: Web Accessibility for Developers

Private (Paid)

• 4syllables's Accessibility for web writers
• Deque University - Note: PwD are eligible for scholarships
• Level Access (previously SSB Bart Group) - Access University
• Online Learning Consortium (OLC) Institute for Professional Development Accessibility Track
• Pacellio Group - TPG Tutor
• Pluralsight - Making a Web Form Accessible
• Pluralsight - Meeting Web Accessibility Guidelines (Section 508/ WCAG 2.0)
• Siteimprove Academy
• Styles in MS Word: A Primer for Accessible Document Design, the Course!
• Team Treehouse - Web Accessibility Compliance
• UX Foundations: Accessibility
• WebAIM's Web Accessibility Training

Conferences & Events

• A11Y Project Events
  • A11yTO
  • A11yCamp Australia
• Accessing Higher Ground
• Accessible by Design
• ASSETS: ACM SIGACCESS Conference on Computers and Accessibility
• CSUN Assistive Technology Conference
• Environments for Humans' Accessibility Summit
• Inclusive Design 24 (#ID24):
  • October 2019 Playlist (YouTube)
  • October 2018 Playlist (YouTube)
  • November 2017 Playlist (YouTube)
  • June 2017 Playlist (YouTube)
  • 2016 Playlist (YouTube)
  • 2014 Playlist (YouTube)
• Knowbility's AccessU
• Web4All

Free

• Accessibility MOOC - Inclusive Online Course Design
• Digital Accessibility as a Business Practice
• Future Learn - Digital Accessibility: Enabling Participation in the Information Society
• Google's Udacity Accessibility course (text version)
• Google's Udacity Web Accessibility - Developing with Empathy
• Microsoft's Training teachers to author accessible content
• Professional Web #A11y Auditing Made Easy
• Start Building Accessible Web Applications Today, by Marcy Sutton
• Teach Access
• UC Berkeley Intro to Course #Accessibility - 6 modules on designing accessible content
• Open.edu: Assistive technologies and online learning
• Ryerson University & Canvas.net: Web Accessibility for Developers
• University of Colorado Boulder & Coursera: Basics of Inclusive Design for Online Education
• Minnesota IT Services: Accessible Word Document Training
• UNICEF Agora Training on Web Accessibility

Webinars

• 3playmedia
• Accessibility Association
• Accessibility Talks (A11Y Talks) - Virtual meetup and video series

Educational Videos

• 3playmedia's Videos
• A11ycasts with Rob Dodson
• Debugging Accessibility with Alice Boxhall
• Marcy Sutton's Accessibility Presentations
• State of Texas Creating Accessible Microsoft Office Documents

Meetups

Also refer to the AccessMeetups Twitter list by Web Axe and this other meetup list by Deborah Edwards-Onoro.

• Accessibility DC
• Boston Accessibility
• Buffalo Accessibility Meet-up (Buffa11y)
• Chicago Digital Accessibility and Inclusive Design
• London Accessibility Meetup
• Montreal's web accessibility & inclusive design meet-up
• Mid-MO Web Accessibility Meetup
• New York City A11yNYC
• Ottawa a11yYOW
• Portland Accessibility and User Experience Meetup
• Quebec City a11yQC
• Raleigh-Durham a11yRTP
• role=drinks
• role=drinks Hamburg
• San Francisco
• Seattle Area Accessibility & Inclusive Design
• Toronto a11yTO - both a meetup and a conference
• Web Accessibility & Inclusive Design - Sydney
• Web Accessibility & Inclusive Design - Melbourne
• Digital Accessibility and Inclusive Design Meetup - Auckland

Certificates

• International Association of Accessibility Professionals (IAAP) Certification
• Media Access Australia (W3C Member): Professional Certificate in Web Accessibility
• Mohawk College: Ontario College Graduate Certificate in Accessible Media Production

Vendor Materials

• Chrome & Chrome OS Accessibility (on YouTube)

For More Information

• Books, tutorials & blogs here
• Follow these people on Twitter
• A11ySlack Slack Channel

Metadatos sobre accesibilidad

En la página Publication Manual of the American Psychological Association (pero supongo que ocurrirá también en otras páginas de esta editorial) he encontrado algo muy interesante:

Parece que hace uso de Schema.org para indicar las características de accesibilidad. En concreto, las propiedades de CreativeWork:

ccessMode	Text	The human sensory perceptual system or cognitive faculty through which a person may process or perceive information. Expected values include: auditory, tactile, textual, visual, colorDependent, chartOnVisual, chemOnVisual, diagramOnVisual, mathOnVisual, musicOnVisual, textOnVisual.
accessModeSufficient	ItemList	A list of single or combined accessModes that are sufficient to understand all the intellectual content of a resource. Expected values include: auditory, tactile, textual, visual.
accessibilityAPI	Text	Indicates that the resource is compatible with the referenced accessibility API (WebSchemas wiki lists possible values).
accessibilityControl	Text	Identifies input methods that are sufficient to fully control the described resource (WebSchemas wiki lists possible values).
accessibilityFeature	Text	Content features of the resource, such as accessible media, alternatives and supported enhancements for accessibility (WebSchemas wiki lists possible values).
accessibilityHazard	Text	A characteristic of the described resource that is physiologically dangerous to some users. Related to WCAG 2.0 guideline 2.3 (WebSchemas wiki lists possible values).
accessibilitySummary	Text	A human-readable summary of specific accessibility features or deficiencies, consistent with the other accessibility metadata but expressing subtleties such as "short descriptions are present but long descriptions will be needed for non-visual users" or "short descriptions are present and no long descriptions are needed."

Podemos encontrar más información sobre esto en WebSchemas/Accessibility del W3C.

Deque University

La consultora de accesibilidad web Deque ofrece Deque University, un servicio de enseñanza de la accesibilidad web. Entre sus cursos aparece:

• Fundamentals:
• Accessibility Fundamentals: Disabilities, Guidelines, and Laws
• Designing an Accessible User Experience
• Basic Web and Document Accessibility for Content Contributors
• Section 508: Fundamentals of the Law and Technical Standards
• IAAP CPACC (Certified Professional in Accessibility Core Competencies) Exam Preparation:
• IAAP CPACC Certification Preparation Course
• Web Accessibility:
• Semantic Structure and Navigation
• Images, SVG, and Canvas
• Visual Design and Colors
• Responsive Design and Zoom
• Multimedia, Animations, and Motion
• Device-Independent User Input Methods
• Form Labels, Instructions, and Validation
• Dynamic Updates, AJAX, Single Page Apps
• Custom JavaScript/ARIA Widgets
• Web Accessibility Testing: Screen Readers
• Web Accessibility Testing: Basic Methods and Tools
• Web Accessibility Testing: WCAG Conformance Testing, Detailed Methodology
• Document Accessibility:
• Basic Web and Document Accessibility for Content Contributors
• MS Word Accessibility
• MS PowerPoint Accessibility
• MS Excel Accessibility
• InDesign Accessibility
• PDF Accessibility
• EPUB Accessibility
• Accessibility Management:
• Accessibility Program Management
• Native Mobile App Accessibility:
• iOS Mobile App Accessibility
• Android Mobile App Accessibility

Sobre el uso correcto de figure y figcaption

En How do you figure? se explica el uso correcto de las etiquetas figure y figcaption:

A figcaption is not a substitute for alt text
Regarding images used within figures, one of the biggest misunderstandings of using a figcaption is that it’s used in place of image alternative text. Such a practice is outlined in HTML 5.2 as being a last ditch effort to convey meaningful information, but only when images are published without an author being able to provide appropriate alt text.
From the guidance of HTML 5.2:
Such cases are to be kept to an absolute minimum. If there is even the slightest possibility of the author having the ability to provide real alternative text, then it would not be acceptable to omit the alt attribute.
A figcaption is meant to provide a caption or summary to a figure, relating it back to the document the figure is contained within, or conveying additional information that may not be directly apparent from reviewing the figure itself.
If an image is given an empty alt, then the figcaption is in effect describing nothing. And that doesn’t make much sense, does it?

Y el artículo realiza un análisis del soporte de estas dos etiquetas por parte de varios lectores de pantalla.

Accessibility Conformance Testing (ACT)

Accessibility Conformance Testing (ACT) Rules Format 1.0 es un nuevo estándar del W3C que tiene como objetivo:

ACT Rules Format defines a format for writing accessibility test rules. These rules can then be shared, compared, and implemented by developers of automated testing tools and manual testing methodologies. This contributes to a common set of rules and harmonized interpretation of Web Content Accessibility Guidelines (WCAG). More info is in the ACT Overview at https://www.w3.org/WAI/standards-guidelines/act/

W3C groups are providing vetted testing rules that follow the ACT Rules Format.

• Rules that are formally published by W3C WAI are listed in the Overview page: https://www.w3.org/WAI/standards-guidelines/act/#act-rules-repository
• Suggested rules in development by the ACT Rules Community Group are listed at: https://act-rules.github.io/rules/

Análisis del selector de fechas

En Collecting dates in an accessible way se ofrece un análisis exhaustivo de cuál es la mejor forma de seleccionar una fecha en una página web:

Currently, providing a usable and accessible method for collecting dates in forms is fraught with difficulty. Due to the lack of consistent and accessible support for input type=”date”, and the difficulty of finding date-pickers that are accessible to keyboard users and screen reader users, is it safest to just go back to using text boxes and dropdowns?
I believe you must include the include the ability for the user to enter a date using a text box or dropdowns – for keyboard-only users and screen reader users this is still the best and easiest option.
However, as we’ve seen, many people like date-pickers, including people with some disabilities, so if you wish to present a calendar-style date-picker:

• never force people to use it, but instead have it as an option triggered by a button, and

• hide the date-picker from screen reader users.

Día Internacional de las Personas con Discapacidad

Ayer, 3 de diciembre, se celebró el Día Internacional de las Personas con Discapacidad.

Para celebrarlo, el W3C anunció la apertura de su curso Introduction to Web Accessibility, ofrecido en la plataforma edX. El contenido del curso es:

This course is based on the open curricula from the W3C Web Accessibility Initiative (WAI).
Module 1: What is Web Accessibility (2 sections)

• Introduces the broad scope of digital accessibility through real stories of people with disabilities
• Examples of how accessibility impacts the lives of interacting in the digital world

Module 2: People and Digital Technology (5 sections)

• Explores how people with different disabilities use various assistive technologies and adaptive strategies
• Introduces accessibility barriers and accessibility solutions
• Explores how design decisions impact interactions
• Explains the essential components of web accessibility

Module 3: Business Case and Benefits (2 sections)

• Presents direct and indirect return of investment and the organizational business case
• Explains the broader benefits for everyone, with or without disability

Module 4: Principles, Standards, and Checks (5 sections)

• Covers international accessibility standards from W3C Web Accessibility Initiative (WAI)
• Explains the guiding principles of web accessibility: Percievable, Operable, Understandable, and Robust (POUR)
• Guides through first steps in checking accessibility and applications

Module 5: Getting Started with Accessibility (2 sections)

• Explains approaches for integrating accessibility into your design and development processes
• Provides tips to get started with accessibility right away

Accesibilidad de las imágenes en textos digitales (LS)

Se ofrecen recomendaciones para asegurar la accesibilidad de las imágenes en los textos digitales.

Los captchas y la accesibilidad

Una breve explicación en I'm Not A Robot:

CAPTCHA stands for Completely Automated Public Turing Test to tell Computers and Humans apart and it’s a way to filter out bots and fraudulent automated activity from the behaviour of real people. It's an umbrella term describing several different techniques presented to the user to determine if they are human. A CAPTCHA challenge could be a random collection of letters and numbers, text obscured with background noise, puzzle challenges or audio challenges asking the user to enter the letters and numbers heard with a lot of background static noise. All of these are termed CAPTCHA as they're asking the user to demonstrate they're human and not an automated computer program. 

The theory is humans are very good at being able to identify distorted text, numbers and audio but not a computer program. A computer program i.e. bot can't reliably identify displayed text or audio and so it's a very effective way to stop bot activity affecting your website. 

The problem is CAPTCHA in its many incarnations causes significant challenges for people with disabilities. Asking a user to decipher distorted text may mean vision-impaired people will be unable to complete it. Presenting an audio challenge may mean people with a hearing impairment will have difficulty, reorientating a visual 3D puzzle may affect users with mobility and cognitive impairments and disabilities are rarely isolated, users may have a range of disabilities. 

If your security check is relying on some kind of user input to determine the "humanness" of the person at the other end, it is ultimately doomed to failure.

Accesibilidad de los textos digitales. Parte II (LS)

Definición del contenido tipo texto
La importancia de etiquetar el idioma
Incluir un glosario
Hacer tablas y listas accesibles
El tipo de fuente, su tamaño, el contraste con el fondo y la alineación del texto.         
No utilizar imágenes para transmitir texto
Cómo incluir texto matemático

Canal de vídeo Accessibility Talks

Accessibility Talks es un excelente canal de vídeos en YouTube dedicado a la accesibilidad. Tiene diferentes listas de reproducción donde se clasifican los vídeos para principiantes, desarrolladores y paneles de discusión.

Un vídeo organizado por capítulos

Un vídeo organizado por capítulos ayuda a navegar por su contenido, lo cual ayuda a mejorar la usabilidad para todos los usuarios y también su accesibilidad.

En Adding Chapters to a Video se explica cómo se puede lograr con un reproductor de vídeos llamado Brightcove Player. Los capítulos se especifican mediante un fichero WebVTT, así que es posible que sea compatible con los reproductores nativos de los navegadores... hay que probarlo.

En YouTube se puede lograr una navegación por capítulos indicando el instante de tiempo en la descripción del vídeo. Desafortunadamente, no es muy usable, ya que muchas veces aparecen ocultos los enlaces y los usuarios no son conscientes de ello.

Y aquí un ejemplo de uno de mis vídeos en YouTube que hace uso de esta técnica:


Los enlaces a los capítulos aparecen en la descripción del vídeo.

Accesibilidad de los textos digitales. Parte I (LS)

Definición del contenido tipo texto La importancia de etiquetar el idioma Incluir un glosario Hacer tablas y listas accesibles El tipo de fuente, su tamaño, el contraste con el fondo y la alineación del texto. No utilizar imágenes para transmitir texto Cómo incluir texto matemático.

Vídeo con múltiples pistas de audio

Ofrecer un vídeo con múltiples pistas de audio es una forma de mejorar la accesibilidad de un vídeo. Por ejemplo, una pista puede tener solo lo que se habla, lo que se conoce como "clean audio". Y otra pista puede tener una audiodescripción.

En las siguientes páginas se ofrecen ejemplos de vídeos con varias pistas de audio:

• Multiple Audio Tracks
• Display multi language and audio options available with the Bitmovin player

International Association of Accessibility Professionals (IAAP)

International Association of Accessibility Professionals (IAAP)  es una asociación internacional que tiene como misión:

to define, promote and improve the accessibility profession globally through networking, education and certification in order to enable the creation of accessible products, content and services.

Tiene un apartado dedicado a webinars muy interesante.

Productos de apoyo para todos

Productos de apoyo y tecnologías de la información y las telecomunicaciones - Estamos rodeados de tecnologías y de productos de apoyo, que hacen nuestra vida más cómoda y segura.




 En el siguiente enlace puedes descargarte el fichero con la transcripción del vídeo "Productos de apoyo para todos" del que anteriormente te invitábamos a fijarte en sus subtítulos y audiodescripción. Este fichero en formato pdf es un ejemplo de transcripción de vídeo.

El texto de la transcripción equivale a la unión del texto de los subtítulos y de la audiodescripción. Leyendo ese archivo tenemos una información equivalente a la que tenemos si vemos y oímos el vídeo.

¿Dónde está BLITAB?

BLITAB fue anunciada hace unos años como la primera tableta para las personas ciegas:

• Blitab es el tablet perfecto para personas ciegas, ahora solo falta que llegue al mercado
• BLITAB, el iPad para invidentes de Kristina Tsvetanova

En abril de 2019, volvió a aparecer en el blog "El futuro es apasionante" del periódico El País y patrocinado por Vodafone: Tabletas con tinta inteligente para traducir webs al braille.

¿Dónde está la tableta? En el canal de la empresa en YouTube, el último vídeo se publicó hace más de 2 años:


¿Existe la tableta o fue todo un "bluf"?

En Blitab, la tableta braille más económica se puede leer un excelente análisis sobre este invento que puede aclarar lo que ha pasado con él.

Sin embargo, lo que es más increíble, es que la página tenga un enlace a una versión accesible del sitio web, lo cual va en contra de todas las pautas de accesibilidad, y dirija a una página web en la que pone lo siguiente:

Coming soon
We are  currently  improving  our website

Cómo crear vídeos accesibles

En Checklist for creating accesible videos se explica cómo crear vídeos accesibles:

1. CREATE ACCESSIBLE VIDEO CONTENT
2. CHOOSE A CURRENT VIDEO FORMAT FOR THE WEB
3. CHOOSE AN ACCESSIBLE VIDEO PLAYER
4. ADD CAPTIONS TO YOUR VIDEO
5. ADD A TRANSCRIPT TO YOUR VIDEO
6. INCLUDE AUDIO DESCRIPTION IF NEEDED

Y como resumen:

An accessible video usually includes captions; a transcript; and careful use of color, text, and flashes or animation. A video should also be delivered in an accessible format with an accessible media player, and may include additional audio description when the default audio track isn't sufficient.

Accessibility in JavaScript Applications

Accessibility in JavaScript Applications es un curso sobre:

We can produce innovative and inclusive JavaScript-powered web apps! This course will teach you to remove barriers to access that might prevent people with disabilities from using a modern JavaScript web application. We’ll study accessibility in UI components, primarily with React and Gatsby.js, but with knowledge applicable to all JavaScript-heavy web stacks. Debug your sites for accessibility, manage keyboard focus, announce live updates to the page to screen readers, and use manual and automated testing to gain web accessibility superpowers!

This course and others like it are available as part of our Frontend Masters video subscription.

Accesibilidad audiovisual: subtítulos (LS)

Se presenta el concepto de los subtítulos, sus principales características, beneficios y recomendaciones para que sean accesibles.

Accesibilidad en la Unión Europea

En Accessibility: Essential for Some, Useful for All se resumen los avances en materia de accesibilidad que ha impulsado la Unión Europea:

Promoting digital inclusion, the European Union has taken measures in a variety of areas including electronic communications, digital public services, audio-visual media services, ebooks, eCommerce and ICT equipment:

1. The Web Accessibility Directive establishes common accessibility requirements enabling everyone to read, understand, and complete administrative procedures on public sector websites and mobile applications.
2. The European Electronic Communications Code ensures that everyone has access to affordable electronic communications services, including emergency services.
3. The recently revised Audiovisual Media Services Directive (AVMSD) covers the means to achieve accessibility such as with sign language, subtitling for the deaf and hard of hearing and audio descriptions for both television broadcasting (i.e. linear services) and video on demand (VOD).
4. The eIDAS Regulation (on electronic identification and trust services for electronic transactions in the internal market) requires that trust services provided and end-user products be accessible for persons with disabilities, such as with eSignatures which aid in signing legal documents and email in a paperless manner.
5. The Marrakesh Directive and Regulation (2017) aim to facilitate the access to print works, including e-books, in formats adapted for persons who are blind, visually impaired or those who have difficulties reading.
6. Whilst complementing the above legislative measures, the European Accessibility Act, sets common accessibility requirements including a number of key ICT products and services.common accessibility requirements including a number of key ICT products and services.

Álex estudia Educación Social, es sordo y usuario de lengua de signos española

Productos de apoyo y tecnologías de la información y las telecomunicaciones - Alex, estudiante de UNED quisiera que la lengua de signos estuviera más presente en la universidad: En las clases o tutorías, en los vídeos y programas de radio. Usa un sistema de interpretación en legua de signos por videoconferencia para comunicarse con un profesor y hacerle una consulta sobre una de sus asignaturas. Participante: Álex González, estudiante de UNED.

Ana estudia Filología Hispánica y es sorda

Productos de apoyo y tecnologías de la información y las telecomunicaciones - Ana Sánchez, estudiante de la UNED, es muy aficionada al cine. Para disfrutarlo necesita que la película tenga subtítulos, o que la sala de proyección disponga de un bucle magnético. También usa el bucle magnético para hablar a través de su teléfono móvil, aunque principalmente se comunica con los demás gracias a aplicaciones de mensajería instantánea para móvil. Echa de menos que los programas de radio estén disponibles en texto. Las tecnologías de hogar digital le hacen sentirse más segura y cómoda cuando está en casa. Participante: Ana Sánchez, estudiante de la UNED.

Carlos estudia Psicología y es una persona con baja visión

Productos de apoyo y tecnologías de la información y las telecomunicaciones - Carlos Javier Cortina, estudiante de la UNED. usa su ordenador ayudado de un magnificador de pantalla que además sintetiza en voz los contenidos visuales. Estudia temas de Psicología en su reproductor MP3 o Daisy, mientras espera un autobús. Utiliza un mini-GPS vocal para orientarse mientras camina por la ciudad. Lee las cartas que el banco le envía con su tele-lupa o su escáner-OCR. Participantes Carlos Javier Cortina, estudiante de la UNED.

Víctor estudia Ciencias Empresariales y es ciego

Productos de apoyo y tecnologías de la información y las telecomunicaciones - Victor Alberto Lorenzo, estudiante de la UNED, utiliza el ordenador, la telefonía móvil, busca en internet recursos para hacer un trabajo de empresariales, lee documentos, etc. Para ello utiliza lectores de pantalla y línea braille. Participantes Victor Alberto Lorenzo, estudiante de la UNED.

Accessibility Object Model

Accessibility Object Model es una nueva tecnología que permite modificar las propiedades de accesibilidad de una página web desde JavaScript. En Meaning without markup: Accessibility Object Model se explica cómo funciona esta tecnología y se ofrecen algunos ejemplos sencillos.

Accesibilidad de los colores

El artículo Contrast and Color Accessibility explica con mucho detalle los requisitos relacionados con el color y el contraste de WCAG.

El contenido es:

• Page 1: Understanding WCAG 2 Contrast and Color Requirements
• Introduction
• Defining Colors
• WCAG 2 "Contrast Ratio"
• 1.4.3 Contrast (Minimum)
• 1.4.6 Contrast (Enhanced)
• 1.4.11 Non-text Contrast
• 1.4.1 Use of Color
• Page 2: Evaluating Contrast and Color Use
• Page 3: Evaluating Contrast with Chrome DevTools

¿Se usa Orca?

Hace unos días me preguntaron por el uso de Orca, el lector de pantalla más conocido para Linux, o quizás el único que existe.

¿Se usa Orca? En el último Screen Reader User Survey #8 de WebAIM, ni se nombra.

¿Orca es un buen lector de pantalla? En el análisis Practical Screen Reader Comparison: A user-oriented approach no obtenía buenos resultados, quedaba el peor, pero bueno, es un estudio de 2011:

Screen Reader	Points	Percentage
JAWS	85.5	93%
HAL	85.5	93%
NVDA	69	75%
VoiceOver	58	63%
Orca	54	59%

Duda sobre cómo se navega con un lector de pantalla

Un estudiante mío está desarrollando una página web y le ha surgido la siguiente duda:

Me ha surgido una duda leyendo documentación y aprendiendo a utilizar VoiceOver de MacOS. Mi idea era que un usuario pudiera navegar por cada Chunk con el tabulador con información adicional, pero no sé hasta qué punto eso concuerda con la especificación. Por ejemplo, si una lección sigue esta secuencia de Chunks:

• Heading
• Text
• Text
• Heading-Text
• Bulleted-List
• Multiple-Answers

La idea era que el usuario empezara navegando con el tabulador y el lector de pantalla avisara con un “Chunk Heading… [contenido]” y al volver a presionar el tabulador “Chunk Text…[contenido]” y así hasta llegar al final de la lección, pero mi duda es si esto se debería hacer o va contra la especificación.

Y mi respuesta:

Tienes que distinguir dos posibles tipos de usuarios mediante teclado: el que puede ver y el que no.

El que puede ver normalmente es una persona con discapacidad motora que tiene dificultad para usar el ratón, pero también puede ser un usuario "pro" que prefiere el teclado porque es más rápido o un usuario norma con una "discapacidad temporal" (por ejemplo, se le ha roto el ratón). Estos usuarios pueden usar los cursores para realizar scroll up/down, así que no necesitan el tabulador para desplazarse por el contenido y leerlo, pero sí que necesitan el tabulador para desplazarse por los elementos de interacción. También les ayuda que pongas un enlace al final de la página para volver al principio de la página.

El que no puede ver usará un lector de pantalla, como VoiceOver, y conocerá todo los atajos que proporciona (y si no los conoce... es su problema, que los aprenda). La lista de comandos es enorme:

https://help.apple.com/voiceover/info/guide/10.8/spanish.lproj/_1203.html

El que no puede ver tiene dos problemas: cómo desplazarse por el contenido y leerlo (el que puede ver no tiene este problema) y cómo desplazarse por los elementos de interacción. Lo segundo lo hace con el tabulador, como el resto de usuarios. Lo primero no lo puede hacer con los cursos igual que lo hacemos nosotros porque no puede ver, así que tiene atajos para desplazarse a nivel de carácter, palabra, frase y párrafo:

Leer el párrafo del cursor de VoiceOver
VO + P

Leer el párrafo siguiente
VO + Mayúsculas + Av Pág

Leer el párrafo anterior
VO + Mayúsculas + Re Pág

Leer la frase del cursor de VoiceOver
VO + S

Leer la frase siguiente
VO + Comando + Av Pág

Leer la frase anterior
VO + Comando + Re Pág

Leer la línea del cursor de VoiceOver
VO + L

Leer la línea siguiente
VO + Flecha abajo

Leer la línea anterior
VO + Flecha arriba

Leer la palabra del cursor de VoiceOver
VO + W

Deletrear la palabra del cursor de VoiceOver
VO + W + W

Deletrear fonéticamente la palabra del cursor de VoiceOver
VO + W + W + W

Leer la palabra siguiente
VO + Flecha derecha

Leer la palabra anterior
VO + Flecha izquierda

Leer el carácter del cursor de VoiceOver
VO + C

Leer el carácter del cursor de VoiceOver
VO + C + C

Leer el carácter siguiente
VO + Mayúsculas + Flecha derecha

Leer el carácter anterior
VO + Mayúsculas + Flecha izquierda


La página web no tiene que proporcionar ningún mecanismo para ello, más allá de usar correctamente HTML. Por ejemplo, si creas "falsos párrafos", texto separado mediante BR, para el lector de pantalla no existirán esos párrafos que nosotros sí que vemos.

Para lo que me preguntas, no tienes que usar el tabulador, tienes que usar correctamente HTML. En concreto, los usuarios de lector de pantalla se desplazan por una página mediante los encabezados h1, h2, h3, etc.:


Buscar el encabezamiento siguiente
VO + Comando + H

Buscar el encabezamiento anterior
VO + Comando + Mayúsculas + H


Buscar el siguiente encabezamiento del mismo nivel
VO + Comando + M

Buscar el anterior encabezamiento del mismo nivel
VO + Comando + Mayúsculas + M


Y también usan la lista de encabezados, que en el caso de VoiceOver está disponible a través del Web Item rotor:

https://www.apple.com/voiceover/info/guide/_1134.html#mchlp2719

Por tanto, lo que quieres hacer lo tienes que hacer con un buen uso de los encabezados. Deberías usar h1 para el título del curso, h2 para el título de la lección y a partir de h3 para los chunks.

¿Por qué la web de La Moncloa hace referencia a WCAG 1.0?

En la web de La Moncloa:

Podemos ver esto en el pie de página:

¿Cómo es posible que la web de La Moncloa haga referencia a WCAG 1.0 que es del año 1999?

La ONCE abre sus 60.000 libros digitales a todos los ciegos del mundo

Una noticia muy importante, La ONCE abre sus 60.000 libros digitales a todos los ciegos del mundo:

La ONCE pone a disposición de 285 millones de personas ciegas del mundo su biblioteca digital, compuesta por más de 60.000 volúmenes, en una iniciativa sin parangón internacional, dado que supone la mayor puesta a disposición del mundo de textos accesibles en lengua castellana.
[...]
España, representada por la ONCE, se convierte así en el primer país europeo que materializa el Tratado de Marrakech y pone a disposición de usuarios y entidades autorizadas de todo el mundo su acervo bibliográfico adaptado y accesible a personas ciegas o con deficiencia visual de todo el mundo. Para ello, la Organización española acaba de poner en marcha una web que permitirá a usuarios de todo el mundo acceder a esta información cumpliendo una serie de requisitos marcados por el citado tratado de Marrakech y por la Organización Mundial de la Propiedad Intelectual (OMPI), que garantizan el correcto uso de los textos disponibles.

Se supone que los libros estarán disponibles en marrakech.once.es, pero ahora mismo solo hay una página con un formulario para iniciar sesión, sin información sobre cómo registrarse.

Según la Wikipedia, el Tratado de Marrakech:

conocido oficialmente como «Tratado de Marrakech para facilitar el acceso a las obras publicadas a las personas ciegas, con discapacidad visual o con otras dificultades para acceder al texto impreso»,​ es un tratado multilateral impulsado por la Organización Mundial de la Propiedad Intelectual (OMPI), que fue firmado en Marrakech, Marruecos, el 28 de junio de 2013.​ Este tratado entró en vigor a partir del 30 de septiembre de 2016. 

El tratado de Marrakech hace referencia a las excepciones al derecho de autor, que posibilitan la creación de versiones accesibles de obras protegidas, a personas con discapacidades que impliquen dificultades de acceso a la lectura convencional. Este instrumento establece una serie de normas para que los países que forman parte de la Organización Mundial de Propiedad Intelectual (OMPI), ratifiquen el tratado e implementen excepciones en sus legislaciones locales, tanto para la creación como para la importación y exportación de obras en formatos accesibles. Así mismo,los países que hayan ratificado el Tratado tendrán la potestad de intercambiar documentos en formatos accesibles entre ellos.

Más información en El Tratado de Marrakech explicado.

Comparativa de tres herramientas de evaluación de la accesibilidad web

En Comparing 3 Top Automated Accessibility Testing Tools: WAVE, Tenon.io, and Google Lighthouse:

Automated tools for testing accessibility have evolved to a point where you don’t have to look hard to find dozens of examples of thorough and reliable tools that test for adherence to Web Content Accessibility Guidelines. There are browser extensions, command-line tools, tools that can be integrated with continuous integration systems…

At every level of integration, these tools provide a good starting point for testing, point to patterns of errors that humans can then look out for, and can catch issues before they go to production.

Consider the following scenarios:

1. A content editor removes the contents of an h2 tag, unaware that the tag remains, causing confusion for screen reader users.
2. The theme of a website contains a ‘skip to content’ link at the top, that linked to a ‘content’ div out of the box. The developer renamed that div, breaking the link. Now keyboard-only users have no way to skip to content, and have to tab through every navigation link.
3. A designer prefers placeholder text to a field label, unaware that this may display an unlabeled field to those using a screen reader.

These issues (and many more) are very easy to miss — and they are very common. If you’re not using an automated testing tool, your site probably has similar issues.

I spent several weeks comparing these three tools in preparation for a presentation at DrupalCon Nashville. Each has a browser extension and an array of options for testing on the command line with continuous integration possibilities. They are all effective for testing a wide range of issues. The differences mainly lie in the user experience and in the scope of the tools.

An Important Caveat

Before you leap to the conclusion that an automated accessibility tool is going to do all of the work that is required to make your website accessible, we need to talk about what these tools cannot do. If your aim is to provide a truly accessible experience for all users, a deeper understanding of the issues and the intent behind the guidelines is required.

The advantages and limitations of automated tools: a few examples

Automated Tools Will Suffice for the following:

• Does the image have alt text?
• Does the form field have a label and description?
• Does the content have headings?
• Is the HTML valid?
• Does the application UI follow WCAG guideline X?

Human Intervention Is Required for the following:

• Is the alt text accurate given the context?
• Is the description easy to understand?
• Do the headings represent the correct hierarchy?
• Is the HTML semantic?
• Does the application UI behave as expected?

While automated tools can discover many critical issues, there are even more issues that need human analysis. If there is a vague or misleading alt tag, that is just as bad from a usability standpoint as a missing alt tag, and an automated tool won’t catch it. You need someone to go through the site with a sharp and trained eye.

In the end, to fully test for accessibility issues, a combination of automated and manual testing is required. Here is a great article on key factors in making your website accessible. Automated testing tools provide a good starting point for testing, point to patterns of errors that humans can then look out for, and can catch issues before they go to production.

Whether you are a developer, a QA tester, or a site owner, and whatever your technical skill level is, automated accessibility testing tools can and should become an indispensable part of your testing toolkit.

Lo que pasa cuando se usa la Web con un lector de pantalla durante un día

Muy interesante lo que se cuenta en I Used The Web For A Day Using A Screen Reader:

This was an interesting and challenging experience, and the hardest article of the series to write so far.

I was taken aback by little things that are obvious when you stop and think about them. For instance, when using a screen reader, it’s almost impossible to listen to music at the same time as browsing the web! Keeping the context of the page can also be difficult, especially if you get interrupted by a phone call or something; by the time you get back to the screen reader you’ve kind of lost your place.

My biggest takeaway is that there’s a big cultural shock in going to an audio-only experience. It’s a totally different way to navigate the web, and because there is such a contrast, it is difficult to even know what constitutes a ‘good’ or ‘bad’ screen reader experience. It can be quite overwhelming, and it’s no wonder a lot of developers avoid testing on them.

But we shouldn’t avoid doing it just because it’s hard. As Charlie Owen said in her talk, Dear Developer, the Web Isn’t About You: This. Is. Your. Job. Whilst it’s fun to build beautiful, responsive web applications with all the latest cutting-edge technologies, we can’t just pick and choose what we want to do and neglect other areas. We are the ones at the coal face. We are the only people in the organization capable of providing a good experience for these users. What we choose to prioritize working on today might mean the difference between a person being able to use our site, and them not being able to.

Let us do our jobs responsibly, and let’s make life a little easier for ourselves, with my last tip of the article:

Tip #13: Test on a screen reader, little and often.

I’ve tested on screen readers before, yet I was very ropey trying to remember my way around, which made the day more difficult than it needed to be. I’d have been much more comfortable using a screen reader for the day if I had been regularly using one beforehand, even for just a few minutes per week.

Test a little, test often, and ideally, test on more than one screen reader. Every screen reader is different and will read content out in different ways. Not every screen reader will read “23/10/18” as a date; some will read out “two three slash one zero slash one eight.” Get to know the difference between application bugs and screen reader quirks, by exposing yourself to both.

XXI Jornadas Formativas Cocemfe Alicante

Este miércoles 2 de octubre comienzan las XXI Jornadas Formativas Cocemfe Alicante: Comunicación y Nuevas Tecnologías como agentes de cambio en el ámbito de la discapacidad, que tienen como objetivos:

• Ampliar la mirada sobre temas de actualidad, cuestionar prejuicios, generar conciencia e inspirar con ideas diferentes para lograr una resignificación en temas relacionados con la discapacidad.
• Hasta el campus se desplazarán profesionales de medios para reflexionar sobre lenguaje inclusivo, expertos en inteligencia artificial, influencers y emprendedores de apps.
• También habrá lugar para el humor. En el descanso del miércoles 2, contaremos con la actuación de Fran Fernández, monologuista de Magma Comedy. ¡Ven, aprende y disfruta!

El miércoles 2 de octubre, a las 12:20 horas participaré en la sesión ¿Cómo usar la inteligencia artificial y la tecnología para mejorar la vida de las personas con discapacidad? junto con:

• Sergio Luján – Especialista en Tecnología y Accesibilidad Web en Discapacidad de la UA.
• Pedro Pernías – Director General para el Avance de la Sociedad Digital de la Conselleria de Innovación, Universidades, Ciencia y Sociedad Digital.
• Alba Alier – Asesora de Tecnología de Apoyo de BJ Adaptaciones.
• Presenta: Asunción González – Junta Directiva de Cocemfe Alicante.

Resultados de la octava encuesta del WebAIM sobre el uso de lectores de pantalla

Ya se han publicado los resultados de la octava encuesta del WebAIM sobre el uso de lectores de pantalla que se abrió en agosto de 2019: Screen Reader User Survey #8 Results.

La encuesta recibió 1224 respuestas válidas, un número muy alto de respuestas, pero menor que las 2515 y 1792 respuestas que se recibieron en la sexta y séptima encuesta respectivamente.

En cuanto a porcentaje de preferencia de los usuarios, el lector de pantalla principal ha dejado de ser JAWS, ahora es NVDA con un 40.6%, seguido de JAWS con un 40.1%. El tercero es VoiceOver con un 12.9% y el resto de lectores de pantalla tienen un porcentaje de uso muy pequeño.

El navegador que más se usa es Chrome, con un 44.4%, seguido de Firefox con 27.4% e Internet Explorer 11 con 10.9%.

Por último, los resultados de las encuestas anteriores:

• Screen Reader User Survey #7 Results (Diciembre 2017)
• Screen Reader User Survey #6 Results (Septiembre 2015)
• Screen Reader User Survey #5 Results (Enero 2014)
• Screen Reader User Survey #4 Results (Mayo 2012)
• Screen Reader User Survey #3 Results (Diciembre 2010)
• Screen Reader User Survey #2 Results (Octubre 2009)
• Survey of Preferences of Screen Reader Users (Diciembre 2008)

Vídeo sobre UNE-153010:2012. Norma Española de subtitulado para sordos

UNE-153010:2012. Norma Española de subtitulado para sordos:

Análisis de la accesibilidad para diferentes tipos de discapacidad

En Bureau of Internet Accessibility han preparado lo siguiente:

By testing according to the Web Content Accessibility Guidelines (WCAG) 2.1, BoIA tests for the experiences of a variety of abilities. But, what are we actually looking for when we test websites and apps for accessibility barriers?

• Part 1: Accessibility testing for people with visual disabilities
• Part 2: Accessibility testing for people with auditory disabilities
• Part 3: Accessibility testing for people with cognitive, learning, and neurological disabilities
• Part 4: Accessibility testing for people with physical disabilities
• Part 5: Accessibility testing for people with speech disabilities

Las próximas Jornadas Formativas Cocemfe Alicante 2-3 de octubre

Las XXI Jornadas Formativas Cocemfe Alicante: Comunicación y Nuevas Tecnologías como agentes de cambio en el ámbito de la discapacidad están convocadas para el 2 y 3 de octubre y se celebrarán en el Salón de Actos del Edificio Germán Bernácer de la Universidad de Alicante.

Estas jornadas tienen como objetivo:

• Ampliar la mirada sobre temas de actualidad, cuestionar prejuicios, generar conciencia e inspirar con ideas diferentes para lograr una resignificación en temas relacionados con la discapacidad.
• Hasta el campus se desplazarán profesionales de medios para reflexionar sobre lenguaje inclusivo, expertos en inteligencia artificial, influencers y emprendedores de apps.
• También habrá lugar para el humor. En el descanso del miércoles 2, contaremos con la actuación de Fran Fernández, monologuista de Magma Comedy. ¡Ven, aprende y disfruta!

El miércoles 2 de octubre, a las 12:20 horas participaré en la sesión ¿Cómo usar la inteligencia artificial y la tecnología para mejorar la vida de las personas con discapacidad? junto con:

• Sergio Luján – Especialista en Tecnología y Accesibilidad Web en Discapacidad de la UA.
• Pedro Pernías – Director General para el Avance de la Sociedad Digital de la Conselleria de Innovación, Universidades, Ciencia y Sociedad Digital.
• Alba Alier – Asesora de Tecnología de Apoyo de BJ Adaptaciones.
• Presenta: Asunción González – Junta Directiva de Cocemfe Alicante.

Entrevista sobre educación inclusiva y diseño universal para el aprendizaje

Del 3 al 5 de septiembre el Centro de Capacitación en Educación a Distancia (CECED) de la Universidad Estatal a Distancia (UNED) de Costa Rica, llevó a cabo una jornada de reflexión del Diseño Universal para el Aprendizaje (DUA) y la accesibilidad educativa. Durante esa jornada realicé una visita y me entrevistaron: Sergio Luján Mora: Educación inclusiva a través del Diseño Universal para el Aprendizaje.

Normativa de accesibilidad que se aplica en España

En la página Normas Accesibilidad del Portal Administración Electrónica he encontrado este documento que resume la normativa existente:

Por política comercial no podemos abrir cuentas a personas sordas

Sorprendente lo que he podido leer en Accesibilidad universal “Por política comercial no podemos abrir cuentas a personas sordas”:

Ignacio Benítez, sordo de nacimiento, se llevó una alegría al conocer que Openbank podría informarle de las condiciones de una hipoteca a través de un chat de WhatsApp. "A lo largo de mis 34 años he sido discriminado muchas veces, por lo que esta opción me pareció una buena forma de romper barreras y de acceder por mí mismo a un servicio sin necesidad de que mediase un intérprete", comenta a EL PAÍS RETINA a través de SVIsual, una aplicación que posibilita comunicaciones telefónicas entre personas con discapacidad auditiva y oyentes. Pero tras un breve intercambio de mensajes de texto el pasado seis de septiembre, el agente de Openbank finalizó la conversación con el siguiente mensaje: "Perdona, Ignacio. He consultado la situación y te informo de que, por política comercial, no podemos abrir cuentas a personas con sorderas agudas o totales, ya que no tenemos la posibilidad de una comunicación telefónica, clave en la relación con Openbank". 

Benítez, que forma parte del Comité de Diversidad e Inclusión de Accenture, se quedó "alucinado e impotente" ante ese trato que considera "superofensivo". Tras escribir a distintas asociaciones de usuarios para reclamar sus derechos, compartió su experiencia en las redes sociales y ese mismo día el asunto llegó hasta Ezequiel Szafir, CEO de Openbank, quien enseguida contactó directamente con el afectado para pedirle disculpas y manifestarle su "vergüenza" ante la respuesta "errónea" de su compañía, que no sigue ninguna política comercial como la indicada en el mensaje de WhatsApp. "Es una contestación aberrante debida a un error humano. Rarísimo, violentamente innecesario. No sabemos por qué el compañero del call center respondió así, porque precisamente al ser 100% digital somos el banco perfecto para Ignacio, que puede abrir una cuenta desde internet sin necesidad de hablar con nadie. La tecnología sirve para tirar abajo barreras y nosotros lo demostramos", comenta Szafir a EL PAÍS RETINA.

En España, el 26,2% de las personas con discapacidad afirma que ésta le impide el uso de internet, según el Observatorio estatal de la discapacidad.

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.

Domino's Pizza no hace su sitio web accesible y quiere llegar hasta la Corte Suprema

En el año 2016, Guillermo Robles denunció a Domino's Pizza porque su aplicación para pedir pizzas no era accesible.

En enero 2019, un tribunal dijo que la aplicación debía ser accesible:  Domino's Pizza app must be accessible to blind people.

Sin embargo, Domino's Pizza no está de acuerdo y quiere llevar el caso hasta la Corte Suprema: Domino’s Would Rather Go to the Supreme Court Than Make Its Website Accessible to the Blind.

Cómo denunciar la falta de accesibilidad web en España

Recientemente me han preguntado por este tema, del cual ya escribí hace tiempo la entrada ¿Cómo denunciar la falta de accesibilidad de un sitio web?. En esa entrada recomendaba la lectura de ¿Como denunciar la falta de accesibilidad de un sitio web? con @ramoncorominas y @jacarrey.

En la Oficina de Atención a la Discapacidad (OADIS) se puede presentar de forma telemática una consulta o una queja, pero no una denuncia.

Sobre Presentar una denuncia, lo que dicen no ayuda mucho:

La Oficina de Atención a la Discapacidad, tiene competencias para:

• Analizar las denuncias exclusivamente de competencia estatal.

• Asimismo, es competente en las actuaciones previas a la instrucción del expediente para analizar las denuncias y remitir a la Dirección General de Políticas de Apoyo a la Discapacidad el correspondiente informe.

Entonces ¿qué hay que hacer? Ramón Corominas y José Ángel Carrey explican:

3. Presentar una denuncia
Puedes plantear una denuncia, para que se sancione a la empresa u organismo infractor de las normas de accesibilidad, y se le obligue a cumplirlas.
Para efectuarla puedes usar el formulario oficial que encontrarás en web de infracciones y sanciones.
La presentación de esta denuncia no es posible realizarla de forma telemática, la tendrás que remitir firmada por correo postal a la siguiente dirección:
Dirección General de Políticas de Apoyo a la Discapacidad.
Paseo de la Castellana, 67, 28071 Madrid.
Procedimiento sancionador.
Una vez recibida, te asignarán un número de procedimiento.
La subdirección General de Coordinación de políticas de discapacidad, previo informe de la Oficina de Atención a la Discapacidad, iniciará la instrucción del procedimiento sancionador, y a su término, será la dirección general antes citada, o el Ministro de Sanidad, en función de la gravedad de las sanciones a aplicar, quien impondrá la sanción.

Eso es, el enlace que proporcionan conduce a Ministerio de Sanidad, Consumo y Bienestar Social - Servicios Sociales e Igualdad - Discapacidad - Protección de derechos - Infracciones y sanciones, que incluye enlaces al formulario de denuncia de infracciones en formato Word y al formulario en formato PDF editable e imprimible:

HOJA DE DENUNCIA
Infracciones y sanciones en materia de igualdad de oportunidades, no discriminación y accesibilidad universal de las personas con discapacidad (Real Decreto Legislativo 1/2013, de 29 de noviembre)

State of Accessibility Report

En State of Accessibility Report podemos encontrar la siguiente infografía y el informe asociado.