- From: Leif Halvard Silli <lhs@malform.no>
- Date: Tue, 12 Aug 2008 00:52:09 +0200
- To: Robert J Burns <rob@robburns.com>
- CC: Smylers <Smylers@stripey.com>, "public-html@w3.org" <public-html@w3.org>
Robert J Burns 2008-08-11 21.01: > Aug 11, 2008, at 7:42 PM, Leif Halvard Silli: >> Robert J Burns 2008-08-11 13.26: > I don't think role='no-text-equivalent' was the proposed solution. The > idea was that if the role attribute was present with one or more of > several predefined values (other than 'decorative') than the non-text > media should be treated as non-decorative with either the text > equivalent displayed or if there is no text equivalent an appropriate > indication drawn from the role keywords. This gets away from the > problems with no-text-equivalent (such as the value becoming incorrect > when a subsequent author adds the text equivalent but fails to remove > the boolean attribute or value). So the @alt text keywords - AKA curly brackets/@tagged - solve a different problem that what @role solves. The former solves the problem of finding meaningful @alt text. Whereas @role does not affect the content of @alt at all. [But see my two questions regarding role="decorative" and alt="" below.] >> As for role="photo" vs. alt="{photo}, the latter is intended to be >> read by the user. Wheras @role needs interpretation by an UA before >> eventual presentation to the user. @role therefore "suffers" from a >> limited set of values, in English. Thus for @role there seems to be an >> UA localisation problem. > > To me this is another disadvantage of the curly brace proposal. It would > be far better (for internationalization/localization as well as other > reasons) to have pre-determined values that UAs could interpret than > simply place anything an author wants between braces and hope that they > do not mean the literal text within the braces (the TeX example is just > one of many possible problems). The curly brace syntax is also a problem > with existing UAs, since now the user will have to listen to endless > utterances of "open-curly-brace photo close-curly-brace'. I don't see these i18n advantages. Yes, it is clear that @role needs to be localized. But that is merely a fact, and does not have any bearing on @alt, whether @alt contains keywords or a real textual equivalent. >> Regarding @tagged [...] >> >> Ex. 1: <img src=src alt="photo" tagged > >> Ex. 2: <img src=src alt="Mum and dad." tagged="photo" > >> >> @tagged might look similar to @role. Therefore I want to describe the >> differences: It seems to me that @role speaks about the entire IMG >> element. Wheras both Ian's propoisal as well as @tagged are only meant >> to say something about how the content of @alt should be interpreted. > > However, the role attribute would imply something about the alt='' null > value. In that case the presence of role='decorative *" would strengthen > the implication that the image (or other non-text media) was purely > decorative. The absence of any role values would leave the ambiguity of > the current state for alt='' (in other words the UA would not know > whether the image was decorative or the alternative text was simply > missing). Will role="decorative" trumph the @alt text in for example <img alt="spacer" role="decorative" src="src" > ? Is the role of role="decorative" to confirm that 'I really meant to say alt=""'? >> Thus, there is nothing which prevents us from having both @role and >> @tagged simultaneously. Though it would of course be possible to have >> role="tagged" to say the same thing as the boolean variant of @tagged. > > The problem with tagged is that it is an extra attribute or value when > the same information can already be conveyed through existing attributes > and values (or with only newly proposed role values such as > 'decorative', 'photo', 'cartograph', etc.). I don't understand how we can already do, with existing attributes and values, what {} and/or @tagged can do. Please explain. Those newly proposed @role values are fine, but can still only cover some general use cases. The @alt "keywords" are as flexible as the author wish (as I see it, anyway). And needs to be, since they will be read by users. >> As long as @tagged and/or Ians curly brackets syntax only speak about >> how the content of @alt should be interpreted, then the question of >> requiring @role on all non-text media elements becomes a different >> question. (Unless, of course, we go for role=tagged.) > > Again, I think the keyword 'tagged' becomes redundant once role becomes > required. The keyword tagged is not intuitive for authors, but requiring > authors to select from among certain role values would be intuitive for > authors. The use of 'tagged' or other attributes requires a shift for > authors into an esoteric HTML syntax whereas selecting from among some > role values does not. For example, authors will have no trouble > identifying an image as a 'photograph' or a 'barchart'. However, > 'tagged' does not immediately convey to an authors what it means. Here is how I would link @role and the 'tagged' keyword: The 'tagged' keyword should only permitted together with certain of the @role attributes. It should not be permitted alone. And it should for instance not be permitted together with role="button" or role="decorative". However, with role="photograph" or if we could say role="album-photo", then 'tagged' could be added -- role="album-photo tagged" -- to indicate that the author "saved time" by only using some keywords in the @alt text. (Allthough, perhaps role="album-photo" would be enough ...) -- leif halvard silli
Received on Monday, 11 August 2008 22:53:00 UTC