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.)
>
> Regards,
> Maciej
>
>

I don't know if it's worthwhile to account for _every_ use case. Yes
we could allow the pre element and it can include ASCII art, but then
we have to also explain that it can't contain anything else, because a
figure is an image...but then people will say, "Well, since it's a
pre, why can't it also contain a poem", and next thing you know, we're
back to what we have now, which is basically allow anything in Figure
and figure is semantically meaningless.

Restricting the content to embedded content, only, is clean,
efficient, and importantly, not confusing--all due apologies to the
ASCII art aficionados. We don't run into the problems with the fact
that the pre element can have such and such content when used in the
page...EXCEPT when its within a figure element. My change proposal was
to clean up the element, tighten its focus -- not add on yet more
interesting little quirks.

Regardless, people can write alternative change proposals, or propose
changes to the one I'll submit.

Shelley


Shelley

Received on Tuesday, 23 March 2010 00:33:04 UTC