- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Thu, 6 Sep 2012 01:49:59 +0200
- To: Kornel Lesiński <kornel@geekhood.net>
- Cc: public-html@w3.org, whatwg <whatwg@whatwg.org>
Kornel Lesiński, Wed, 05 Sep 2012 22:29:22 +0100: > On Tue, 04 Sep 2012 22:53:57 +0100, Leif Halvard Silli wrote: > so if I understand this correctly, the <picture> element can be > defined to allow "Name From: contents", and then it will work fine as > role="img" and structured alternative content in the element. I agree that it could work the way you say. But I don't know if it should considered to be 100% equal to role=img. E.g if <picture role=img> would be treated different from <picture>, then they would not be equal. (One would expect that an explicit role=img on <picture> should have the same effect as if you apply role=img on e.g. a <div>.) Also, I doubt that one can expect the mark-up to be handled as mark-up. AT would probably only see it as "flattened" content. We are in the same "land" as we are with other hidden content ... >> You mean, treat <img>’s @alt like the <caption> of <table>, for >> instance? That is: Make it <img> a required part of the <picture> >> construct, for instance? I do think that integrating <img> into >> <picture> as a part of the picture compound element, sounds >> interesting. And it could be possible, I guess. > > Not exactly required. Simply read alternative content from element's > content. If you find <img> there, then read its alt. If you find > text, table or something else, then read that. So you want <picture>'s alternative text to be "whatever it contains". I don't rule that out. But it is not compatible with the img role - for the reasons I have outlined before, but also due to what I say below. >> One thing to think about is this: If we e.g. have a <table> which we >> declare as presentational, then we also, per the ARIA rules, declare >> the elements that are part of the <table> construct of that particular >> table (<td>, <tr> etc) as presentational. So, if <img> was seen as part >> of <picture>, then, to declare <picture> as presentational would also >> affect the <img>. > > Yes, I think it makes sense. > > <picture role=presentation></picture> would be equivalent to <img > alt=""> (presentational image). > > <picture --role=img--></picture> would be equivalent to <img> (missing alt). That's OK. And correct. But you don't mention this: <picture role=presentation><img alt="Content."></picture> According to "normal" ARIA rules, the above would be a presentational <picture> with a non-presentational <img> inside. Because, here we touch a slightly confusing aspect of ARIA 1.0. At least until one gets it: role=presentation does not mean that the content is hidden *except* if the element is one where the accessible content of the native element is provided via attributes - as is the case for <img>. So, unless we say that <img> has a *special* role in <picture> - that it is an integrated part of <picture> (same as <td> in <table>), then it does not make sense that <picture role=presentation> should have any effect on anything *except* on the <picture> element itself. But not on its children. Because, you see: For non-void elements, if you apply role=img to them, then you hide their content, while if you apply role=presentation, then you "open them up". Whereas for void elements, like <img> and (in theory at least) <area>, then it is role=presentation that closes them and the native role that opens them up. We could say that no *textual* content (and also no <img> elements with other roles than presentation) inside <picture> would make the <picture> presentational. That would be congruent with the rule that says that an <img> with empty alt is presentational. But we cannot say that role=presentation - in any by it self - should have any effect. Because we can, as I see it, not demand that role=presentation and role=img should work in a different way when applied to <picture> compared to when applied to other elements. So - knock on woods - we only have two options: Model (1): Define <picture><img></picture> as a compound element where the content by default is provided via the <img> element but where other textual content by default is ignored. An 'accessible content model' like that reminds *strongly* about role=img. In fact, it is role=img, with some twists. EXAMPLE: <picture> <img alt="I am a key content picture image. And I, the alt attribute of the img element, defines the accessible label of the picture element." /> But! Everything outside the img element, such as this text, is by default ignored by AT. </picture> Model (2): Say that <picture> defaults to role=presentation. I have to say that, in my book, what you have describes reminds about that! Keep in mind, also, that as long as a <picture> *only* contains an <img alt=foo> element, then for most intents and purposes, an AT user would not perceive any difference between model (1) and model (2). Keep in mind, as well, that if we went for model (1), then it would only take that the author manually added <picture role=presentation> to get the model (2). The really confusing thing, for model (1) would be if the author manually added <picture ROLE=IMG>, because then the AT would probably not look for alternative text in the <img> anymore. However, this could be solved by making it a conformance criteria to *not* apply role=img to <picture>. The model (1) could probably be extended with e.g. the <desc> element that Laura suggested. In other words: One could create "fields" that would be handled in predefined ways. Note that model (1) does not follow role=img in a strict sense - only in the sense that a <picture> should by default be conveyed to users as an image. I would say that the <canvas> model borders on model (2). > <picture --role=img-->alternative</picture> would be equivalent to > <img alt="alternative"> (alternative present). -- leif halvard silli
Received on Wednesday, 5 September 2012 23:50:35 UTC