Skip to content

Allow alt text for external content resources beyond label #1288

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
azaroth42 opened this issue Oct 12, 2017 · 9 comments
Open

Allow alt text for external content resources beyond label #1288

azaroth42 opened this issue Oct 12, 2017 · 9 comments

Comments

@azaroth42
Copy link
Member

azaroth42 commented Oct 12, 2017

Content resources might not be accessible to all users, such as images for users with visual impairments or audio for those with auditory impairment. The resource can have a label, but this is not the same thing -- a textual representation of an audio file is not the name of the audio file.

The property should allow internationalized text, following the languageMap (#755) decision.

@azaroth42 azaroth42 added this to the Presentation 3.0 milestone Nov 9, 2017
@azaroth42
Copy link
Member Author

Needs a proposal, or could defer until 3.1 if there's insufficient interest?

@azaroth42 azaroth42 removed this from the Presentation 3.0 milestone Nov 17, 2017
@tomcrane
Copy link
Contributor

Is it just description?

@azaroth42
Copy link
Member Author

Now summary according to #1242. I think so? Just a case of documenting this in the definition?

@azaroth42
Copy link
Member Author

Discussion on 11/22 call:

Question: Where does this actually live? Doesn't go on the image's info.json, not per tile, nor on the canvas which could have many images or time based media.
Need to recognize that we're building an application, not a replacement for and need different solutions to just an alt text property.

No consensus as to the correct way forwards.

@anarchivist
Copy link
Member

Per comments by me and @workergnome on 22 Nov call:

  • Alt text is usually very short (~30 words or less)
  • Image description for accessibility can be longer. See, for example Art Beyond Sight and MCA Chicago's Coyote documentation
  • Image description for a11y is not necessarily the same as summary. Doing so places probably undesirable semantic constraints on summary.
  • @workergnome had some conversations with Sina Bahram (Prime Access Consulting), who worked on MCA's Coyote project; recommendation is that we treat IIIF viewers more as ARIA applications.

@jpstroop
Copy link
Member

Use case here: #1777 (comment)

Finally, a text version should be provided for screen readers so that all users are aware of the content and purpose of the image.

@jpstroop
Copy link
Member

jpstroop commented Apr 15, 2019

Some text that is more descriptive than label seems like it could go with a logo, or any other image or a/v content for that matter

@azaroth42
Copy link
Member Author

Editors agree it's important, especially with 3d that adds even more accessibility issues. Would be good to have an informed and holistic solution, perhaps via a new TSG?

@tomcrane
Copy link
Contributor

tomcrane commented Jun 7, 2024

Dropped into Slack #a11y

Editors have been discussing #1288
But needs a wider discussion. There are a set of aria-* tags that a IIIF client might expose, drawing them from IIIF properties, but what are those properties and what are the mappings?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants