all-caps button labels are misread by screen-readers

[cfm]

Description

For example: A button labeled ADD USER will be announced by a screen-reader as an initialism to be spelled out: "A.D.D. user".

securedrop/securedrop/journalist_templates/admin.html

Lines 6 to 9 in 012d30e

	<button type="submit" id="add-user">
	<img src="{{ url_for('static', filename='icons/plus.png') }}" class="icon" width="13" height="15" alt="">
	{{ gettext('ADD USER') }}
	</button>

Steps to Reproduce

For this example:

1. Navigate to the Admin Interface of the Journalist Interface.
2. Activate a screen-reader.

Expected Behavior

The button visually labeled ADD USER is announced as "add user".

Actual Behavior

The button visually labeled ADD USER is announced as "A.D.D. user".

Comments

Labels capitalized explicitly in #1538 can be reverted to title case (pending #5821) and then styled with the text-transform property.

[eloquence]

Note there are i18n arguments against text-transform, see #1587 (comment)

[cfm]

After further research:

1. Per Deprecate use of CSS text-transform: uppercase #1587 (comment): the localization argument against text-transform stands. (Thanks for referring me, @eloquence.)
2. Where testing demonstrates that screen-readers may misread a specific label in all caps, we can override it with aria-label, at the cost of adding an extra string to translate. For example:

 <button type="submit" id="add-user" aria-label="{{ gettext('Add User') }}"> 
   {{ gettext('ADD USER') }} 
 </button> 

3. In general, however, and in the absence of a specific misreading, we should avoid micromanaging the accessibility tree.

I'll close this general tracking issue and address specific instances as I encounter them in the course of #5986 and #5987.