Alexis Rossi <[email protected]> wrote:
    > This is a long one, so let me state my goal up front. I am trying to
    > ascertain whether there is community interest in trying to make sure 
future
    > RFCs can be fully read and understood without relying on information in
    > imagery (SVG or ASCII). This is an accessibility issue, but I think it 
also
    > may be helpful for people who learn in different ways. We are not talking
    > about trying to address this in older RFCs, just new ones.

Fair enough.
Older RFCs do get revised, and re-working those sections could be painful.

    > RFC 7996 contains the following language in the introduction:

    > "Note that in RFCs, the text provides normative descriptions of protocols,
    > systems, etc. Diagrams may be used to help explain concepts more clearly,
    > but they provide supporting details and should not be considered to be
    > complete specifications in themselves."

The language is not strong enough, and is probably not well enough understood.

    > Some people think that we already have the general idea in the community
    > that the text should be normative, and that imagery should be a helpful
    > illustration of the text. (So you could have normative info in an image,
    > but that shouldn't be the ONLY place where it exists.)

By "normative" do you mean BCP14, or just that it defines things?

    > Others have made the point that this has never been an accepted norm for
    > ASCII art. We haven't found a citation that says otherwise (other than
    > 7996). And it seems that in regards to packet diagrams specifically, BCP
    > 22/RFC2360 Section 3.1 [2] actually tells us to put normative info into
    > ASCII art.

I think that it's time to move to machine readable descriptions of packet
formats, and to derive diagrams from that.  We had a document go through
dispatch a few years ago that was mentioned, but I can't find it right now.
25 years ago, I proposed a declarative language for packet formats, but at
the time, it's applicability to documents was not understood.

    > 1) provide adequate alt/desc text within the code to fully describe the
    > content of a diagram/image to someone using a screen reader (SVG only)

    > 2) use aria labels appropriately to allow a screenreader user to navigate
    > the diagram (SVG only)

    > 3) fully describe the normative information in the text (TXT has all the
    > info needed outside of the ASCII art, and SVG points people to the
    > text)

Yes, but can we also provide a useful label in txt?
What about in PDF?

    > A fourth path has been suggested: using a formal language to describe
    > diagrams. UML was suggested as a possibility. I have not yet found
    > convincing evidence that UML alone is sufficiently accessible to people
    > with visual disabilities.

UML is useless to me.
Too complicated, does many things I don't need, fails to do things I do need.
(I've tried multiple times over 30 years)




--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*



Attachment: signature.asc
Description: PGP signature

_______________________________________________
rfc-interest mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to