Home

#Blockly

##Improve the accessibility of the block editor

• Ensure the editor has a full, meaningful accessibility tree populated with information using the ARIA spec.
• Add meaningful keyboard shortcuts and keyboard navigation so the editor can be used mouselessly.
• Ensure elements are all voiced meaningfully when narrated

##What's been accomplished

• The entire editor should be keyboard navigable with tab controls/default google closure library controls.
  • This includes a bunch of context-menu based analogues for mouse drag and drop actions
• The accessibility tree should be fully populated with correct information to inform narrators, which should result in correct voicing.

##What should be done to call this 'good'

• Test for bugs introduced by the changes
  • Write an automated test suite for blockly and blockly a11y
• Merge in upstream (regularly)
• Correct the TODOs and here in the new code to allow for i18n
• Refine the automatic mnemonic creator on the context menu to:
  • Only use alphabetical characters
  • Handle when it can't find any unused characters in the menu item by choosing the first free character, rather than not binding one

##Future direction for our work on block editors

• Finish polishing blockly accessibility support, merge in upstream changes, potentially see if there's interest in a PR to add the a11y support into google/blockly
  • The goal being having something like this be accessible.
• Investigate how block editors like blockly integrate into TouchDevelop and possibly use it as a base for a fully accessible IDE/submit PRs to it until it is a fully accessible IDE.
  • Heck, just investigate TouchDevelop in general. It was released after we started this project, but it looks very promising. TouchDevelop's beginner interface resembles a block interface but doesn't attempt any drag and drop shenanigans and may actually be even better than a block editor for those looking for an accessible experience. Thought right now it looks like the app entirely lacks a11y information.
• Block-intellisense support - ie, user selects a connection and is presented with a list of things that can move there or be created there. TouchDevelop has built-in intellisense support for editors, maybe it could be utilized here?
• While there are many blockly examples out in the web to test against, it might be worth discussing / building a audio-centric application.
  • Beats is a close example, other things to include might be those features available in scratch, like recording and playing audio.
  • Many of the tutorials that do exist have heavy visual components (such as those listed in the Scratch programming books), so, while these guides may not help build a complete tutorial, they can be sued as a general stepping stone.