DrRacket Is Inaccessible with Screenreaders

[ghost]

Hello,

I have tried running DrRacket on a Windows and Linux box with the NVDA and Orca screenreaders, respectively, and I am noticing some accessibility issues that need some addressing. Under Linux, the only parts of the DrRacket interface that are accessible are the menu bars and the preference dialogs; as for the main interface, I hear only the phrase "drawing area". On Windows, I wasn't able to get the interface to speak at all with NVDA; I will do further testing tomorrow to see if I missed a step when trying to get the interface working. Sorry I cannot be more informative than that; I am just starting my Racket adventure so haven't delved too deeply in to the code, but I hope this issue can be resolved.

Additionally, I spoke on Slack about this problem, and I heard that there is work done in this area; is this available for testing as of yet? If so, which branch should I track and what steps are necessary to get it working?

Thanks,

Hunter

[SamKacer]

Hello, I am also a screen reader user interested in Racket. Trying out Dr Racket on windows 10 with NVDA screen reader, the main interface seems to be completely opaque.

The menu bar (file, edit, etc.) and its submenus and menu items are all accessible by the screen reader, but the main content of the window dont communicate any information to the screen readr at all, making it completely unusable.

I tried opening up a couple dialogues like package manager and they have the same issue.

I suspect the UI is built with a GUI toolkit that didnt implement communication with the accessibility API.

I should still be able to get into things since there are commandline tools for compiling/interpreting, formatting, and package management, but fortunately I am not a beginner programmer, so having to use that isn't a barrier for me. However I imagine a visually impaired kid in middle school would have trouble with that and would really benefit from having access to an IDE that simplifies a lot of things.

I see last comment on this is from 2 years ago and no reply from devs. Is supporting people who rely on assisstive technology something the racket devs care about? Are there any plans to fix this?

[rfindler]

I think this is something that would be great to have, but I'm not in a position to work on it myself.

[FelixGruetzmacher]

I'm a blind software developer and I teach C and C++ programming on a regular basis. I'd love to do a class based on Racket and the PLT content but I also find the IDE inaccessible to my screen readers. While I do have the resources to conduct the teaching, I am currently lacking the capacity to do any substantial portion of the work required to provide for accessibility. I am offering, however, my guidance and testing. The lack of resonance to this issue seems to indicate that accessibility is not currently among the core priorities of this project. If this is so then I shall not disturb anyone here but simply point out to interested parties that accessibility is to be searched elsewhere. If, on the other hand, there is interest, however, I am there to help.

[rfindler]

If someone is interested to work on this, I am guessing that the basic problem is that the editor is implemented by directly drawing characters on the screen, not by using some OS-provided editor. I'm not really familiar with the way screen readers work, but this code is probably a lot like how things look to the OS:

#lang racket/gui

(define words-in-lines
  '(("Hello" " " "W" "or" "ld")
    ("How are you?")))

(define (draw c dc)
  (for/fold ([y 0])
            ([line (in-list words-in-lines)])
    (define-values (x h)
      (for/fold ([x 0][h 0])
                ([word (in-list line)])
        (define-values (tw th td ta) (send dc get-text-extent word))
        (send dc draw-text word x y)
        (values (+ x tw) (max h th))))
    (+ y h)))

(define f (new frame% [width 400] [height 400] [label ""]))
(define c (new canvas% [parent f] [paint-callback draw]))
(send f show #t)

So probably something somewhere needs to tell the screen reader what the text is? The editor code is here and the code that is actually doing the drawing is here.

[soegaard]

@FelixGruetzmacher

In the short term I think racket-mode in Emacs might be a solution.

But perhaps @LeifAndersen knows about an alternative screen reader that can be used with DrRacket?

[rfindler]

Oh, right! I meant to suggest using @greghendershott 's emacs mode (or maybe the VS Code extension).

[LiberalArtist]

This blog post describes how GTK 4 has redesigned its accessibility APIs around concepts from ARIA (Accessible Rich Internet Applications, the HTML properties etc. used to provide information for screen readers and other assistive technologies). Here's the documentation for the resulting GtkAccessible interface in GTK 4.

It inspired me to do some more digging, and I found the W3C publication Core Accessibility API Mappings 1.2, which has extensive tables mapping ARIA semantics to the platform-native accessibility APIs. For example, the ARIA role tooltip maps to:

MSAA + IAccessible2

Role: ROLE_SYSTEM_TOOLTIP

UIA

Control Type: ToolTip

ATK/AT-SPI

Role: ROLE_TOOL_TIP

AX API

AXRole: AXGroup
AXSubrole: AXUserInterfaceTooltip

The fact that people have already figured out the translation across platforms seems like a big help!

I think racket/snip would need to add support for exposing accessibility information, with string-snip% as an important special case, and racket/gui would need to consume that information and provide it to the platform-native APIs. Maybe canvas<%> or canvas% should also get methods for accessibility outside of the snip/editor context.

I think this is a very important issue, but I don't know when I'd have time to devote to it personally, and I don't have any experience with the platform-native accessibility APIs.

[abletec]

VS code seems to work on Windows, though having thus said, I'm just a newby getting started so what do I know?

Another solution might be to just use the command line, always remembering to put # lang racket or whatever at the top of the file & running racket -filename from the cli. No debugger though, which is a pita-&-a-half.

Using NVDA here, but I suspect results would be identical in any other screen reader.

The 2 major problems are that the caret isn't visible, and often the characters are graphical rather than represented as plain text.

If Racket & its ilk are to be used in educational institutions, though, it seems fair to request that accessibility be implemented in the IDE. Although the cli & VS Code are workarounds, the problem is that blind students would then not be using the same tools as their classmates, and that can make the learning (& teaching) process a lot harder.

If I'm able to make headway w/Racket, I'll put up a tutorial for screen reader users.

Thank you Philip for replying. Jackie McBride

[LiberalArtist]

Another possible direction to explore is AccessKit, which can be used as a foreign library (it's Rust with a C API). It offers a cross-platform abstraction over communicating accessibility information to platform-specific backends.

Ideally we'd communicate with the platform APIs directly from Racket, as we do for other parts of racket/gui, rather than take on a foreign library. However, if AccessKit were to make accessibility easier to implement (I don't know), I think it's worth considering. In particular, it seems like we could probably swap out AccessKit for native implementations later without changing the API exposed to Racket programmers.

[racket-discourse-github-bot]

This issue has been mentioned on Racket Discourse. There might be relevant details there:

https://racket.discourse.group/t/scope-and-purpose-of-racket-gui/2965/17