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.
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." |
A figcaption is not a substitute for alt textY el artículo realiza un análisis del soporte de estas dos etiquetas por parte de varios lectores de pantalla.
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?
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.
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.
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.
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.
Screen Reader
|
Points
|
Percentage
|
JAWS
|
85.5
|
93%
|
HAL
|
85.5
|
93%
|
NVDA
|
69
|
75%
|
VoiceOver
|
58
|
63%
|
Orca
|
54
|
59%
|
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.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.
[...]
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.
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.
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.
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.
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.
There are generally two things that contribute to this:Los ejemplos tratados son:
- thinking that using code, all the code, is the best way to make something accessible, and
- not testing with users who have disabilities.
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.
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.
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.
