The links should be discoverable by accessibility software

[skorokithakis]

Currently they look just like text to screen readers.

[luciandex]

@skorokithakis I think one solution may be "focus" event.
When screen reader focus on the expounder, the expounded should appear.
But what if the human "reader" does not want the expounded explanation?
How to control that for every instance of epounded element?

[luciandex]

@skorokithakis , up! 🙂

[skorokithakis]

Sorry, yes. I don't really know much about how accessibility works on the frontend here, so I can't really say :/

[luciandex]

Perhaps, we can set a shortcut key combination.
When is pressed, the expounded will open, then screen reader can read the text.
I am not sure if it's working, but I will try to achieve this.
The steps:

• reader focus on a word that have explanation
• the user can be notified by a beep (?) that he can get an explanation (and the reader will wait 2-4 seconds)
• the user press keys combination
• the reader parse the explanation and continuing with the text after

[skorokithakis]

Hm, isn't there some ARIA attribute that can do the right thing here?

[luciandex]

I know that. I will try something in that direction first. I though that can't be achieve by that apriori.

[luciandex]

But, as I notice above, what can be done if a user don't want to "read" explanantion?
And even if the exponded has an aria attribute, the reader will try to read a hidden text. I don't think this is possible.

[skorokithakis]

Yeah, it sounds very tricky... What does the screen reader read when something is a link?

[stelabouras]

Here are some links regarding certain ARIA roles, states and properties worth reading that might help with the issue here:

• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Tooltip_Role
• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-haspopup
• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-expanded

The aria-expanded one looks promising 🤔