Hey Catherine,
Thanks for getting in touch! We aim to release a beta in April, so not too far away. If we have an earlier alpha release we can also let you know about it. We haven't discussed doing that but if we find a logical place to do that we will consider it.
If you just want to try out the features we've been working on, you can play with it on the test page
here. This is based on the `add-screen-reader-support-experimental` branches of both the keyboard-experimentation repo and the core blockly repo. However, that branch is definitely
experimental and I would not recommend changing any of your application's code based on that branch. While a lot of the user experience will be the same (pending the feedback we gained from user research sessions), the way we're implementing the features and APIs will change. That work is being done in the `v13` branch of the blockly repo, but I think right now it's not stable enough to meaningfully pull in the changes. v13 is the branch I'd keep an eye on though!
For the v13 release (coming this summer), we're actually hoping to retire the `keyboard-navigation` plugin because Blockly will be accessible by default. The plugin may still exist to provide default experiences for things like a keyboard shortcut help modal which we expect many applications may want to replace with their own version that is more closely tied to the rest of their application.
In terms of other things you could be doing now to prepare, some things you will need to think about include:
- Onboarding experience. The user testing results showed that good onboarding was essential to giving all students a good experience. Consider your current teacher/parent/guide resources and how you could improve them to help teachers of visually impaired students get acquainted with your software and hardware. More research on this will be shared at the Blockly summit I'm sure!
- Aria labels for your blocks and the rest of your page. While Blockly will include aria labels for the built-in blocks, for the best experience, your custom blocks and fields will likely need custom labels. We will provide APIs to do this, so for now you can be thinking of the kind of consistent vocabulary you can use throughout your application. Again, hoping to be able to share more concrete research results in the future.
- Help content. You'll want to provide some kind of help content for keyboard shortcut and screenreader users. You can see an example of what I mean by pressing Ctrl/Cmd+/ in the demo I linked above. It should open a modal with a list of available keyboard shortcuts. We'll provide this default experience but you might want to integrate it to your app better, such as if you already have a help sidebar, maybe you want to open that instead.
- Settings screen. What we've learned from user testing is that there is no one-size-fits-all approach to making Blockly accessible. What works for sighted users with physical disabilities may not work for a screenreader user. We'll have some suggestions on this later but think about if there is already a good place in your application to add a setting like "turn on screenreader mode" or "enable audio cues" or things like that.
- Prep for VPAT. Start researching if and how you will complete a VPAT to make it easier for schools to adopt your programs.
I hope that helps! We will be sure to share updates here and on the blockly-accessibility group when we have more news to share.
Best,
Maribeth