This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Add a typeof attribute (this could also be done using the role attribute) to the <img> element that allows a space seperated list of keywords (defined in the spec or in a register referenced by the spec) to indicate what type of image it is example: <img typeof="chart"> <img typeof="photograph chart"> <img typeof="photograph painting"> This information could then be used by browsers and AT to inform users about image type.
Why is @alt insufficient for this task? With @alt you can express the type of the image when appropriate *and* more information as well. Further, I don't understand the semantics of multiple keywords in your proposal. Take "photograph painting". Is it a photograph of a painting? A painting of a photograph? A painting and a photograph together in one image?
(In reply to comment #1) > Why is @alt insufficient for this task? With @alt you can express the type of > the image when appropriate *and* more information as well. > Further, I don't understand the semantics of multiple keywords in your > proposal. Take "photograph painting". Is it a photograph of a painting? A > painting of a photograph? A painting and a photograph together in one image? you can't use alt to provide an unambiguous categorisation of an image content type can you? alt allows any words/numbers etc what i have suggested only allows predefined kyewords. the idea behind allowing multiple keywords is authors to specify with more granularity the img content so "photograph painting" indicates its a photgraph of a painting. the order of the keywords indicates specificity.
Why is "unambiguous categorization" necessary? It seems that a user should be able to quickly ascertain from the alt text what the image is of when that categorization is important. It also seems that knowing something is a chart or a photograph of a painting doesn't really help me know whether or not I want to listen to the alt text.
(In reply to comment #3) > Why is "unambiguous categorization" necessary? It seems that a user should be > able to quickly ascertain from the alt text what the image is of when that > categorization is important. It also seems that knowing something is a chart > or a photograph of a painting doesn't really help me know whether or not I want > to listen to the alt text. it has nothing to do with wheter they listen to the alt text or not. one of the issues that concerns the html editor is that the role of the <img> element is available to assistive technology via accessibility APIs he has stated that browsers should not map the <img> element to a 'graphic' role in accessibility APIs, because in his view that role should not be conveyed to AT users. Providing a categorization of images could resolve this issue. for example: <img alt="poot" typeof="text"> this keyword could be used to indicate that the image contains only text. so an accessibility API could provide the follwoing info: name="poot" role="graphic" typeof="text" graphical rowser could use this info (when images are turned off) to replace the img with text without an indication of an image. AT could offer the user a preference to announce role information only on images of typeof x, y, z and not on images of typeof="text"
I haven't examined the proposal in detail yet, but before I do: do we have experimental implementations or any implementors committed to supporting this? At this stage I'd really rather not add new features without a clear commitment from user agent implementors, given how close we are to LC.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: Before we add new features we should make sure that we have implementor interest. I presume ATs are the target implementation class here; can we get confirmation from AT vendors that they are interested in implementing this feature?
The bug-triage sub team doesn't believe this should be Accessibility TF priority, the bug is in good hands with Steve.
i raised it and will close as i do not wish to pursue