Fix: Add answer status to question list for screen reader accessibility
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_answeredandtst_answer_status_not_answered - Question titles now display as "Question Title (Answered)" or "Question Title (Not answered)".
Ticket 43952
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
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.
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.
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
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
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!
Hi @kergomard, @klees and @Annett7811:
Based on the feedback we received, we’ve updated the implementation to improve accessibility in the test player. We added an aria-label to the question links so that screen readers can announce each question’s status (e.g., “Question 1 (Answered)”) without affecting the visual interface. We also extended the Workflow component to accept a map of status constants to text labels, which is now used to dynamically generate these accessible descriptions.
We look forward to finding out whether this implementation is more in line with what is required.
Once again, thank you all very much for your comments.
Best regards, Daniel.