Open mhorspool opened 2 years ago
This may be slightly tangential but we should try to make sure we can designate a certain level of professionalism in the text descriptions along the lines of the DIAGRAM Center's Poet Image Description Tool framework -- particularly when provided by publishers
All the publishing formats allow alt text and descriptions for images.
For the HTML-based formats, this may also require ARIA attributes, which would increase processing complexity. It's not clear to me if there are benefits of programmatic association for braille reading, though, given that these files will be formatted specifically for braille readers.
One such attribute that is aria-braillelabel that may be applicable here. Here is the MDN documentation on aria-braillelabel
It may be helpful to be able to programmatically determine the content of the description. One of the challenges with EPUB/HTML is that there is no consistent way to indicate a long description. ARIA attributes like aria-details can be used to refer to content that is visible elsewhere in the current document, but there is not a way to specify that a section of content is an image description that I am aware of. Benefits that come to mind: The user may want to collapse the long description if it is capable of showing the included tactile graphic, or a refreshable braille display not capable of graphics could collapse the description by default but indicate that one is available, and the user could show it if desired. It should be clear where the image description begins and ends so that the user knows what content is in the added description versus the document text outside it. Techniques like the details element can serve this purpose in EPUB but they are not specific enough to be machine readable. Ability to collapse the long description, allow a user to skip to the end of it and so forth can be left to the reading software, but it would need to be able to determine what content makes up the description. Edited to say benefits at this stage instead of formal use cases.
I wonder if extending the DPUB ARIA module to include doc-detailed_description could be of benefit here.
There is the tactile graphic, and its tour or how to properly explore the tactile. I wonder if SVG has the ability to include a link to an audio and/or a text file. I would think that audio is prefered, because one would have busy fingers exploring the tactile.
I wonder if extending the DPUB ARIA module ...
This sounds more like a general property than a publishing-specific one, but we're probably getting ahead of ourselves for use cases.
As a reader without access to the means to display or produce tactile graphics, I would prefer to be able to read a text description of the graphics rather than not having any access at all.