A colleague who is an instructor - Chris Appert - would like to use Snap! but cannot because of a visual impairment.
Features like "Zoom Blocks" and "Flat Background" are useful in instances of this kind, but still are not enough to enable Chris to use Snap! The Fade block, which exposes the text underlying Snap! blocks raises the question of whether it might be possible to make this text accessible to screen readers such as the one described in her note below.
Thanks for any thoughts or suggestions ...
"I am unable to use Snap! ... With screen reader programs (e.g., JAWS, or MS Narrator which is built into Windows 10). It does not matter what browser I am using. The menu headers report “blank” or “untitled edit box.” Everything else just doesn’t output any speech. I am using magnification and inverted colors (so the blue motion command bars are yellow, etc)." - Chris Appert
There is nothing to read on the Snap! browser window. Everything you see on the screen is painted on a single canvas as an image. You need to OCR the image but it seems to be a bit of overkill for this purpose. For better results accessibility must be built into Snap!.
To get the desired results two problems must be overcome.
What to say?
How say it?
ad.1. What?
There are a few possibilities to convert a list of JS objects stored by Snap! in memory.
a) Heuristics: blindly scanning for objects near the cursor for any text data to be said. Required for UI elements.
b) Codification: built-in ability to convert blocks to any language
c) Export: XML format used internally by Snap!
ad.2 How?
a) by TTS engine in a browser/JS, barely configurable
b) supplying data for external accessibility engine/OS by a handcrafted HTML "speak-able" object or e.g. clipboard
It's not obvious how the TTS should be activated - in realtime with every mouse move or by a special key.
Thanks for your thoughtful comments. This is not my area of expertise ... but possibly the following note from Chris may be helpful:
"I have a lot of "Zoom" going on already and the "Fade" block may also be helpful. Not just for me but in general (like for middle school students who are blind and in regular classes). It would be good if the menus, buttons, etc. could be tagged so that Snap! works with a screen reader. There is an effort to try and interest Blind students in coding - they have even have camps specifically organized for coding and robotics. So, it is just something to consider."
scratch is a block based programming language and I have been able to use a screen reader with scratch, well, I've been able to get the screen reader to read the blocks, but not move them. I was using a braillenote touch plus.
It's on our list. Because Snap! does its own drawing of graphic elements instead of using the browser's widget management, we don't get the "for free" interface to screen readers that most web software has. It's one of the things Jens is planning to do eventually but I don't have a target date or anything like that.
But there's no reason in principle that a block language shouldn't be screen-readable.
What we do have, that I hope will be helpful, is the keyboard editor. This allows programming using the keyboard rather than drag-and-drop. See p. 115 in the Reference Manual.