Expose coordinates as fields for accessibility

Re-roll for 2.1.0

Hello @bleen and @Kasey_MK, the patch !11 has been reviewed and tested. It's working fine .

Updating the version, so an appropriate issue fork can be created.

Added the issue to the a11y meta and added the the wcag211 tag for now (might need more wcag tags)

At first thanks to @kasey_mk for all the work on the issue and @the_g_bomb for moving the patch in #11 📌 Expose coordinates as fields for accessibility Needs review into merge request. I've tested MR42, a few thoughts and observations:

In general some work might be needed stylingwise. I've tested on 11.x and focal_point 2.x using Safari 18.1. On a desktop viewport the image fieldset looks like that:

While on a mobile viewport there is no linewrapping and the entire description is getting crammed into a single line:

In general I love the idea of progressive disclosure showing Click and drag the indicator to set the focus of this image, or double-click the indicator for a text field to change the focal point offsets. only when javascript is available. but i wonder when no javascript is available and the description is hidden why the white cross of the focal point is still shown? wouldnt it make sense to hide it as well?

in regard of the behavior for screenreader users. first i consider it confusing that the focal point field is placed in different positions depending on if javascript is available or not. Without Javascript it is at the end of the fieldset

While with javascript available it is at the first position in the fieldset:

It feels also rather odd and confusing that the focal point field is first hidden and only shown when it gets into keyboard focus. In that case it is not a progressive disclosure that first a criterion has to be met but the user just has to tab until they reach the focal point field. if you have a sighted keyboard user who is reading "Click and drag the indicator to set the focus of this image, or double-click the indicator for a text field to change the focal point offsets." there is no indication that the feature is keyboard accessible nor that the focal field will get unhidden when it gets into focus. the description is only about mouse interaction. So i wonder if it wouldnt be the better choice to make the focal point field visible all the time for everyone in every context?

In regards of the syntax used on the focal point field, having something like 50,50 along with instructions like "Specify the focus of this image in the form "leftoffset,topoffset" where offsets are in percents. Ex: 25,75 " is sort of challenging. would it be an idea, instead of having one input text field, having two input number fields. that way the keyboard user would be able to either type in the number or use the up and down arrow key changing the value, plus a failsafe could be added only allowing integer values with a minimum value of 1 and a maximum value of 100?

Thanks for your thorough review, @rkoller! For what it's worth, my responses:

In general some work might be needed stylingwise

Agreed! I think I ended up changing styles in my own theme; it didn't occur to me that that might be an issue to solve in focal_point.

in regard of the behavior for screenreader users. first i consider it confusing that the focal point field is placed in different positions depending on if javascript is available or not

It does make sense to have it in the same position. If I recall correctly, I couldn't figure out how to move the field without JS.

i wonder when no javascript is available and the description is hidden why the white cross of the focal point is still shown? wouldnt it make sense to hide it as well?

I think it makes sense to show the crosshairs regardless, since they provide a visual confirmation of the values in the offset field(s) for those who can see it. I like that changing the values using either input automatically updates the other.

So i wonder if it wouldnt be the better choice to make the focal point field visible all the time for everyone in every context

I have no objection to that, personally. If I recall correctly, I was aiming to change as little as possible, but in general I'd think it would be much more accessible and easy to use to just give everyone access to the same tools instead of trying to guess exactly what tools any individual user might need and then anticipate how they'd find them.

In regards of the syntax used on the focal point field, having something like 50,50 along with instructions like "Specify the focus of this image in the form "leftoffset,topoffset" where offsets are in percents. Ex: 25,75 " is sort of challenging. would it be an idea, instead of having one input text field, having two input number fields. that way the keyboard user would be able to either type in the number or use the up and down arrow key changing the value, plus a failsafe could be added only allowing integer values with a minimum value of 1 and a maximum value of 100?

I like that idea, though it's been a long time since I looked at the code and I don't know how difficult that kind of change would be. At the very least, I'd try to make the instructions more human friendly, maybe replacing "leftoffset,topoffset" with "[left offset],[top offset]" or explaining it with a little less tech-speak.

I don't know if I'll get some time to take another crack at this, but if no one else picks it up before I get back here, I'll leave a comment to say I'm giving it another whirl.