Awesome thanks

FWIW for the front end templates, we should invert this, eg everything is required unless optional is stated (also should be <small>optional</small> not a *). That is the best practice AFAIK.

actually that is not correct.

There are tonnes of articles denote this as a best practice, here is one:
https://uxdesign.cc/design-better-forms-96fadca0f49c

PS also it marks the favourable tooltips as a bad practice and I couldn't agree more on that as well

it might be from a usability perspective but it certainly isnt from an accessibility compliance perspective

Ok maybe I'm stupid but you're using a star with aria-hidden so how that will be translated to the screen reader? It won't because the field itself has this info (attribute required) so actually you don't have to denote this differently it's already baked in. Now the fields that don't have a required attribute if we add the optional in the label we get a better a11y experience (that word will be pronounced) and also for non-disabled people the distinction is totally clear. And we get to have a better UX on top of that.
Actually, I would love to see us implement all these proposals for the article above (some of them already done)...

Ok maybe I'm stupid but you're using a star with aria-hidden so how that will be translated to the screen reader?

Correct - the screenreader already knows it is required because of the required attribute on the field - hence it doesnt need to be told about the star as that would be duplicate information

However don't forget that a11y is not just about the visually impaired and the a11y specifications state that you must indicate that a field is required. So while the required attribute on the field does satisfy the requirement for a visually impaired user it does not for sighted users - hence the need for it to be visibly annotated - in this case by a star

If you can find any accessibility documentation that says to just mark the optional fields I will be very surprised

hence the need for it to be visibly annotated

Well, the argument here is do you annotate the required or the non-required fields.
Obviously, you can go both ways as the result is the same but for me is more elegant to annotate the non-required fields, as if you did the form correctly in the first place these fields should be very few...

it is not that i disagree with you it is that the specification disagrees with you ;)

ok, can you point me to those specs, I really need to read this

Maybe it's just me but the same aria-hidden concept could apply if you're marking optional fields versus required. Clearly it's going to be easier to mark required fields (even a input:required + label::after type selector can be used to put the asterisk in with CSS only), but something feels really wrong about a11y guidelines basically stating "you can only visually mark required fields as required, you cannot visually mark non-required fields as optional".

"you can only visually mark required fields as required, you cannot visually mark non-required fields as optional".

it doesnt say that. As far as I understood dimitris he wanted to only mark the optional fields and I am saying that the specification says that the required fields must be marked

You'd still use the required attribute on required fields. But instead of the asterisk to visually mark required fields, you'd use a help text to visually mark optional fields.

I would like to mark optional fields instead of using the ugly asterisk.
But what I don't like at all is that we mark the categoryedit field as required in the right status bar (i.e. article edit). Either we set all dropdowns required or none.

. Either we set all dropdowns required or none.

Except that is the only one that is required

Right. But the user has no chance NOT to select something.

sorry you are absolutely right. it didnt used to have a default. that can definitely be removed but it is beyond the scope of this pr

It is possible not to have any categories created on a site. In that scenario the category drop down has no value. So it is a required field and it can have no value. However I agree that marking it as required makes no sense and instead we should perhaps look at a way of ensuring that there is always at least one category. But its definitely beyond the scope of this pr

@brianteeman @wilsonge quite honestly aria-hidden="true" or any similar toggling aria attribute should be applied by javascript. Accessibility requires JS afaik

If there is no category at all, the whole application wold break down. think that nobody ever tried to delete all categories ;) (except me, right now). But agree - at least one category must exist and we should make sure that not all categories can be deleted or trashed and the field never could be empty.

Just found this old discussion. I remember that we meanwhile changed all the attributes.
Is this still an issue @brianteeman @dgrammatiko ?

it's not a discussion it was a PR that has been merged or am I missing something?

@brianteeman it's merged but it still appears in the issue tracker as "need tests": https://issues.joomla.org/tracker/joomla-cms/21190.

Not sure who could check on this.

not me

Set to "closed" on behalf of @alikon by The JTracker Application at issues.joomla.org/joomla-cms/21190

for the curious the history https://github.com/joomla/joomla-cms/commits/4.1-dev/layouts/joomla/form/renderlabel.php