Re: [Rswg] SVG/ASCII art and accesibility (was: Re: Fwd: I-D Action: draft-carpenter-rswg-rfc7996-issues-00.txt)

Jean Mahoney <jmahoney@amsl.com> Fri, 07 October 2022 21:56 UTC

Return-Path: <jmahoney@amsl.com>
X-Original-To: rswg@ietfa.amsl.com
Delivered-To: rswg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49311C14F734; Fri, 7 Oct 2022 14:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkF0Agmwtncm; Fri, 7 Oct 2022 14:55:59 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F07B3C14F74E; Fri, 7 Oct 2022 14:55:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id CC69C425A375; Fri, 7 Oct 2022 14:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aALH_mZL7E61; Fri, 7 Oct 2022 14:55:58 -0700 (PDT)
Received: from [192.168.1.203] (unknown [47.186.48.51]) by c8a.amsl.com (Postfix) with ESMTPSA id 751E3425977A; Fri, 7 Oct 2022 14:55:58 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------508g3EAQT7Hi63OeZIvxgbf9"
Message-ID: <bf3a6631-494f-fa95-e2e1-37d084c2abbb@amsl.com>
Date: Fri, 07 Oct 2022 16:55:57 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.3.2
Content-Language: en-US
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Alexis Rossi <rsce@rfc-editor.org>
Cc: exec-director@ietf.org, rswg@rfc-editor.org
References: <20220922183747.5EC6A4AE593E@ary.qy> <2691aee2-9e47-d8a0-d13a-559e410d2be7@it.aoyama.ac.jp> <90d3bb18-46f5-70a9-31ae-332f929bf432@gmail.com> <155f037f-e61a-c338-5369-2448735d55e4@it.aoyama.ac.jp> <7D5C2144-A7C4-4719-A42E-0181E4171066@rfc-editor.org> <b98713f4-a068-8c85-64c2-0008d5e838f9@it.aoyama.ac.jp> <30FCA904-7993-45C7-B9E2-DC025F5DBA12@rfc-editor.org> <fdb7ab37-895f-076c-e48b-895571fe3f91@it.aoyama.ac.jp>
From: Jean Mahoney <jmahoney@amsl.com>
In-Reply-To: <fdb7ab37-895f-076c-e48b-895571fe3f91@it.aoyama.ac.jp>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rswg/IofDazzTlGXUNgyBRPXDzrb8bj8>
Subject: Re: [Rswg] SVG/ASCII art and accesibility (was: Re: Fwd: I-D Action: draft-carpenter-rswg-rfc7996-issues-00.txt)
X-BeenThere: rswg@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RFC Series Working Group \(RSWG\)" <rswg.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/rswg>, <mailto:rswg-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rswg/>
List-Post: <mailto:rswg@rfc-editor.org>
List-Help: <mailto:rswg-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/rswg>, <mailto:rswg-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Oct 2022 21:56:03 -0000

Hi all,

On 10/5/22 4:32 AM, Martin J. Dürst wrote:
> Hello Alexis,
>
> (cutting previous exchanges down a bit)
>
> On 2022-10-04 07:16, Alexis Rossi wrote:
>> replies inline
>>
>>> On Oct 3, 2022, at 12:08 AM, Martin J. Dürst 
>>> <duerst@it.aoyama.ac.jp> wrote:
>>>
>>> Hello Alexis, others,
>>>
>>> Sorry to be late with my reply.
>>>
>>> On 2022-09-28 05:02, Alexis Rossi wrote:
>>>> It seems like we are not regularly using <title> and <desc> within 
>>>> the <svg> element to provide accessible information about the art. 
>>>> (At least, none of the several examples I found of svgs had them.)  
>>>> The author guidance on https://authors.ietf.org/en/diagrams doesn’t 
>>>> specify their use, though the example provided does include <title>.
>>>
>>> If this is the case, then I think we need to improve it. We should 
>>> clearly tell authors to use <title> and <desc> in <svg>s, and the 
>>> RPC should check that they are there and have appropriate content, 
>>> and if not should get back to the authors and make sure this gets 
>>> fixed. If this needs an update of policy, then the WG should 
>>> prioritize it because it's an obvious accessibility oversight.
>>>
>>
>> I agree, if we don’t currently have policy in place to require 
>> descriptive elements for artwork then we should make sure this is 
>> created.
>
> Great.
>
>>>> I had a heck of a time trying to find any guidance on this as a 
>>>> newbie, but Alice Russo helpfully pointed out (thank you!) that 
>>>> rfc7992 section 9.5.2 [1] says, "Note: the "alt" attribute of 
>>>> <artwork> is not currently used for SVG; instead, the <title> and 
>>>> <desc> tags are used in the SVG."
>
>> Yes, I agree that using <figcaption> for the content that belongs in 
>> the SVG’s <desc> is a bad idea. I wonder if repeating the content of 
>> <figcaption> in the SVG’s <title> element would be annoying for those 
>> using screen readers? I am guessing it would be better to repeat it, 
>> given the order of the tags. (I am not suggesting getting rid of 
>> <figcaption>, as that is useful for people reading the text on the 
>> screen.)
>
> A agree that we need <figcaption>, because it's the way most 
> publications work: Figures have captions.
>
> With respect to SVG's <title> and <desc>, I guess it could be a 
> case-by-case decision. I can imagine many cases where <title> is much 
> shorter than <figcaption>, but various <desc>s inside the SVG are 
> (together) much more detailed than <figcaption>.
>
>
>> If we do move forward with having the WG write policy on this, I 
>> think part of the process needs to be getting some independent 
>> input/review from people with visual disabilities, for sure.
>
> At this point in time, it's not yet very clear how far into details 
> "WG policy" will go. My guess is that we need to work out some actual 
> examples (such as this one) to get a feel for it. [I really hope we 
> will get some guidance from our WG chair(s) soon.]
>
> I could imagine the "WG policy" to be as short as "The RPC ensures 
> that RFC authors/editors provide the necessary alt/title/desc text to 
> make sure that visually challenged readers do not miss any information 
> provided in (ASCII or SVG) diagrams." (or something similar)
>
> I can also imagine the "WG policy" to provide pointers to 
> relevant/related guidelines such as those provided by W3C.
>
> I can also imagine the "WG policy" to mention specific elements and 
> attributes and how to use them, or even to create new elements or 
> attributes in xml2rfc (although currently I think the need for the 
> later is probably zero).
>
> [I can also imagine the RPC saying "we might have had a better look at 
> SVG <title> and <desc> elements so that they cover accessibility 
> needs; we'll add this to our internal checklist" and thus avoid the 
> need for "WG policy".]

[JM] Repeating here the comment that I've added to issue #20 
(https://github.com/rfcseries-wg/new-topics/issues/20):

The RPC is updating its procedure for checking artwork to include 
reviewing the contents of the SVG |<desc>| and |<title>| elements and 
the |<artwork alt=""/>| attribute (when xml2rfc supports it. Issue 
opened: ietf-tools/xml2rfc#898 
<https://github.com/ietf-tools/xml2rfc/issues/898>). If the artwork 
lacks an accessible description, during AUTH48 the editor will ask the 
authors to please provide text. We will also update the Online Portion 
of the Style Guide to recommend to authors that they provide descriptive 
text for artwork. rfc7322bis 
<https://datatracker.ietf.org/doc/html/draft-flanagan-7322bis-07#section-3.7> 
already captures a recommendation regarding artwork accessibility.

Best regards,
Jean Mahoney
RPC Project Manager


>
> In all cases, input from people with visual disabilities will be 
> appreciated, but the need will be higher the more we move down the 
> above list into adding details. Also, input from disability experts 
> (maybe, but not necessarily, the same people) will be very valuable.
>
> Regards,   Martin.
>
> P.S.: I volunteer to write a draft of "WG policy" if asked by the 
> chairs or if otherwise there's an (emerging, maybe not yet firmly 
> established) consensus that such a document is a good way to move 
> forward.
>
>>>> Alexis
>>>> [1] https://www.rfc-editor.org/rfc/rfc7992.html#section-9.5.2
>>>>> On Sep 25, 2022, at 5:35 PM, Martin J. Dürst 
>>>>> <duerst@it.aoyama.ac.jp> wrote:
>>>>>
>>>>> Hello Brian, others,
>>>>>
>>>>> On 2022-09-23 13:23, Brian E Carpenter wrote:
>>>>>> On 23-Sep-22 14:32, Martin J. Dürst wrote:
>>>>>>> [tweaked title]
>>>>>>> I'd say that "would be useful" is a strong understatement. 
>>>>>>> Providing
>>>>>>> alternative text for images and diagrams is about the first item 
>>>>>>> in the
>>>>>>> 101 of accessibility (see e.g.
>>>>>>> https://www.w3.org/TR/WCAG10/#gl-provide-equivalents). From the 
>>>>>>> 1990es,
>>>>>>> that meant 'alt' attributes on <img> elements. For SVG, it means 
>>>>>>> <title>
>>>>>>> and <desc> elements (see 
>>>>>>> https://www.w3.org/TR/SVG-access/#Equivalent).
>>>>>>>
>>>>>>> I just took a sample of 1, looking for "<svg>" in my download of 
>>>>>>> RFCs,
>>>>>>> and ending up with RFC 8989 (sorry, Brian).
>