Enhance accessibility on Onomasticon module

Created on 8 February 2023, almost 2 years ago
Updated 9 October 2023, about 1 year ago

Problem/Motivation

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>
Feature request
Status

Fixed

Version

2.0

Component

Code

Created by

🇧🇪Belgium bernardopaulino Brussels

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @bernardopaulino
  • 🇧🇪Belgium bernardopaulino Brussels

    Here is a patch that should improve accessibility when using extra element option in the onomasticon text format filter.

  • 🇧🇪Belgium bernardopaulino Brussels

    Removed extra enter from the template to comply with coding standards.

  • 🇩🇪Germany broon Potsdam

    Thank 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.

  • Status changed to Closed: works as designed over 1 year ago
  • 🇩🇪Germany broon Potsdam

    I 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).

  • Status changed to Needs review about 1 year ago
  • 🇧🇪Belgium bernardopaulino Brussels

    Thank 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.

  • Assigned to broon
  • 🇩🇪Germany broon Potsdam

    Thanks 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).

    • broon committed 60c1fd5a on 2.x
      Issue #3340245 by bernardopaulino: Enhance accessibility on Onomasticon...
  • Issue was unassigned.
  • Status changed to Fixed about 1 year ago
  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024