Accessibility of Documents

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]