search

brownplt / code.pyret.org

Website for serving Pyret to folks.
Other
24 stars 45 forks source link

Is the ARIA labelling for rotations backwards? #356

Closed blerner closed 3 years ago

blerner commented 3 years ago

rotate(27, ellipse(40, 20, "solid", "gray")) produces a value whose aria-label attribute is "Rotated image, -27 degrees: a solid gray ellipse of width 40 and height 20" -- note the minus-sign in the degrees. @schanzer @ds26gte your input would be useful here :)

schanzer commented 3 years ago

Isn't the default rotation behavior CCW?

blerner commented 3 years ago

Yes, but I'm surprised at the mismatch between the argument 27 and the description -27 degrees

ds26gte commented 3 years ago

The angle argument of rotate() (in image.js, ~ line 600) is inverted when passed to makeRotateImage. Git credits this rather deliberate-seeming inversion to @jpolitz circa July 2016.

jpolitz commented 3 years ago

I think that commit is just the initial commit of image.js, that mirrors the original, API-edited to match how the Pyret module works (see https://github.com/bootstrapworld/wescheme/blob/742326520bc7b4b4ad2d30d4273b43b0ced2f7f6/war-src/js/js-runtime/primitive.js#L5366)

It seems like the internal API and the user-facing API use degrees in different “directions.” The aria-text speaks negative in both WeScheme and CPO.

image

Agree with @blerner that we should re-negate the argument when spoken (and probably consider doing the arithmetic inside the RotateImage methods rather than relying on clients of RotateImage correctly negating the argument)

schanzer commented 3 years ago

I'm convinced - negating the angle for ARIA is the right move. WeScheme will be updated tonight.