Glossary component proposal evaluation

[jaclinec]

The USWDS UX and accessibility subject matter experts are taking a first pass at the glossary component suggested in our component proposal discussions. We are piloting our process for evaluating the component to consider including it/developing it for USWDS. Along the way, we will further define our early process and evaluation criteria for component proposals.

[jaclinec]

Making good progress on the Glossary component evaluation. We are honing the evaluation criteria / decision tree. We considered using a scoring rubric but also may adapt an earlier proposal evaluation decision tree created by Amy Leadem.

Next steps are:

• a11y and UX discuss the approach we want to take between a decision tree and a scoring rubric. Finalize a draft for that.
• Present what we've found so far to the team and further refine the document and eval criteria from there.

[amycole501]

This issue relates to uswds/uswds#5954

[jaclinec]

This evaluation is as close as complete its going to get at this point. The recommendation from UX and Accessibility is to move forward with the proposal.

We recommend moving forward with the glossary component proposal for several compelling and evidence-based reasons.

A glossary component (or alternatively, a new "Help a user understand unfamiliar language" pattern):

• Supports WCAG AAA success criteria 3.1.3 unusual words which falls under Guideline 3.1 Readable.
• Supports a user’s need to understand unfamiliar terms on a website, which is especially applicable for government websites given the guidance for localization and plain language in M-23-22 directives.
• Serves as a viable solution not currently offered in USWDS. The potential existing solutions (such as tooltip, accordion, modal, summary box, or alert) are limited in their ability to provide clear, brief displays of definitions and there are some usability and accessibility concerns with their implementation. There is no solution that could serve as a comprehensive reference source for unfamiliar terms; a glossary would fulfill that requirement.
• Has usability and accessibility benefits that outweigh potential risks. Additionally, the risks can be mitigated with helpful guidance that encourages the use of plain language as well as point-of-need strategies (ex: accordions, modals, etc.) for helping users understand unfamiliar terms.
• Is strongly needed by the USWDS community. Glossaries are already being used across the government digital landscape. It is unclear if the accessibility and user experience of these instances has been documented. By providing a research-based glossary component or pattern, we can provide consistency in future implementations.

Evaluation criteria	Yes	Somewhat	No
Does it support a WCAG requirement?	X
Does it address a user need?	X
Is there an existing USWDS solution to fulfill the need?		X
Is this component needed by the USWDS community?	X
Do the usability and accessibility benefits outweigh the potential risks of using the component?	X

Next step is presenting it at the CS UX sync and then obtain fed approval.

[jaclinec]

This was presented to the team at CS UX sync. Can be marked as 'done' for this stage of the component lifecycle. Next steps are further documenting "when to use" and "when not to use" a glossary, and also bring Content Strategy into the fold of this work to get their input.