Re: [whatwg] Adaptive Image Element Proposal
On Tue, 04 Sep 2012 22:53:57 +0100, Leif Halvard Silli xn--mlform-iua@målform.no wrote: If we say that picture should have img role, then we imply that alternative text should be provided via an attribute. Why? Because that is what ARIA 1.0 says about the img role: In order for elements with a role of img be perceivable, authors SHOULD provide alternative text or a label determined by the accessible name calculation. The accessible name calculation algorithm includes a clause: Otherwise, if the attributes checked in rules A and B didn't provide results, text is collected from descendant content if the current element's role allows Name From: contents. 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. 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. 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). picture --role=img--alternative/picture would be equivalent to img alt=alternative (alternative present). -- regards, Kornel
Re: [whatwg] Adaptive Image Element Proposal
On Tue, 04 Sep 2012 21:01:32 +0100, Adrian Roselli rose...@algonquinstudios.com wrote: So, how would the hyperlink in this example work for *all* users? I disagree with premise of this question. I don't think it should work for all users. If the link is in alternative content, then by definition it is intended only for users who cannot see the picture, e.g. it could be a link to longdesc-type of page that contains no useful information for sighted users. By definition the value must be an appropriate replacement for the image. It does not say it is solely for users who cannot see the picture (4.8.1.1.1). You're right, there is nothing saying solely. However, the spec also doesn't say that alt needs to be accessible when images are displayed. Currently UAs don't make it easy to see alt when images are displayed. IE used to display alt as a tooltip even when images were enabled, and this has been called out as an error and fixed. Section 4.8.1 starts with: the value of the alt attribute provides equivalent content for those who cannot process images or who have image loading disabled.. I think it's reasonable to flip this and interpret it as alt is not for those who have images enabled and process them. The link should be inaccessible to sighted users in the same way img alt=text is inaccessible. [...] There are many cases where a sighted user access @alt text. The biggest one is when the referenced file is missing. Other cases include bad/dropped connections, bad reference (404), unsupported file format, corrupt file, and a mean game of hide-and-seek. But that is not the case when image is displayed. When image is not displayed *for any reason*, then the alternative should be shown, and then the link would be accessible. -- regards, Kornel
Re: [whatwg] Adaptive Image Element Proposal
On Tue, 04 Sep 2012 21:47:15 +0100, Adrian Roselli rose...@algonquinstudios.com wrote: My point was more about @alt being solely for non-sighted users. I felt that starting off with that premise could lead to conclusions based on a faulty base. Ah, sorry. Of course instead of sighted/non-sighted I should have said when UAs display the image/when UAs don't display the image or expose alternative available to the screen reader Pedantism turned out to be useful, because when the issue is phrased this way I now see the problem: the image may be displayed and at the same time a screen reader may want to access alternative content. This makes handling of interactive content in fallback tricky, as focus required for the screen reader (needing to activate link in picture) would differ from focus required for GUI users with images displayed (never focusing picture content). The easy workaround for that may be to treat picture fallback/alt similarly to button content, i.e. just forbid focusable/interactive elements. Do any UAs allow users to access a in rendered object? -- regards, Kornel
