Buscador

lunes, 3 de febrero de 2020

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

viernes, 24 de enero de 2020

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.

miércoles, 22 de enero de 2020

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.

miércoles, 15 de enero de 2020

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.

lunes, 13 de enero de 2020

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:




viernes, 10 de enero de 2020

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

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

miércoles, 8 de enero de 2020

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).

lunes, 6 de enero de 2020

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.

miércoles, 25 de diciembre de 2019

Asqatasun

Asqatasun es una herramienta de evaluación de la accesibilidad web de software libre (open source). La descripción de la herramienta dice:
Asqatasun is the leading opensource software for web accessibility (#a11y) since 2007. Built with reliability in mind, it also addresses SEO concerns, and is extensible to any other domain.
Asqatasun provides a huge level of automation and can be included in Continuous Integration thanks to its Jenkins Plugin.

viernes, 20 de diciembre de 2019

Lista de cursos sobre accesibilidad web

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



University (Paid)

Private (Paid)

Conferences & Events

Free

Webinars

Educational Videos

Meetups

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

Certificates

Vendor Materials

For More Information

miércoles, 18 de diciembre de 2019

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:

ccessModeText 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.
accessModeSufficientItemList 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.
accessibilityAPIText Indicates that the resource is compatible with the referenced accessibility API (WebSchemas wiki lists possible values).
accessibilityControlText Identifies input methods that are sufficient to fully control the described resource (WebSchemas wiki lists possible values).
accessibilityFeatureText Content features of the resource, such as accessible media, alternatives and supported enhancements for accessibility (WebSchemas wiki lists possible values).
accessibilityHazardText 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).
accessibilitySummaryText 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.

lunes, 16 de diciembre de 2019

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

miércoles, 11 de diciembre de 2019

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.


lunes, 9 de diciembre de 2019

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.

viernes, 6 de diciembre de 2019

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.

miércoles, 4 de diciembre de 2019

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

lunes, 2 de diciembre de 2019

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

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

miércoles, 27 de noviembre de 2019

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.

lunes, 25 de noviembre de 2019

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