[Improvement] UI: Remove Glyph Action

[fhelfer]

related to #10985

[iszmais]

Thx!

I approve the changes within DataCollection 👍

[matthiaskunkel]

23 MAR 2026: Thibeau notified us about this PR and its impact on the improvement of accessibilty in ILIAS 11. He asks all involved authorities to have a quick look on the related changes and let Thibeau know until Thursday if the object. Otherwise, he would merge the PR on Friday to proceed with testing of 11. PR is accepted for 11 and trunk.

[kergomard]

Thank you very much for the PR @fhelfer and @thibsy !

Ok, this looks ok for the changes in the TestQuestionPool and I approve the changes there.

The changes in ilObjectListGUI have an unfortunate side-effect though:

• Please make sure the pointer is changed to indicate a clickable element in the header indication for Tags.

Thanks again and best,
@kergomard

[BettyFromHH]

On testing the lerning module, ilias crashed on loading the learning progress.

Call to undefined method ILIAS\UI\Implementation\Component\Symbol\Glyph\Glyph::withUnavailableAction()

Additional Information:

components/ILIAS/Tracking/classes/repository_statistics/class.ilLPListOfSettingsGUI.php (Line 559)
  
$this->ui_factory->symbol()->glyph()->expand()->withUnavailableAction()

[fhelfer]

@BettyFromHH, @kergomard thanks for your comments. I removed the rest of Calls to the deprecated methods & ObjectListGUI Headers are now rendererd with a button

[kergomard]

Thanks @fhelfer !

[thibsy]

Hi @fhelfer,

Huge thanks for going after these deprecated usages of 'clickable' glyph components. This is very much appreciated.

As you can see I asked component authorities at JF yesterday to look into this PR until Thursday, so we can possibly merge this by the end of this week.

In addition to my inline comments, please implement the following changes:

• Event.preventDefault(): you implement around 28 of these method calls inside the client-side logic. I assume this is because the underlying HTML changes from <a> to <button>. I believe most of these can be removed by introducing a new context renderer for our button components which are rendered inside a form (I think without matching the form itself), which adds a type="button" attribute to the rendered HTML. <button> will implicitly inherit a type="submit" if contained inside a <form> – which I think is why you implemented these calls in the first place (accidental form submission).
• Accessibility: currently we always render glyphs inside a button with role="img" and the respective aria-label if the button does not have a label itself. However, I think the most appropriate solution in this case would be to move the aria-label up to the level of the button, remove it on the glyph and make the glyph aria-hidden="true", because in this case the button is the interactive element that should convey all the information and the glyph is primarily decorative. You should be able to achieve this by updating the button renderer and the "glyph inside button" context renderer.
• Field\Password::withRevelation(): I think the (S)CSS of the password component isn't too happy about the change from a link to a button element. Could you or maybe @BettyFromHH look into this?

And, one suggestion:

• Symbol\Glyph examples: while the withUnavailableAction() method does no longer exist, their 'inactive' state still remains. You have simply removed this from the documentation/examples. Now I'm wondering, if it would not make sense to keep this showcase in tact and replace this with a glyph attached to a button. I am however fine with adding this to the roadmap for now (general showcase of glyphs in different button scenarios, e.g. label / no label, disabled, etc.), but maybe @oliversamoila has some strong opinion here?

And btw, neat way of updating the factory descriptions. I like the wording very much.

Kind regards,
@thibsy (as UI coordinator)

[oliversamoila]

Hello everyone.
I’d also like to say a big thank you for all this work, which was “only” initiated by validation errors but has now grown way beyond that. Thanks @fhelfer
Regarding @thibsy|s question: I think the current documentation for each glyph is very appropriate. There are still examples featuring glyphs for Standard Button, Primary Button, Shy Button and Bulky Button. These are definitely well worth keeping, because of the existing combination possibilities.

Best regards,
@oliversamoila

[fhelfer]

• Event.preventDefault(): you implement around 28 of these method calls inside the client-side logic. I assume this is because the underlying HTML changes from <a> to <button>. I believe most of these can be removed by introducing a new context renderer for our button components which are rendered inside a form (I think without matching the form itself), which adds a type="button" attribute to the rendered HTML. <button> will implicitly inherit a type="submit" if contained inside a <form> – which I think is why you implemented these calls in the first place (accidental form submission).

Because these glyphs are injected straight into a legacy template, the renderer has no reliable way to know that they end up inside a

. Until the Answer Wizard is replaced by a proper UI component, we therefore have to keep relying on preventDefault to avoid unintended form submissions.

• Accessibility: currently we always render glyphs inside a button with role="img" and the respective aria-label if the button does not have a label itself. However, I think the most appropriate solution in this case would be to move the aria-label up to the level of the button, remove it on the glyph and make the glyph aria-hidden="true", because in this case the button is the interactive element that should convey all the information and the glyph is primarily decorative. You should be able to achieve this by updating the button renderer and the "glyph inside button" context renderer.

Done. When the button has no visible label, the button’s aria-label is derived from the glyph (via glyphAccessibleName()). One side effect is that in setups like the notification centre in NotificationItemTest.html, counter information is swallowed.

Best @fhelfer.

[BettyFromHH]

Hi @thibsy,

Field\Password::withRevelation(): I think the (S)CSS of the password component isn't too happy about the change from a link to a button element.

Yes, you're right. The button have to be moved upwards for 5 more pixels. Thanks for that hint.

Hi @fhelfer

Please modify the 070-components/UI-framework/Input/_ui-component_password.scss, Line 4

from

margin-top: -21px;

to

margin-top: -26px;

That should fix that problem.

[fhelfer]

Thank you @BettyFromHH