W3C home > Mailing lists > Public > public-html@w3.org > March 2010

Re: ISSUE-90 background documentation on allowing any flow content in figure

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 22 Mar 2010 17:17:11 -0700
Cc: Edward O'Connor <hober0@gmail.com>, HTMLWG WG <public-html@w3.org>
Message-id: <CB2DBD20-DF00-4916-A129-B50908005B91@apple.com>
To: Shelley Powers <shelley.just@gmail.com>

On Mar 22, 2010, at 5:02 PM, Shelley Powers wrote:

> But then, there isn't fallback for the reader to understand what the
> heck is going on.

I'm not sure what you mean. In Safari on Mac, when the VoiceOver  
cursor is on the <pre> element, VoiceOver speaks "ASCII art of a  
butterfly; image". That seems exactly right to me. VoiceOver is fully  
aware that the pre element is an image and treats it as such. I  
believe the results will be similar in any browser + screen reader  
combo that correctly supports ARIA.

(For anyone who doesn't feel like doing View Source, I used <pre  
role="img" aria-labeledby="caption">, with a later element that has  
id="caption" which is precisely what ARIA recommends for cases like  
this. If I chose to, I could also hide the text equivalent from visual  
media but it seemed better not to.)

> I don't want to debate my change proposal before I submit it, but I
> think a screen shot of the ASCII art, such as the following provides
> the art without the gibberish. And a person can always link the ascii
> art, if for some reason it's absolutely essential to include all the
> characters. Or they don't have to use figure.
> http://burningbird.net/graphics/ascii.jpg

I don't see how an <img> element pointing to that JPEG would lead to a  
superior accessibility experience to what I posted. If your Change  
Proposal argues that it does, then I believe it will be making a false  

At the same time, linking a JPEG has some downsides:

- It won't work in text-only browsers.
- It can't be copied and pasted into a plain text file.
- It consumes more bandwidth.
- It's more work for the content author if they already have the ASCII  
art in ASCII form.
- It gives worse results for users with partially impaired vision when  
applying full-page zoom.
- It can't take advantage of sub-pixel antialiasing settings  
appropriate to the display.

It could be argued that these are relatively minor downsides, but I  
don't see why anyone would want to incur them for literally zero  
benefit. And I certainly do not think the spec should recommend such  
an approach.

(It's true that you could use <pre role="img"> outside <figure>, but  
they could also use <img> outside <figure>, so that argument by itself  
doesn't make the case for anything.)

Received on Tuesday, 23 March 2010 00:17:44 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:59 UTC