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

On Mon, Mar 22, 2010 at 7:17 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> 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 claim.
>
> 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.)
>

The irony of this discussion is the following message is associated
with the pre element:

"Authors are encouraged to consider how preformatted text will be
experienced when the formatting is lost, as will be the case for users
of speech synthesizers, braille displays, and the like. For cases like
ASCII art, it is likely that an alternative presentation, such as a
textual description, would be more universally accessible to the
readers of the document."

So the pre element recommends using a text description (in addition or
in place of, I'm not sure), while the figure element would recommend
using pre for ASCII art.

That is the type of inconsistency we should be avoiding.

Shelley

> Regards,
> Maciej
>
>

Received on Tuesday, 23 March 2010 00:40:28 UTC