Unexplained abbreviations on website

[selfthinker]

This issue is from the accessibility audit of the Design System website by DAC in July 2024.

DAC's description

• Page: Home – GOV.UK Design System
• WCAG reference: 3.1.4 Abbreviations (Level AAA)
• Issue ID: DAC_Abbreviations_01

The abbreviation 'GDS' was present throughout the page which was not conveyed in its expanded form when it was first used. This could be problematic for some users who may not be familiar with the meaning of the acronym.

Current code

<p class="govuk-body">
   See what the Design System team at GDS is planning to work on over the next 12 months in the <a href="/community/roadmap/" class="govuk-link" data-hcontribute="guidelinegh">GOV.UK Design System Roadmap</a>.
</p>

Cognitive user comments

“At the bottom of the page the acronym ‘GDS’ is used without an explanation on the page. I would not expect a user to understand any acronym immediately as different services and industries may use the same acronym to mean different things.
This can lead to confusion, or mistakes being made if a user assumes the acronym may stand for something else. Those with short term memory loss will also have trouble remembering acronyms.”

DAC's proposed solution

Ensure that all acronyms and abbreviations are expanded upon in the first instance to ensure that all users can understand what they represent. Using the expanded state of the of the abbreviation will ensure that users can clearly determine what they are accessing; this is particularly important for users who may experience cognitive difficulties. For more information, please refer to Technique G102: Providing the expansion or explanation of an abbreviation.

Thoughts about the solution

While it's generally a good idea to expand abbreviations and acronyms, in this particular case ("GDS") it might be fair to argue the need for fixing it depends on how well our target audience knows it. I'd propose to only fix those acronyms that we think would otherwise be confusing for our target audience.

Additional instances

DAC's report mentions additional instances in the Accessibility strategy.

As this can potentially happen on any page, this work should include checking all the other pages for other uses of abbreviations.
It might be worth making two different cards for this: One for checking and recording all instances, the other for fixing them.

To save time, it makes sense to audit all the body copy issues together:

• Unexplained abbreviations on website #4010
• Non-descriptive links on the website #4013
• Links on website missing context #4023
• Use of special characters on website #4024
• Wrong heading structure on website #4025

Needed roles

Content designer

Tasks

Beta Give feedback

1. List of abbreviations we want to scan for (if needed)
2. Build process to scan for abbreviations and acronyms (as consecutive capital letters)
3. Run scan
4. Capture report into single document
5. Review document to find instances and decide on actions for each instance
6. Implement actions in PR
7. Review with team
8. Publish
9. Consider adding process to prevent in future

[calvin-lau-sig7]

To detect, we can:

• find acronyms by scanning website for 2 or more capitalised letters adjacent to one another
• for abbreviations we could possibly, we could possibly make a dictionary scan on the website

To assess, we'll need to:

• review results on a spreadsheet

To resolve, we can:

• ensure acronyms and abbreviations are explained in first instance
• removed if it does not serve a useful purpose

[selfthinker]

Just for more context, this is what the GOV.UK Style Guide says about abbreviations and acronyms. As a lot of our content is technical, it's also worth checking the style guide for technical content as that mentions a couple of acronyms that should not be expanded.

[calvin-lau-sig7]

Update for potential squad wrap-up after this cycle:

As an investigation, I've completed a rough audit of acronyms across the Design System website, as an audit sheet and put together a 'report' showing notable acronyms found with categories.

This work could potentially continue as a small story, with input gathered async. One idea is to survey a few team members on acronyms to decide whether they need to be explained for users.

Rough steps would look like:

• create Google Forms survey, listing all found acronyms, grouped by type
• team members are asked to assess whether each acronym is "commonly known" or a "technical term familiar by expert audience", possibly 1-2 other factors
• results used to inform which acronyms require explanation
• changes entered into pull request and published