[policy] Rephrase input device-specific language (remove e.g. "click")

Problem/Motivation

Drupal uses variations on the verb "click" in user-facing text (account emails), site administrator-facing text (e.g. status messages, inline help) and developer-facing text (e.g. PHPDoc, code comments).

Websites/applications built in Drupal are not only being used with point-and-click devices like mouses. They are also being used:

• on mobile devices (tapping with a finger or stylus to activate or execute)
• with keyboards (tabbing to navigate, pressing 'return' or 'space' to activate or execute)
• with remotes (think smart TV interfaces)
• with speech-to-text for navigation
• with eye-gaze detection
• with potential future navigation techniques, such as hand gestures

In particular for user-facing text, we shouldn't be assuming a particular input device is being used.

This is a proposal to create a policy to rephrase that kind of language.

I originally noticed this when I was looking at 🐛 Use email verification when changing user email addresses Needs work .

Current state

• In the Drupal content style guide → , there is no entry specifically addressing this, and it uses variations on "click" throughout several other entries.
• In the Drupal interface guide → , there's not an exact entry, though it does say, "Make sure link text describes what is on the linked page or what will happen if the link is clicked. Do not use 'Click Here' or a URL for a link text."

All code: grep for 'clicking' in Drupal repo (or similar searches for "click", "clicked", etc.)

Examples of user-facing text: user.mail.yml (several times)

Examples of site admin-facing text: INSTALL.txt, block.module, contextual.module, comment.configuring.html.twig

Examples of developer-facing text: node.preview.es6.js (and note function name), form.es6.js, FormSubmitterInterface.php, BrowserTestBaseTest.php (admittedly in the weeds, but clickLink() is used often in tests)

Proposed resolution

Adopt a policy regarding input device-specific language in Drupal code.

Follow-up 1: Update user-facing text consistent with the new policy in the style guide.

Follow-up 2: Update site admin-facing text consistent with the new policy in the style guide.

Follow-up 3: Update developer-facing text consistent with the new policy in the style guide.

I separate these because the first seems particularly urgent. Ideally we shouldn't be assuming developers are only using a mouse, or model language for them in which "clicking" is the default; we also shouldn't tell site admins to save a block interface by "clicking" save. But much more significant are the default account-reset emails that go out to every user of a Drupal site, telling them to "click" various links -- a huge percentage of those are going to be seen and acted on with mobile devices.

Remaining tasks

• Define style guidelines around this issue.
• Publish updated style guide → and interface guide → (as appropriate).
• Proceed with follow-up tasks.

User interface changes

None within this issue; potential content changes in follow-ups.

API changes

None within this issue; potential code documentation and/or function name changes in follow-ups.

Data model changes

None.

Release notes snippet

TK