The thing is, that's not up to us. People who use screen readers have a screen reader they're comfortable with, and they expect other software to play nice with it.
Alas, this is an area in which Jens's use of Morphic rather than ordinary DOM widget management works against us. DOM-based software interfaces more or less automatically with screen readers, and browsers have to work hard to make that true. One idea about how we'll get a screen reader interface is to keep two copies of the Snap! world, one in Morphic and one in DOM, with the latter used only for screen reading. (Why not just use the DOM altogether? Because the "lively" interactivity of Snap! depends subtly on things like being able to interact with widgets that are under the mouse but not in the topmost layer under the mouse. Jens could explain this much better than I.)
Warms my heart! I confess, I re-read it, too; sometimes when we're caught up in arguments over metaprogramming or something, I need to remind myself what an amazing achievement Snap! was in the first place. :~) :blush:
Yeah, one of my many failures is not having produced a more tutorial introduction to the Snap! UI.
I dunno, in a text language, even though you can see the internal definitions, your program can't, and that's the whole virtue of them. You're not supposed to be thinking about the internal helper functions of a procedure other than the one you're studying right now. So hiding those helper blocks will, I think, promote their use rather than discouraging it. But, time will tell. :~)
I don't really understand what you mean. We get those on the forum too. Comments on project pages are just like threads in "share your projects," no?
:~)
This is funny, but Jens will hate that characterization of Snap!. :~)
It's not trivial; there's a lot of design to be done about the UI for creating a helper, and whether there will be a mini-palette inside the block editor to access the helpers. (That isn't strictly necessary since these days you can drag a copy of a block out of its prototype hat block, but in a block editor window that has enough in it to have to scroll, which is likely the case for blocks with helpers, you'd rather not have to scroll back and forth to find the physical position of some helper.)
But yes, much of the underlying programming-language mechanism is there now.
instead of having to reply with just two-four letters