No to making anything but English sentences normative. People can add all the examples, diagram, images, and alt tags they want in an RFC, I am going to ignore all of them and complain loudly that the protocol cannot be implemented.
On 5/13/25 4:24 PM, Brian E Carpenter wrote: > 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] -- Marc Petit-Huguenin Email: [email protected] Blog: https://medium.com/@petithug Profile: https://www.linkedin.com/in/petithug
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ rfc-interest mailing list -- [email protected] To unsubscribe send an email to [email protected]
