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

[Jean Mahoney <[e-mail]>]

Hi Martin,

On 10/10/22 3:14 AM, Martin J. Dürst wrote:
> Hello Jean, Alexis, Brian,
>
> On 2022-10-09 01:21, Jean Mahoney wrote:
>> Hi Brian,
>>
>> On 10/7/22 6:17 PM, Brian E Carpenter wrote:
>>> Jean,
>>>
>>> On 08-Oct-22 10:55, Jean Mahoney wrote:
>>>
>>> <snip>
>>>
>>>> [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.
>
> Many thanks for this; I think this is the best way to proceed because 
> it has the lowest overhead.
>
>>> That's excellent, of course. But I still lack
>>>
>>> a) any drawing tool for SVG that supports <desc>;
>> [JM] Ack. I've manually inserted <desc> into SVG embedded in RFCXML, 
>> and it works (that is, the contents appear in the HTML output), but 
>> it would be good to identify drawing tools that support <desc>.
>
> Just a sample of one:
> Inkscape would do that, under Object -> Object Properties -> 
> Description. But then, Inkscape doesn't produce clean SVG.
>
> Personally, I'd probably go with just adding the <desc>s by hand in 
> the markup, which to me looks faster than selecting submenus over and 
> over. But I understand that may not be for everybody.
>
>>> b) any simple way of testing whether a <desc> or <artwork alt=""/> 
>>> actually works with a screen reader in the html rendering;
>> [JM] I'm also looking for a good screen reader or browser plugin to 
>> test these things. Anyone have suggestions?
>
> As far as I'm aware, for English at least, the commercial option for 
> Windows is JAWS 
> (https://www.freedomscientific.com/products/software/jaws/). On 
> Windows, there is also a built-in screen reader called Narrator. The 
> open source screen reader for Windows most widely used is NVDA. Mac 
> has VoiceOver built in. For Android, it's TalkBack.
[JM] Thanks for this info. I have started learning VoiceOver.

>
> There are two problems to be aware of:
> 1) Screen readers can be expensive for the occasional try, because 
> it's a small market and those who really need a screen reader (or 
> their companies) are ready to pay a decent price.
> 2) Screen readers have a very steep learning curve. Interaction mostly 
> happens with a large number of Ctrl/Alt/Fn/... key combinations. The 
> default settings may not be the ones you prefer, and you may not know 
> which settings you would prefer, anyway. A screen reader may start to 
> talk, and be difficult to stop, or may stop, and be difficult to start 
> again. It may be best to use two computers, one with the manual and 
> another with the screen reader, because otherwise, the screen reader 
> will start to read the manual whenever you want to check something in 
> the manual.

[JM] I agree with 2). I don't know if my manual modifications of SVG are 
still incomplete, or if I'm missing something with VoiceOver navigation, 
but I'm not able yet to get VoiceOver to read the <desc> content.

>
> https://weboverhauls.github.io/demos/svg/ shows tests for some 
> relevant combinations of SVG elements, ARIA attributes, browsers, and 
> screen readers, although it is quite a bit outdated.
>
>>> c) a good example of a well annotated diagram in 
>>> xml2rfcv3-conforming xml.
>> [JM] And this would be good to capture on authors.ietf.org. I've 
>> added a comment to Issue #42 
>> (https://github.com/ietf/authors.ietf.org/issues/42).
>
> I suggest we start with the diagram in Brian's RFC for which I wrote 
> some descriptive text (which may need some further tweaks). The 
> problem with that is that the text isn't in the actual published RFC.

[JM] We can create a completely fictional example that demonstrates how 
SVG <title> and <desc> elements are supposed to look and then replace it 
when we have a published example. We will need to update the example 
anyway when the <artwork> alt attribute works.

>
> Another idea is to wait for the next RFC to be published that includes 
> a diagram (maybe there are one or more already in the pipeline).

[JM]  When I looked through the queue for a candidate with SVG artwork, 
I realized that asking the authors to provide detailed descriptions of 
artwork during AUTH48 would probably be a surprise and a burden to the 
authors. The candidate document I found in the queue has 14 SVG diagrams.

Perhaps the order of plan should be:

   1.  The Tools Team and RPC will ensure that the alt text is available 
in the output and can be read by at least one screen reader.

   2.  The RPC will improve the information on authors.ietf.org with a 
good, mocked-up examples and add guidance to the Online Portion of the 
Style Guide.

   3.  The RPC will announce to the community the details of how to 
support accessibility within documents, with links to authors.ietf.org 
and the Style Guide.

   4.  Then the RPC will ask authors to provide descriptive text if such 
text is missing.

   5.  The RPC will update the examples on authors.ietf.org with 
published examples.



> The tests linked to above also shows we might need to check out some 
> parts of ARIA.
>
> We may definitely need to reach out to screen reader users and 
> accessibility experts. I can try to help with contacting somebody at W3C.
[JM] Thank you! I've also reached out to a resource in our local school 
system who supports teachers of visually impaired students and who is 
familiar with multiple screen readers.

Best regards,

Jean

>
> Regards,   Martin.
>
>> Thanks!
>> Jean
>>
>>>
>>> The third one is probably the most important of all.
>>>
>>> Regards
>>>     Brian
>>>
>>>
>