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.
