AppendageNode order of change/input firing

[jonathanolson]

It would be helpful near here:

    // Due to the variability of input and change event firing across browsers,
    // it is necessary to track if the input event was fired and if not, to
    // handle the change event instead.
    // see: https://wiki.fluidproject.org/pages/viewpage.action?pageId=61767683

to mention that the input event will fire before the change event (in the case that they both fire). The listener for 'change' was in front, so it took a bit to sort out the logic.

Also, this seems like behavior that would be very common, and should be abstracted out (e.g. #149).

[jonathanolson]

Code review for #128

[jonathanolson]

Also as a note about related code: rotateAppendage() is specific to rotating due to the accessible DOM (that wasn't immediately apparent from the name).

[jessegreenberg]

I updated the documentation for both #153 (comment) and #153 (comment).

[jessegreenberg]

I agree, that much should be abstracted out for all accessible sliders. #149 suggests a mixin pattern for all kinds of accessible components, and this event handling could be handled there.

[jessegreenberg]

Also, this seems like behavior that would be very common, and should be abstracted out (e.g. #149).

Further abstraction of accessible components is going to be tracked in phetsims/scenery#607, closing this issue.