While typing in a text box, "Accessibility: previous/next element" is allowable, but not while editing other elements such as a slur
When custom shortcuts are utilized, this becomes an issue. If the user makes an alpha-letter be the shortcut for "Accessibility: next/previous element", this will interrupt, for instance, while typing in a staff text. You might say, "Well, that's the price you pay for trying to make a letter be a shortcut for such a thing," and I might agree. The problem here is one of inconsistency and inconvenience.
For example, if the user has a slur and activates the "Edit Element" command while doing so with a slur, "Accessibility: next/previous element" is disabled. Here is the gripe. If you were to allow such behavior as above, in a sense this activity should be reversed: why should it be disabled while editing a line or a slur, but then while typing in a staff-text, it's enabled to go to next element? Either both should be the same, or better yet, disallow moving to next element while typing, and allow for it while dealing with nodes of lines.
Of course this may call for some discussion, so this will be merely a suggestion for now, but it is definitely worth dealing with in the future, albeit's not a critical situation. Although, again, for the user who uses A-Z as shortcuts for navigation, this will screw up some activities.
Aside Note: A quick workaround for typing [A-Z] when alphas are set up as shortcuts that are affected while doing activities specific to text entry: use [ALT+Alpha] and the text will be entered, bypassing the A-Z shortcut.