Currently, the "Onomaticon" module is using the element in a wrong implementation way.
The element represents the defining instance of a term and it can contain only the term being defined. If the ´title´ attribute of the element is present, then it must contain the term being defined only as well.
Defining term using a tooltip: By default, the paragraph, description list group, or section that is the nearest ancestor of the element must contain the definition(s) for the term given by the element. However, if no ancestor node, the ´aria-describedby´ property may be used to attach the definition(s) for the term to the element through the use of an ´id´ reference.
What is outputted currently but wrongly:
<dfn class="onomasticon ..." tabindex="0" title="marketplaces">
<button disabled="" class=...">
<p>Here the definition about marketplaces</p>
</button>
</dfn>
What should be outputted according to the specifications and in compliance with the WCAG guidelines:
<span class="onomasticon ...">
<dfn tabindex="0" aria-describedby="definition">marketplaces</dfn>
<span id="definition" role="tooltip" hidden="">Here the definition about marketplaces</span>
</span>
Comments
Comment #2
bernardopaulino commentedHere is a patch that should improve accessibility when using extra element option in the onomasticon text format filter.
Comment #3
bernardopaulino commentedRemoved extra enter from the template to comply with coding standards.
Comment #4
bernardopaulino commentedComment #5
broonThank you for your input. I am actually aware that the default way Onomasticon is using HTML elements is not proper and there is even a paragraph on that in the module's description page with a link to the discussion leading to the decision made: http://stackoverflow.com/questions/40531029/how-to-create-a-pure-css-too...
To summarize, it was requested to create a CSS-only solution which is able to include rich text in the term's description (including images).
I am open to patches that add an accessibility option but I will not change the default behaviour unless there is a better option that satisfies all requirements.
Comment #6
broonI am closing this as "works as designed" because of the original purpose of this module. If you do get time to work on your patch, I am happy to review. My suggestion would be to add a third option besides "Extra element" and "Title attribute", ie. "Accessibility first" (or similar).
Comment #7
bernardopaulino commentedThank you so much @broon for your feedback. I trully appreciate it.
I am uploading a new patch that incorporates your suggestion. This patch introduces a new option titled "Accessibility First" within the filter configurations. Additionally, I've ensured that it uses the same CSS styles as the "Extra Element" option.
I hope this approach aligns better with the requirements.
Comment #8
broonThanks a lot for your effort. From a pure code perspective this looks fine. I'll test it and look for implications this might have (will take a few days).
Comment #10
broon