I'm not sure I can parse Marc's response, but in answer to Alexis's question:
Is the community
interested in supporting accessibility by trying to make sure future RFCs
can be fully read and understood without relying on information in imagery?
my answer is yes. In the case of protocol specifcations in particular, this
was definitely overlooked in RFC 2360, but it can also apply to informative
documents, especially ones that describe complex systems.
Just to take a recent example, anyone consulting RFC 9686 using a screen
reader will not obtain an overview of the address registration mechanism
(only described by Fig. 1) and will have to guess the length of the
option-code and option-len fields (only defined by Fig. 2).
Regards
Brian Carpenter
On 14-May-25 10:41, Marc Petit-Huguenin wrote:
No.
On 5/13/25 3:00 PM, Alexis Rossi wrote:
Hello,
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.
If there is interest in this, I think the path we would take would be to
have an IETF working group attempt to address the issue.
* Background
The RSWG is currently working on replacing RFC 7996, which allowed the use
of SVGs in RFCs. (We would like to make creating SVGs easier for the
community.)
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 RSWG draft [1] that has been adopted for the replacement of 7996
currently has similar but stronger language (though softer language has
been suggested in thread), and this has lead to a discussion about
normative info in imagery:
https://mailarchive.ietf.org/arch/msg/rswg/E4eBJEmlTo5nX7ITYFvIvjKa2ec/
* Thread Discussion Summary
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.) Other than the above
text in RFC7996, this seems to be "folklore" or a generally accepted but
not documented norm. Additionally, the point has been made that 7996 is an
Informational IAB document (so does not have IETF consensus), and shouldn't
govern how the IETF uses imagery.
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.
Additionally, in discussing whether it is even possible to have all
normative information in the text, some have asserted (and others have
refuted) that some types of information may be too difficult/onerous to
represent fully in text, thus making a diagram/image the most reasonable
place for the information.
* Accessibility
ASCII art is not accessible to people using screen readers. It is read as
gobbledygook, essentially. ZSo generally there are three ways to make
imagery accessible:
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)
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.
So I think this leads me back to my goal for posting here. Is the community
interested in supporting accessibility by trying to make sure future RFCs
can be fully read and understood without relying on information in imagery?
And thank you for reading this far!
Alexis
[1] https://datatracker.ietf.org/doc/draft-editorial-rswg-svgsinrfcs/
[2] https://www.rfc-editor.org/rfc/rfc2360.html#section-3.1
_______________________________________________
rfc-interest mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
rfc-interest mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
rfc-interest mailing list -- [email protected]
To unsubscribe send an email to [email protected]
