short question, when do you use aria-label attribute if you always need a label? doesn't full fill this attribute the same thing?

first rule of aria is not to use aria and to always use native html if possible

https://www.deque.com/blog/top-5-rules-of-aria/

https://stackoverflow.com/questions/43105006/should-i-use-arial-label-or-a-label-element-that-is-visually-hidden#:~:text=Using%20aria-label%20is%20preferable,visually%20hide%20a%20label%20element.&text=But%20note%20that%20you%20don,field%20and%20the%20submit%20button.

which says: "Using aria-label is preferable to relying on CSS to visually hide a label element." and links to https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/ARIA14

it's WCAG 2.0 but I didn't find anything saying something different in 3.0 but tbh didn't read the every...

also your source speaks of a "visible" label or a aria-label...

the first rule of aria always wins

the first rule of aria always wins

sorry but the WCAG says something different and the rule 5 also says something different.

anyway, will come back to this later

You always know better than anyone else.

@HLeithner: The label can sometimes be invisible, but an accessible name is needed for assistive technology users, such as when the context and appearance of the control determine its purpose. Then those who control by voice can issue the appropriate command (e.g., Search, Close). You can, of course, use a label and hide it visually with CSS. But consider that this accessible name is needed by assistive technology users. It is better, simpler and more reliably conveyed using aria-label (the first rule of aria always wins).
Aria was created to provide accessibility components where HTML does not or cannot provide them with HTML. Therefore, use ARIA when you must, not when you can. If you use a native HTML element in this case, you have to hide it visually right afterwards, which causes complications and can cause accessibility problems.
A better choice: use aria-label.
I hope I have clarified. Brian is right.

@HLeithner: The label can sometimes be invisible, but an accessible name is needed for assistive technology users, such as when the context and appearance of the control determine its purpose. Then those who control by voice can issue the appropriate command (e.g., Search, Close). You can, of course, use a label and hide it visually with CSS. But consider that this accessible name is needed by assistive technology users. It is better, simpler and more reliably conveyed using aria-label (the first rule of aria always wins). Aria was created to provide accessibility components where HTML does not or cannot provide them with HTML. Therefore, use ARIA when you must, not when you can. If you use a native HTML element in this case, you have to hide it visually right afterwards, which causes complications and can cause accessibility problems. A better choice: use aria-label. I hope I have clarified. Brian is right.

I appreciate your comment, that's exactly what I said. I think that got lost in translation.

and brian please keep your

You always know better than anyone else.

for you self, thanks

maintainers meeting yesterday decided that accessibility team in this case @drmenzelit will take a look and takes a decision.

What is the a11y team to decide?

Brian offered the correct solution to the reported problem. Before this fix, the screen reader does not announce what the selection lists are for. After the implementation of the fix, the screen reader correctly announces what the selection list is for and correctly announces the date input fields. In terms of accessibility, it is OK.

Also, if the user turns off the stylesheet, they will receive full information (see screenshot)

If I were to further improve this element, I would make the indication specifying the date format visible. The title attribute is not a reliable way to convey instructions and directions for filling in forms.
Furthermore, in my opinion, this fix should be implemented in Joomla 4 and not only in Joomla 5.

@zwiastunsw i have no idea - someone elses problem now

Sadly Brian closed the pull request, so we need to create it again.

@drmenzelit: Does this mean that we should trash a job well done and once again fix something that has already been fixed?
I don't understand.

@brianteeman thx

I have tested this item ✅ successfully on ff94310

i'll don't mark this as a succesful test, cause i've only checked the html , hope that someonelse do the last mile

I have tested this item ✅ successfully on ff94310

I have tested this item ✅ successfully on ff94310

label is added after patch

RTC

Furthermore, in my opinion, this fix should be implemented in Joomla 4 and not only in Joomla 5.

shouldn't be done because it could break frontend templates (also true for 5.0)

Furthermore, in my opinion, this fix should be implemented in Joomla 4 and not only in Joomla 5.

shouldn't be done because it could break frontend templates (also true for 5.0)

not true

not true

it is, if you don't have the class "element-invisible" which is only in Atum and Cassiopeia you get something like that:

Tested on a 4.3 site by just adding the label to the Startdate not using cassiopeia (I think it's yootheme)

If that class is not present then it will have an impact in other places. Also not covered by BC policy

If that class is not present then it will have an impact in other places

@brianteeman I think it should be visually-hidden as we use in other our code, instead of element-invisible.
I checked we mostly use visually-hidden , but did not found element-invisible.

Feel free to edit the pr I don't use the computer on shabbat

Feel free to edit the pr I don't use the computer on shabbat

@brianteeman do you update this before weekend?

Sorry. Thought someone had already done it. Will try tonight when I get back from hospital

changes made as requested

thx

thanks