Skip to content

Conversation

@ZallaxDev
Copy link
Contributor

This commit adds the answer status text to each question title in the question list, making it accessible to screen readers while maintaining the visual indicators.

Changes:

  • Modified ilTestPlayerAbstractGUI::showSideList() to include answer status text in question titles
  • Uses existing language strings: tst_answer_status_answered and tst_answer_status_not_answered
  • Question titles now display as "Question Title (Answered)" or "Question Title (Not answered)".

Ticket 43952

…ty. Ticket 43952

This commit adds the answer status text to each question title in the question
list, making it accessible to screen readers while maintaining the visual
indicators.

Changes:
- Modified ilTestPlayerAbstractGUI::showSideList() to include answer status
  text in question titles
- Uses existing language strings: tst_answer_status_answered and
  tst_answer_status_not_answered
- Question titles now display as "Question Title (Answered)" or
  "Question Title (Not answered)". Ticket 43952
@ZallaxDev ZallaxDev requested a review from klees October 16, 2025 15:20
@ZallaxDev ZallaxDev added bugfix php Pull requests that update Php code labels Oct 16, 2025
@kergomard
Copy link
Contributor

kergomard commented Oct 17, 2025

Hi @ZallaxDev

Thanks for the PR!

Just because I saw this coming by today: I do not think this is the right solution and I would need a lot of convincing to accept it for the test. This makes the experience for the majority of users (all looking at the page) worse by cluttering the screen with duplicate information to solve a problem for a smaller group (those having the screen read to them). I think the correct solution in this case would be to expand the interface of bulky links and bulky buttons by a way to set a "aria-label" on it and then set this as the value there. On a quick glance I do not believe the implementation is correct, either, but this would tackle later on.

Just on a note to implement such an interface: It would be nice, if it would be built to enforce the requirement that the visible name is included in the accessible name .

Thanks and best,
@kergomard

@kergomard
Copy link
Contributor

Sorry, I just realized one more thing: This needs to be done a level up in the workflow. There it gets even more useful as it could be implemented by assigning a text representation to the status and the function for the buttons (in this case) and potentially also links could stay internal and wouldn't need to be on the interface.

@ZallaxDev
Copy link
Contributor Author

Thank you very much for the thorough review and detailed feedback. For us, your point makes a lot of sense: we understand that adding visible text may negatively affect the overall experience, and we agree that an aria-label–based solution would be more suitable and consistent with accessibility guidelines. We’ll mention @Annett7811 as the SIG Accessibility Leader and link this PR in the Mantis ticket so we can discuss it with a broader perspective and reach a well-agreed, robust solution together.

Best regards,
Daniel.

@Annett7811
Copy link

Hello!

Thank you very much for the detailed feedback and the differentiated discussion on the topic of the status display in the question list.
I understand the argument regarding a possible visual overload due to the additional text output. At the same time, I would like to point out that sighted users could also benefit from a double-coded display - i.e. a combination of a visual symbol and textual information. Such redundancy could increase user-friendliness and support people with impaired vision or color perception problems in particular.
From the point of view of accessibility testing, however, it is clear that the only thing that counts for the assessment is whether the information is technically accessible for screen readers or not. The solution proposed here would therefore be completely sufficient, provided it reliably conveys the information content.
I generally consider the proposed approach to be sensible and consistent with accessibility requirements. In this way, the problem could be solved sustainably and without impairing the visual interface.

Best regards,
Annett

@ZallaxDev
Copy link
Contributor Author

Thanks for the feedback and discussion.
We’ll move forward with the aria-label–based solution, as suggested, since it aligns better with accessibility guidelines and keeps the interface clean. I’ll leave another comment here once the updated implementation is ready for review.

Best regards,
Daniel

@klees
Copy link
Member

klees commented Oct 27, 2025

Hi everyone,

I think it's totally fine that @ZallaxDev moves on and also that this issue was discussed here via GitHub. But I also want to point out: As far as I'm concerned, we have reinitiated the A11y-Squad exactly to have discussions like this. So afaic it would be absolutely fine to bring issues like this into the squad, discuss options and then decide for a way forward.

Kind regards!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bugfix php Pull requests that update Php code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants