Subject: Accessibility of Documents

From: Sam Hartman <[email-masked]>
Date: Tue, 10 Jan 2006 14:39:35 -0500

Hi.  I'd hoped to avoid this, but a number of people both on and
off-list have asked me to discuss the issue of accessibility of documents.
for those who may not know, I'm blind.

I try and avoid such discussions.  It is fairly clear to me that my
standards of accessibility are different than other blind peoples'.
The one time I was involved in accessibility consulting,the I was told
by the blind users that there is no way a blind person could use the
system we had designed.  So, I can speak for myself, but I will not
claim that  anyone else will agree with me.

I do find IETF specs significantly easier to read than most other
SDOs.  Much of this is the fact that RFCs are available as text.  I'd
find HTML almost as convenient.  

I think HTML would be much more accessible than PDF.  Some PDFs are
reasonably OK.  However some PDFs tend to have images instead of text
and that roughly requires printing out, scanning and then OCRing the
get information out.  (In theory you could just OCR the PDF; I have
not had as good of luck with that as I should, but a new solution I've
been working with for OCR might do much better that way.)

Some PDFs are just hard to extract text from even if they don't use
images.  I think it is a font encoding issue.  PDFs using the computer
modern fonts are notoriously bad in this regard.

I also find that IETF specs are more readable because they do tend to
focus less on figures and actually spend the time to explain what is
going on rather than depending on a picture.  

I'd like to focus on several types of possible figures and discuss
ways they could be handled.

network packet diagrams: I can get enough content out of these in
ASCII text so that I know what is in the packet and roughly what
order.  I find determining how long fields are to be challenging
without help from someone else.  I believe the accessibility of our
documents would be significantly reduced if we replaced these with
images without having an alternate representation of the information.

equations: ASCII equations are generally as easy to follow for me as
for others--which is to say sometimes not so great.  I agree that
visually appealing equations could be useful.  LaTex is easier to read
than mathml; I'm not sure how to provide both the image and the latex
in the same document.  Perhaps alt tags could be used.

Graphs: A lot of diagrams attempt to show relations between entities,
state transitions or other things that fall into the category of
mathematical graphs (sets of nodes and edges).  I can generally get
the names of nodes out of ASCII descriptions but no more.  Here's a
case where I really think the diagram should not be normative and that
you need good text to go along with the diagram.  It should be
possible to find the names of the nodes, the edges and the labels on
the edges by reading the text.  In general if you are doing a good job
of explaining your protocol you'll want this in your text anyway.  The
one case where this might not be true is state transition diagrams: if
you don't manage to explain why your state machine works the way it
does, then you might not have any reason to describe the states in the
text.  My opinion as an IESG member and document reviewer is that it's
worth it to explain the reasoning behind your states.  That gives you
an excuse to have your text be complete and makes your document much
easier to review.

function graphs: Another class of diagram would be a graph of some
function.  I'm likely to get nothing out of the diagram in ASCII.
Here, if I really cared, I actually could do something with an image;
there are ways to print the image in such a way that I could at least
look at the shape of the function.  It is useful to describe the
variables and the domain and range of the function.  It is useful if
the text describes the basic conclusion of the graph.  "As you can
see, the performance of this protocol is exponential in the number of
participants in the session.  We recommend against large sessions."

pictures: I guess someone might want to include a photo or other
picture in an IETF spec.  I'd kind of like to know why.  Be sure to
explain what the point of the photo is in the text.

--Sam

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 10 Jan 2006 16:58:19 -0600

Hi, Sam,

Thank you for taking the time to explain this stuff to us. It is very 
helpful.

> explain what the point of the photo is in the text.

In RFC 2397, "The "data" URL scheme", the following URL appears:

   <IMG
   SRC="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw
   AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz
   ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp
   a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl
   ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis
   F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH
   hhx4dbgYKAAA7"
   ALT="Larry">

If you cut-and-paste this text into an HTML document and view it with a 
browser that supports RFC 2397 (last I looked, Netscape and Mozilla did and 
IE did not, but that's been a while), you see either a black-and-white GIF 
of Larry Masinter that's about the size of your thumbnail, or "Larry" as the 
ALT text.

That's not quite "putting a picture in an RFC", but it's close :-)

I'm also thinking that if an RFC is bad enough, having pictures of 
authors/editors might make it easier to recognize the guilty parties and 
organize a lynch mob, and that might do more to improve our quality than 
anything since Kobe...

Have a great day,

Spencer

---

From: John C Klensin <[email-masked]>
Date: Tue, 10 Jan 2006 19:28:39 -0500

--On Tuesday, 10 January, 2006 16:58 -0600 Spencer Dawkins
<[email-masked]> wrote:

>...
> I'm also thinking that if an RFC is bad enough, having
> pictures of authors/editors might make it easier to recognize
> the guilty parties and organize a lynch mob, and that might do
> more to improve our quality than anything since Kobe...

As an occasional fan of lynch mobs in the service of rough
consensus, I believe your objective would be better accomplished
by a photo gallery of recent RFC authors and editors, WG chairs,
and IESG and IAB members rather than making RFCs longer and more
bulky.  

You might suggest this to the IAOC; I am fairly certain they
would give it the appropriate priority :-)

    john

---

From: "Lucy E. Lynch" <[email-masked]>
Date: Tue, 10 Jan 2006 16:43:08 -0800 (PST)

> would give it the appropriate priority :-)

Gents,

watch how you use the word "lynch" please. As the oldest of six
I'm a bit *sensitive* to mob comments. ;-)

Lucy E. Lynch                           Academic User Services
Computing Center                        University of Oregon
llynch  @darkwing.uoregon.edu           (541) 346-1774

---

From: Dave Crocker <[email-masked]>
Date: Tue, 10 Jan 2006 17:47:02 -0800

> I'm a bit *sensitive* to mob comments. ;-)

Lucy, I suspect that they merely were making a spelling error, since I'm sure 
they were referring to folk who are truly essential, and therefore qualify as 
linch pins...

d/

ps.  As one who constantly wishes people would find a different dismissive label 
than "crock" I do, however, share your sensitivity.

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 10 Jan 2006 23:16:04 -0600

Dear Dave and Lucy,

> Lucy, I suspect that they merely were making a spelling error, since I'm 
> sure they were referring to folk who are truly essential, and therefore 
> qualify as linch pins...
>
> d/
>
> ps.  As one who constantly wishes people would find a different dismissive 
> label than "crock" I do, however, share your sensitivity.

My sincerest ("chuckle, snort!") apologies :-)

It is difficult to come up with useful terms that clearly describe a 
barely-controlled riot ... I thought the reference to July14 in the name of 
the draft that became RFC 3933 was very witty, but so few people caught the 
reference to Bastille Day that I finally decided it was only half-witty.

I guess, based on the IETF's previous experience, I should be using "Kobe" 
as a verb?

Thanks,

Spencer

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Jan 2006 13:49:05 -0800

On Jan 10, 2006, at 5:47 PM, Dave Crocker wrote:
>
> Lucy, I suspect that they merely were making a spelling error,  
> since I'm sure they were referring to folk who are truly essential,  
> and therefore qualify as linch pins...

I have never heard of a linching party.  RFCs filled with base64  
encoded images may invite an en masse response however.. : )

-Doug