[rfc-i] normative illustrations vs text

Iljitsch van Beijnum iljitsch at muada.com
Fri Apr 27 09:50:47 PDT 2012


I think the discussion about accessibility is muddying the waters.

I don't think it makes much sense to require some kind of alt text for every image that is a complete description of the entire image. What we do require, and should continue to require in my opinion, is a full description in text, and then images can be added to that when useful. For instance, RFC 2460 has this text:

   Version              4-bit Internet Protocol version number = 6.

   Traffic Class        8-bit traffic class field.  See section 7.

   Flow Label           20-bit flow label.  See section 6.

   Payload Length       16-bit unsigned integer.  Length of the IPv6
                        payload, i.e., the rest of the packet following
                        this IPv6 header, in octets.  (Note that any
                        extension headers [section 4] present are
                        considered part of the payload, i.e., included
                        in the length count.)

This is a complete specification of those fields in text form. It also has:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |  Next Header  |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Personally, I don't like this image of the IPv6 header. I have included two representations of the one I use, which is 64 bits wide, which can't be accomplished using the regular ASCII art representation of headers.

What would make sense to me is that the text stays the way it is, but the image can be either the ASCII art, the bitmap or the vector image as preferred by the reader. Preferably all of these are generated from some formal specification of the header, but it's easy enough to do by hand, that just requires more time for consistency checking.

Iljitsch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Untitled.pdf
Type: application/pdf
Size: 15441 bytes
Desc: not available
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20120427/2ce2aacd/attachment-0001.pdf>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: v6header.001.png
Type: image/png
Size: 28629 bytes
Desc: not available
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20120427/2ce2aacd/attachment-0001.png>
-------------- next part --------------



More information about the rfc-interest mailing list