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.
