[4.0] Modal select fields

[brianteeman]

The following fields were identified by @zwiastunsw as not having labels associated with the element

There were TWO different problems that this PR fixes

1. the label was being associated with the hidden input and not the visible input
2. The visible input was set to disabled - it should have been readonly because

When applied to a form field, the disabled attribute means that the field does not receive focus. resulting in the screen reader ignoring the field and not announcing the value of the field

Basically the fields that look like

Menus: Edit Item page, Single Article menu item type
Details tab: Select Article field

Menus: Edit Item page, Category blog menu item type
Details tab: Choose a Category field

Menus: Edit Item page, Single Contact menu item type
Details tab: Select Contact field

Menus: Edit Item page, Contact Single Category menu item type
Details tab: Select a Category field

Menus: Edit Item page, Single News Feed menu item type
Details tab: Feed field

[wilsonge]

This is more complicated. There’s a technical difference too. Disabled means the field isn’t submitting. So the readonly attribute means it is submitting which is undesired. We only want the hidden field to be submitting the data

[brianteeman]

Disabled also means the field should be skipped in the tab order which is why the screen reader never sees it. It might be submitted but what is it submitting? It can only be submitting exactly the same as the hidden field. As both fields have different id then surely we are already only storing the submitted values of the hidden field???

Have to ask though why we have a hidden field in the first place?

[SharkyKZ]

Hidden field holds the value/ID that is sent to the server. Text field just displays the name of selected item to the user.

@wilsonge True, but that shouldn't be an issue if input has no name attribute?

[wilsonge]

I can't find any docs on that either way. The HTML5 spec says that name is optional but doesn't tell browsers how to handle it when that is missing. I think practically speaking it's true it won't be submitted when it's missing but it's definitely not a given either.

As for why it's hidden it's as @SharkyKZ says. The value being submitted isn't the name of the article it's the id. The disabled field is sending the title of the newsfeed/article etc

[SniperSister]

As discussed with @wilsonge: securitywise I have no concerns with the PR

[wilsonge]

Good to continue then @brianteeman

[brianteeman]

After that small diversion its all good to go then. Just needs tests. Nothing else from me

[sanderpotjer]

I have tested this item ✅ successfully on df3755c

There are some JS formvalidator issues when creating a new article via the Modal select fields, but that does not seem to be related to the changes of this PR.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/24775.}

[euismod2336]

I have tested this item ✅ successfully on df3755c

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/24775.}

[wilsonge]

Thanks guys!

[brianteeman]

Thanks

[infograf768]

This has changed drastically the id of the label, using _name instead of _id and therefore breaking some js as associations-edit.js
It took me some hours to find out what was broken and I can solve the js easily with a PR but I wonder if this is B/C.

Could someone explain in simple terms why this specific change ?
For example I get:
<label id="jform_associations_de_DE_name-lbl"
instead of
<label id="jform_associations_de_DE_id-lbl"

If it IS absolutely necessary then we should have some documentation about it.

[brianteeman]

Before the markup was incorrect as it said label for= something that didnt exist

Now the markup is correct and correctly associates the label with the input

[infograf768]

See #25060
I still think that this change should be documented.