Factor transformations into position and area for shapes' accessible outputs - addresses #4721

[calebfoss]

Addresses suggestion raised in #4721
Specifically this comment

Changes:

Currently, transformations are not taken into account for outputs generated through textOutput() or gridOutput(). This PR modifies _getPos and _getArea to be methods on the p5 prototype and to factor in the current transformations into their calculations.

You can see that in this example. Three squares are on the canvas in different positions with the square in the lower right being scaled down, but the text output describes only one shape because the arguments passed into square() are the same and because the color is the same.

Here's that same example with the build from this PR.

PR Checklist

• npm run lint passes
• Inline documentation is included / updated
• Unit tests are included / updated

[calebfoss]

Tagging accessibility stewards @kungfuchicken, @cosmicbhejafry for feedback if you have a chance

[davepagurek]

I think this might not work if this gets called when in WebGL mode. But if you detect WebGL mode, you can use new DOMMatrix(this._renderer.uMVMatrix.mat4) and the rest should work!

[calebfoss]

Thank you, @davepagurek! I forgot that the 2D primitive functions could also be called in WEBGL mode. I really appreciate you sharing how to get the transform matrix from the WEBGL renderer because I had no idea!

I've added a commit that accounts for WEBGL mode enough to not throw an error, but that brought me to other issues in WEBGL:

1. Because (0, 0) is in the middle of the canvas by default, _getPos() is inaccurate as is
2. The camera settings would affect the position of a shape on the canvas as well
3. The area calculation would depend on the surface(s) facing the camera, their angle, and the camera settings
4. 3D primitives are not yet supported by these accessible outputs

Currently in WEBGL (without this PR) 2D primitives get inaccurate descriptions, even without transformations.

I think generating these position and area descriptions for WEBGL would be a very big undertaking, and maybe a different format for descriptions would better fit WEBGL. In the meantime, I think it would make sense to modify textOutput() and gridOutput() to only work in 2D and to throw a friendly error if called in WEBGL (along with modification to documentation).

I'm happy to make those changes as well, if that sounds like a good plan. If so, would it be preferable for me to make those changes in a separate PR?

[davepagurek]

Sure thing, this would be an improvement regardless of whether it works for WebGL mode! A follow-up PR sounds good to me.